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

by smathieu • 12 years ago

230 46 12 years ago

vagrantup.com

iaskwhy3• 12 years ago

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!

iratedev• 12 years ago

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.

smathieu• 12 years ago

The idea is that you could have a remote coworker or a QA use your dev server to test things, review UI, etc.

iaskwhy3• 12 years ago

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.

kasperbn• 12 years ago

We use ngrok (vagrant share alternative-ish) to test integration with third-party services that have to send requests to our system. Works great.

deefour• 12 years ago

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/

mitchellh3• 12 years ago

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.

bhouston2• 12 years ago

Sort 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.

makmanalp3• 12 years ago

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?

kayoone4• 12 years ago

If i somehow can't connect to the VM anymore "vagrant halt" followed by "vagrant up" usually fixes that. Doesn't happen alot though.

colinc• 12 years ago

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.

  config.vm.provider :virtualbox do |vb|
    vb.customize ['modifyvm', :id, '--nictype1', 'virtio']
  end

xofer• 12 years ago

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.

akngo• 12 years ago

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).

gojomo2• 12 years ago

It 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.

mitchellh3• 12 years ago

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.

gojomo2• 12 years ago

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.

gcv• 12 years ago

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.

mitchellh3• 12 years ago

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

catinsocks• 12 years ago

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.

ygra• 12 years ago

On Windows you could probably just set an entry in App Paths. No need to modify the PATH environment variable at all.

Oculus• 12 years ago

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!

prostoalex• 12 years ago

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.

pkieltyka• 12 years ago

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-...

tlrobinson• 12 years ago

So basically localtunnel (http://progrium.com/localtunnel/), but integrated into Vagrant? Plus some SSH magic.

midas007• 12 years ago

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

jvoorhis• 12 years ago

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.

IgorPartola2• 12 years ago

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.

kayoone4• 12 years ago

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.

IgorPartola2• 12 years ago

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.

drakaal• 12 years ago

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.

sschueller• 12 years ago

Will this also be open source so I can run my own proxy?

kayoone4• 12 years ago

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.

milin• 12 years ago

I was using ngrok before, but I guess it's much easier to use vagrant share.

wnevets• 12 years ago

that is an awesome idea, cant wait.

Vagrant Share

Related Stories