Vagrant Share
vagrantup.com
Vagrant Share
1–10 of 47 posts
Re: Vagrant Share
#2Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow.
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!
Re: Vagrant Share
#3Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow. 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!
How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.
Re: Vagrant Share
#4Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow. 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!
How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.
The idea is that you could have a remote coworker or a QA use your dev server to test things, review UI, etc.
Re: Vagrant Share
#5Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow. 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!
How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.
Well, this came to my mind because I'm developing a new responsive web app and wanted to test it on both my iPhone and iPad. There are several ways around this but I guess this makes it so much easier.
Also, as noted, seems great to let your colleagues see what's going on with your work.
Re: Vagrant Share
#6Sort of neat.
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.
Re: Vagrant Share
#7Earlier quoted context omitted.
How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.
Well, this came to my mind because I'm developing a new responsive web app and wanted to test it on both my iPhone and iPad. There are several ways around this but I guess this makes it so much easier. Also, as noted, seems great to let your colleagues see what's going on with your work.
> I'm developing a new responsive web app and wanted to test it on both my iPhone and iPad.
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
Re: Vagrant Share
#8It looks like the SSH option sends the encrypted private-key to anyone who asks (via the "vagrant connect --ssh" command)... so they could do an offline brute-force attack.
Thus, 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.
Re: Vagrant Share
#9It looks like the SSH option sends the encrypted private-key to anyone who asks (via the "vagrant connect --ssh" command)... so they could do an offline brute-force attack. Thus, 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 regenerate…
Yes, you're right. But this is assuming a lot of things which are still really hard:
* 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.
Re: Vagrant Share
#10Earlier quoted context omitted.
How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.
The idea is that you could have a remote coworker or a QA use your dev server to test things, review UI, etc.
So they can only get their job done if they are in the same timezone or if you don't happen to reboot your laptop? Those don't seem like great use cases.
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.