Vagrant Share(vagrantup.com)
vagrantup.com
Vagrant Share
http://www.vagrantup.com/blog/feature-preview-vagrant-1-5-share.html?utm_content=buffer080fe&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
46 comments
I know this isn't the right place for it but here we go: it's a total PITA when somehow the VM connection gets severed and "vagrant ssh" won't work and "vagrant shutdown" won't shutdown cleanly, so you have to kill it by hand and then reboot MANUALLY in virtualbox because the VM gets stuck in the grub menu after a non-clean kill. So then you have to wait for it to boot completely, then shut down normally and then run vagrant up again.
That connection dies for me periodically, like a few times a week. Anyone manage to solve that one?
That connection dies for me periodically, like a few times a week. Anyone manage to solve that one?
I've been running into this issue as well. A similar one is that the SSH connection is lost whenever the network is lost. I think both issues are supposed to be solved with the latest version of VB (4.3.8) from this ticket (https://github.com/mitchellh/vagrant/issues/2691).
If your VM is stuck on a GRUB prompt, that's an issue with its GRUB config. You could have the same problem with any VM. Change the GRUB config to stop this behavior and repackage.
If i somehow can't connect to the VM anymore "vagrant halt" followed by "vagrant up" usually fixes that. Doesn't happen alot though.
Halt breaks too, though!
Strange, question might be why your ssh connection breaks down like that. I get disconnected when i put my machine to sleep but after waking up i can just vagrant ssh back into it.
I ran into a similar (completely maddening) situation when using an Ubuntu 12.04 LTS guest with Vagrant configured to create a private network.
I don't recall the exact cause of the failure, but switching to the virtio networking drivers has completely solved this issue for me.
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']
endIt 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.
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.
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.
* 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.
Thanks for the extra info!
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.
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.
I noticed the share funcionality uses a Vagrant URL (vagrantshare.com). Sure enough, when I scrolled to the bottom there was mention of a web service. I imagine this web service will be monitized as it just makes a lot of sense, but hoping that single devs can still demo their projects to friends without having to pay a fee.
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!
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!
It's most likely being used to generate a nice URL that does dynamic DNS forwarding to the actual server.
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.
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.
This is exactly why widespread adoption of IPv6 would make everyone more productive. Why doesn't every Vagrant box have an IPv6 address that you can expose by opening up firewall rules? Well, aside from ISP's being slow and developers not spending the 40 minutes necessary to set IPA tunnel, VirtualBox does not support IPv6 addresses on bridged interfaces if the host interface is a wireless card. Sad day all around.
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.
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.
Why? Even now, you can just forward the guest port to the host and expose it to give people access.
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.
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.
Several reasons. First, you are likely behind a NAT. Sure, you can share your Vagrant box with people in your office, but you can't share them if you are working remotely. This has actually bitten me on my team (I work remotely) where I needed to debug a Puppet issue on a coworker's VM and had to try to ssh to his box. What a pain.
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.
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.
So basically localtunnel (http://progrium.com/localtunnel/), but integrated into Vagrant? Plus some SSH magic.
https://localtunnel.me/ does the same thing but with ssl for free.
Likely the first to market was http://showoff.io ( pivoted to https://forwardhq.com/ ), promoted by http://pow.cx
Likely the first to market was http://showoff.io ( pivoted to https://forwardhq.com/ ), promoted by http://pow.cx
Just 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!
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.
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
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
I'm not sure that's the way to do it. I mean, I do use forwarded ports on my projects and I also configure my private network for each one but at least on my current machine it doesn't allow outside access unless I mess with the router and the firewall. A little bit easier would be to configure a network as "public_network" on the Vagrantfile. I assume this works for most people but, again, my machine doesn't vagrant up if I have a public_network configured. I never tried to figure out why, it's not something I had to care about that much to be honest.
So, as you can see, if vagrant share works as announced it would make it much easier for me for that particular task.
So, as you can see, if vagrant share works as announced it would make it much easier for me for that particular task.
We use ngrok (vagrant share alternative-ish) to test integration with third-party services that have to send requests to our system. Works great.
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.
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.
GP said dev server, not laptop. I think in that context it's reasonable.
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
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
But can't you do all the complex/difficult stuff for them so they just have to type "vagrant up"? What are some of the complexities involved in setting up a vagrant env?
You are vastly overestimating the technical abilities of the average QA person. "Just as easily spinning up their own VM with the Vagrantfile" assumes a significant base understanding of a lot of technologies.
I think you are vastly underestimating their abilities. You install git, virtual box, and vagrant. Clone the repo and type vagrant up. If they've never done it they can refer to the wiki page you typed up for everybody. I know every QA person at my workplace could easily do it.
I've found there's a broad categorization talent/skills in QA, but a lot of it boils down to this separation -> Able to do development related tasks (set up their own envs, run different versions of apps, etc.) or not.
Anecdotally, it also seems to correlate with how useful Developers usually find their peers.
Anecdotally, it also seems to correlate with how useful Developers usually find their peers.
I install ngrok[1] on my vm's to show off what I've been working on temporarily or to see how things look on iOS.
[1] https://ngrok.com/
[1] https://ngrok.com/
Localhost tunneling has existed for a long time. It's great if you're already doing it somehow. The benefit of Vagrant Share is that it detects all these ports for you and is basically zero-touch: "vagrant share" and you're done!
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.
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.
Feature request for the Mac OS Vagrant port: please don't copy your executable into /usr/bin when running the installer (and that seems to be the only reason the installer exists at all — it would be better distributed just as a .zip containing the Vagrant directory; I can take it from there). /usr/bin is for system-provided executables, not for applications. I understand the wish to provide an easily-accessible command line executable, but Vagrant users likely know how to modify the path or make an appropriate symlink.
We used to do that, but we received SO MANY complaints that it wasn't instantly available on the PATH, that we symlinked into /usr/bin.
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
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
Well I mean what's wrong with adding a file to /etc/paths.d which is picked up by the default shells using /usr/libexec/path_helper
It works for Mactex without fucking with the system folders.
It works for Mactex without fucking with the system folders.
On Windows you could probably just set an entry in App Paths. No need to modify the PATH environment variable at all.
Cool addition to vagrant. It reminds me a lot of another useful tunneling utility written in Go: https://ngrok.com. Maybe an inspiration for it? And also, an interesting related deck: https://speakerdeck.com/inconshreveable/gosf-decentralizing-...
I helped build something like this for developing Facebook apps. I'm happy to see that the service is still running at https://tunnlr.com/. It's a good tool, and I think it makes sense as a Vagrant plugin but I'm surprised this is becoming part of core.
This is great! What i am still missing is sharing a vagrant vm across multiple machines i work with easily. Basically to set this up i have to set up a base box and bring that up on another machine and then manually switch the hd uids so that they are in sync. Otherwise dropbox sharing my vagrant workspace will sync a different id and on the other pc vagrant up wont find the existing vm and start a new one.
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.
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.
Will this also be open source so I can run my own proxy?
I was using ngrok before, but I guess it's much easier to use vagrant share.
that is an awesome idea, cant wait.
There are lots of vagrants, you don't have to share, everyone can have one or two all of their own. But if you choose to share I'm sure this is the best way.
Hopefully they expand in to Hobo's, Bums, and the underemployed.
Hopefully they expand in to Hobo's, Bums, and the underemployed.
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.