Vagrant Share
vagrantup.com
vagrantup.com
We already share our vagrants within our office as we port forward from the host computers to the guest. Thus to access bob's vagrant I just go http://bob-computer:3120/, etc... We use this feature periodically and it is useful in those cases.
I guess this new feature is mostly for remote collaborations where you are not in the same secure network.
PS. Vagrant is one of the most reliable parts of our http://clara.io development infrastructure. We absolutely love it. I was trying to think of issues I have with it and I can not think of any.
That connection dies for me periodically, like a few times a week. Anyone manage to solve that one?
I don't recall the exact cause of the failure, but switching to the virtio networking drivers has completely solved this issue for me.
config.vm.provider :virtualbox do |vb|
vb.customize ['modifyvm', :id, '--nictype1', 'virtio']
endThus, even though there's some public-key encryption being used, this is ultimately less secure than even allowing remote logins with just a password (because you can't observe and throttle failed attempts).
Even with the keypairs being regenerated each time, or the "--ssh-once" option, there's likely a tendency to use the same password over and over with the same collaborators. If so, once a third-party captures one of the ephemeral keypairs, the offline brute-force could be used to discover the reused password, effective for compromise in the future despite the key-refreshing.
So be aware of this, and don't think the ephemeral-keypairs and public-key aspects mean you can use/reuse weak passphrases over long periods with the feature. The passphrase is the major security measure, and appears vulnerable to unthrottled offline brute-force attack.
* The person would've had to retrieved the private key before. This private key is only ephemerally written to disk to `ssh` and is deleted after, otherwise being stored in memory only a brief period of time. Additionally, when it is sent down over the network, it is done so over a TLS connection. So this means they would've had to somehow intercept that.
* The person, as you said, would have to brute force the password. PERHAPS the easiest part if people are using easy passwords (we can assume they are, for this comment).
* A subsequent share name with SSH enabled. The share names created (happy-panda-1234) are in a set of 40,000,000 possibilities (for now). They probably won't guess that, especially since shares are only active 1 hour. They could try to intercept the share name, but we send it down over TLS, so they'd have to do a MITM there somehow. Unless the person is running OS X 10.9.{0,1}, not easy.
* And, if the sharer is using --ssh-once, they'd have to do all the above and connect in before the intended connector is in.
This is all to say that while you're correct, I imagine there are much easier ways to attack someone.
And this is just the state of things as Vagrant Share is right now! We already are working on and completed many additional features that we're simply not launching Vagrant 1.5 enabled with:
* You'll be able to restrict access to a share based on organization or username. In this case, to retrieve the private key, you'd need to have an API token for the user in question.
* We're adding detailed audit logs of connections, connection attempts, and more. The person sharing will be able to see who connects and when.
* You'll be able to run a private installation of the server-side component. In this case, you'll be able to run it within a firewall that requires perhaps a corporate VPN to access. Another layer to the onion.
And that is just changes that affect the SSH portion. We have more coming for HTTP and others.
Again, I want to say that given all the right prerequisites, you're right. But we did a lot to thwart this sort of thing, and we're not stopping there. Sharing anything over the internet always has a risk attached to it, and we're trying to mitigate any potential threats as best we can.
The unpredictable share-name likely adds the most important short-term barrier – essentially an extra random passphrase that's not offline-brute-forceable – especially if your server is logging/throttling scans of the share-name space.
Do I understand correctly that the 'share' command doesn't exit until the session ends? If so, it might be nice to report all the connections/attempts at each session end, so checking another log at a remote console isn't required to notice an anomaly.
The security may be fine for typical uses, I just wanted to help people understand that the password chosen is potentially leaked (in encrypted form) to third-parties... so shouldn't be something too weak/common/widely-reused.
If my above assumption is true, would a Vagrant Share Enteprise be in the works/future, similar to Github Enterprise?
Thanks for the awesome tools HashiCorp!
One could probably get away with just using an IP and a port, but within an organization that's behind a firewall it's not always immediately obvious which IP and port to use.
Edit: in fact I wonder if instead of building yet another IPv4 traversal tool, new applications that require P2P connectivity should actually start building it as an IPv6-in-something tunnel. There are plenty of ways to do this including AYIYA which while not fantastic would actually work really well here.
Vagrant share makes the process of doing this super easy which is great, because you don't need to do any of that manual trickery.
Second, port forwarding is fun and all, but why bother when you can do things properly and directly. Your host machine can still control everything and you won't need to do anything manual. All the manipulations that are required can still be hidden behind the simple `vagrant share` command. You can even combine this with a dynamic DNS entry so that you could share not just an IP address but a simple name.
Third, it would be less effort do support this, than to maintain yet another NAT traversal service.\
Fourth, this would speed up adoption of IPv6, something we will all benefit from in the long run.
Likely the first to market was http://showoff.io ( pivoted to https://forwardhq.com/ ), promoted by http://pow.cx
Edit: I got so excited I even forgot to thank Mitchell for all the hard work. Vagrant completely changed my (work) life. Thank you a thousand times, Mitchell!
Plus if you are at the point of QA/PM review of what you've done, the code has already been checked into source control. They could just as easily spin up their own VM with the Vagrantfile.
I used Vagrant for CI builds for a while, and I would have liked the ability to automatically share an internal url to the environment so that when coworkers submitted code that broke the build, they would have a single link to follow to get access to the particular environment on the particular server that serviced their job.
Some vagrant envs are also somewhat complex to set up - I could use this for teaching people how to use things like this: https://github.com/stackforge/puppet_openstack_builder
Anecdotally, it also seems to correlate with how useful Developers usually find their peers.
Also, as noted, seems great to let your colleagues see what's going on with your work.
This is already easily done just by configuring port forwarding from your host to your guest in your vagrantfile.
e.g.:
config.vm.network :forwarded_port, host: 8080, guest: 80
So, as you can see, if vagrant share works as announced it would make it much easier for me for that particular task.
Another benefit Vagrant Share has that I haven't seen yet in any other localhost tunneling solution is that it shares _every_ port (if you want), not just a single port, and gives the other person an IP to access the machine as if it were on the LAN. This is super nice if you want to expose anything like Redis, SSH, etc. You just "vagrant share" and, again, you're done.
Also, many localhost tunneling solutions don't support UDP. We fully support UDP connections in addition to TCP.
The big win, though, technology aside, is how if you use Vagrant, this just becomes another part of your Vagrant workflow that _just works_. You don't have to worry about installing anything, and of course it'll work with any sort of guest machine running on any provider.
An alternate approach: Mac has some way to hook into shell profile loading so we should be able to inject a script somewhere that amends the PATH. This turns out to be a little crazy on Mac for some reason I don't remember, but should be possible.
Surprisingly, things are better here for Windows: Windows has an API call to both set environmental variables AND send messages to applications to refresh their environmental variables! So, Windows people have somewhat nice things.
Anyways, I'd love to improve this. The installer generators are open source, would be happy for any contributions: https://github.com/mitchellh/vagrant-installers
It works for Mactex without fucking with the system folders.
Also when i install a new service inside the vm on one machine, i have to repackage the vm and reinit it on the other machines later.
Kind of a pita, has anyone an elegant way to solve this ? Can't believe no one is working with multiple machines at work/home.
Hopefully they expand in to Hobo's, Bums, and the underemployed.