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