
Vagrant Share - smathieu
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
======
bhouston
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/](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](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.

~~~
makmanalp
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?

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

~~~
makmanalp
Halt breaks too, though!

~~~
lojack
I run into similar problems. Seems to happen when I disconnect and then
reconnect to a different network.

~~~
makmanalp
I think it may be this for me too, I code at work and then carry the laptop
home to finish up sometimes.

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

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

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

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

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

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

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

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

~~~
midas007
[https://localtunnel.me/](https://localtunnel.me/) does the same thing but
with ssl for free.

Likely the first to market was [http://showoff.io](http://showoff.io) (
pivoted to [https://forwardhq.com/](https://forwardhq.com/) ), promoted by
[http://pow.cx](http://pow.cx)

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

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

~~~
bhouston
> 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

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

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

~~~
mitchellh
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](https://github.com/mitchellh/vagrant-installers)

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

------
pkieltyka
Cool addition to vagrant. It reminds me a lot of another useful tunneling
utility written in Go: [https://ngrok.com](https://ngrok.com). Maybe an
inspiration for it? And also, an interesting related deck:
[https://speakerdeck.com/inconshreveable/gosf-
decentralizing-...](https://speakerdeck.com/inconshreveable/gosf-
decentralizing-the-web-again)

------
jvoorhis
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/](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.

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

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

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

------
wnevets
that is an awesome idea, cant wait.

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

