> Supplying an SSH public key for future login use
It's public so it can be emailed in cleartext to the admin of the server, copied in any instant messenger or painted on walls. It's the secret key that ensures all the security of the connection.
This is a scenario where "the humans can speak to each other (directly) but the computers cannot". Key authenticity is not a problem, the other party can verify that the fingerprint is correct.
Nice! It might be interesting to use the magic-wormhole API to set up the piknik keys. In the long term, I'm pushing magic-wormhole to serve as a provisioning tool for other (more persistent) connections.
Nifty.. I'll look at the network side of that, maybe we can steal some ideas. At the moment magic-wormhole depends upon one of:
* at least one side has a public IP address
* both sides are on the same (private) LAN
* a TURN-like "Transit Relay" server that I run
That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.
If I remember correctly, ncp only works on LANs (using local segment broadcast), so it doesn't require either side to have any Internet connectivity at all. Your approach would be a lot more flexible, but I bet people would also appreciate it if you could figure out a LAN-only mode -- for better privacy, and when the Internet connection is down. Maybe you could start with an ncp-style segment broadcast and then fall back to the transit relay server if nothing on the segment answers and begins negotiation?
Yeah, also the two sides can exchange (encrypted) notes about their apparent network environment (including their public IP address, as reported by the rendezvous server), which might give them a clue that they're on the same LAN.
Also see https://github.com/warner/magic-wormhole/issues/48 for some discussion about making things work when you're connected to each other but not to the internet, e.g. an ad-hoc wifi network. It doesn't work at all now, but it totally should.
I'm still unclear on a couple of things. How do you even know which send request the attacker attempted to attack if only the codeword identifies the send request, and the codeword was wrong? Also, what stops an attacker from trying again - alternatively, what stops an attacker from doing a denial-of-service by purposefully guessing the wrong codeword?
The codes have a small number in front; these are the requests. So if the server did allow 65k requests, each one would be a different number. You can guess once per request.
Yes, an attacker can denial-of-service by guessing once on all the (possible) requests. There is some work towards stopping this sort of behavior (see e.g. https://github.com/warner/magic-wormhole/issues/126)
Trusting the baked-in rendezvous server would seem to be the most obvious security "nit," which could be addressed by compiling and running your own server. But out-of-the-box, that would seem to be a weak-point for MitM attack.
Ok, I'll bite. From the project page: "Copying files through email first requires transcribing an email address in the opposite direction, and is even worse for secrets, because email is unencrypted. Copying files through encrypted email requires bootstrapping a GPG key as well as an email address."
And S/MIME is essentially PGP/GPG, except you bootstrap the key from a central Certificate Authority. So yes, it's still a hassle.
As for SSH, how would /you/ place the public key on /their/ remote end? That's a bit of a chicken and the egg problem right there, don't you think?
Even then, the email would need to be signed and verified to ensure the key wasn't modified. You wouldn't want an attacker replacing it with their own public key.
But you would want tab completion of the shared secret so all an attacker needs is to guess the first character?
Why not email the ssh public key in plaintext and verify the md5sum, sha1sum, fingerprint, and / or first and last X characters of the key itself over the phone?
... or... Why not just put the public key on a web server with SSL and a free cert and speak the URL, then scp the payload file over? Or go ahead and get the free S/MIME cert from Comodo for your email since you can sign without the other end sending a signed email first and attach the payload file itself or an ssh public key and then scp? Or use Pidgin or a similar client with the OTR plugin on any XMPP server and send the payload file in the first place? Or issue SSL keys from your own local CA and communicate the fingerprint orally? Or send the public ssh key plaintext and only allow ssh through the firewall from the IP of your friend?
... or ... allow ssh via password rather than key for a small timeframe and communicate a password out of band rather than a shared secret for this thing?
... or ... put your ssh public key on a well-known account of yours like GitHub, Facebook, HN, etc and let your friend install it from there?
Very true, I'd personally never use the tab completion since the secrets are short enough, and I will probably raise an issue on the project to have that be optional.
And for the rest, they're still a hassle compared to just having your hackerspace friend install magic-wormhole so you can toy around with the nonsense he has on his Raspberry Pi.
Your last point, however, I think will be the key to the future (no pun intended). I'm hoping asymmetric crypto based communication will become easy, ubiquitous, and the default. Cheers to Keybase!
I would use this just to cut and paste text from my host machine to my VMs, because I've never been able to get that seemingly simple concept to work reliably.
> The wormhole library requires a "Rendezvous Server": a simple WebSocket-based relay that delivers messages from one client to another. This allows the wormhole codes to omit IP addresses and port numbers. The URL of a public server is baked into the library for use as a default, and will be freely available until volume or abuse makes it infeasible to support.
Interesting.. I'll take a look at it. My first thought is that magic-wormhole needs a canonical way to allocate "nameplates" (the numeric channel identifier at the start of the wormhole code), and that's tricky to do in a DHT (I'm assuming syncthing's relay server behaves like a DHT).
Why would I use magic worm-hole instead of Syncthing or Signal? They are both user-friendly and easy to install for the person I want to send the file to.
The only shortcomings I can imagine:
_AFAIR Signal has a size limit on the file you can send
_you need a phone number and a smartphone to use Signal
_The Synching key you have to share is complicated, but sending it via email and making sure you add the hosts quickly on both sides would provide enough security guarantees for most people. If you have a secure messenger then you can simply share the key through this channel. And overall I find it easier to explain how to
1) install Signal
2) install Syncthing and share the keys
rather than install magic-wormhole and use some passphrase.
Signal and Syncthing are great. magic-wormhole is more about setting up that initial connection: when two humans know each other, but their computers haven't met yet (i.e. know each others pubkeys).
In Signal, the security of the initial message exchange depends upon the phone network (did somebody spoof caller-id to claim Alice's phone number?) and the Signal servers (did they report the correct key for Alice's phone number)? Once you've verified keys in person, those concerns go away. In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code.
For Syncthing, if I remember right, you have to exchange "Device IDs", which are like public keys. You can send them over email, but the security depends upon the email servers (did any of the servers along the path replace that DeviceID with a false one?). The window of opportunity for that attacker is basically the same as it would be for a wormhole code sent via email. And Syncthing gets you long-term/repeated sharing of a folder, whereas magic-wormhole is one-shot.
My goal for magic-wormhole is to offer it as a provisioning protocol for other tools (with better UI and more functionality). Imagine if Syncthing had an "Invite A New Device" button, and pushing it gave you a wormhole code, and the other Syncthing instance had an "Accept Invitation" button where you type in that code. Then you could get all the nice UI and workflow of Syncthing, but you wouldn't have to transcribe the large Device ID (pubkey), and you could do it over something safer than email (like a phone call or just speaking the code to the coworker sitting next to you).
You don't trust that third-party server with any information, it simply makes the initial link between the two parties, like a DNS, that it needs to send the encrypted information to.
An evil relay server could not send the information, or send information to the wrong server, but neither would cause data to be lost because of the encryption.
Thanks a lot for the reply! Indeed I was thinking that the main use case that would make sense is the integration of your tool in other more complicated protocols, as a simple first step. As you mentioned, the Syncthing "device id" is 56 characters long that are pseudo-random and thus nigh impossible to remember. Having magic-wormhole as a first step in the handshake would make everything easier.
P.S.: some have mentioned that using apt to install dependencies and then pip to install Magic-Wormhole itself is complicated. You should probably replace these instructions for Debian by "sudo apt install magic-wormhole", as it is included in Debian as of Stretch (stable). It should be the recommended option anyway.
You can also use https://ondevice.io for that. But in that case it let's you ssh into the remote device even if it changes location/ip-address.
I use it for some IoT tinkering I do.
The security model here is pretty great assuming you trust the rendezvous server.
Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).
If I did things right, the rendezvous server shouldn't get any advantage over a network attacker: one guess per invocation of the program, 1-out-of-65536 chance of getting it right, 65535-out-of-65536 chance of giving you a WrongPasswordError.
FWIW, there's also a --verify option, which causes the program to print out a hex hash of the session key, and wait for you to approve it before sending anything. Not as ergonomic, but it removes the MitM threat pretty effectively.
Yup, it still does. In the face of a lucky-guessing attacker, PAKE basically degenerates down into plain unauthenticated Diffie-Hellman, which means Alice-Mallory has one key, and Mallory-Bob has a different key. Mallory could decrypt the messages from Alice and then reencrypt them for Bob, but Alice and Bob will still both see different keys. If they have some out-of-band means to compare those keys (which Mallory can't corrupt), then they can detect the attack.
Call me a nerdy hipster, but I prefer my 1-in-2^256 chance with AES encryption. Then I can put it, well, anywhere. Including a thumb drive, google drive, S3, email, or even some random public newsgroup.
I realize this complicates things a touch - you need a program to encrypt and decrypt the file - but that seems much more secure.
You also need to read the full AES key to your recipient. If you've already got a secure channel to your recipient, great: you can just paste them the key. But if you're sitting next to a new friend at a conference and want to throw them a copy of your secret file without worrying about who else might be able to see it in the future, you might want something more.. ergonomic :).
> a --verify option, which causes the program to print out a hex hash of the session key
This is plenty enough.
Another option is to use the ssh model whereby the sender has a persistent keypair, uses it to sign the handshake and sends the pub key to the peer. If the peer has this key in its key cache, it proceeds quietly. Otherwise it pops up a "New key, please verify and approve" message before proceeding.
Isn't it more like a <number of pending transfers>-out-of-65536 chance of getting it right? If there are 256 pending transfers, then it's more of a 1 in 256 chance of stealing someone's information?
The more popular this program gets, the easier it is to steal people's information?
The two sides exchange IP addresses (inside the encrypted channel), and try to connect to all of them. If that fails to produce a successful handshake, they fall back to a "Transit Relay Server" that I run. So they'll manage a direct connection if one of the machines has a public IP address, or if they're both on the same LAN.
I'm hoping to add NAT/UPnP support, but it's not there yet.. still looking for an easy library with Python support.
What happens when your transit server's bandwidth bill gets out of hand because someone is transferring a few TB of data to their backup host? (see article a few days back about someone griping about their 13 TB backups on Backblaze if you aren't sure this is a real thing)
It'll probably just break for the remainder of that month. I'm hosting that transit server on Linode, and I think (does anyone know for sure?) that their policy is to just turn off the interface if you go over your monthly allowance, which is like 4TB or 6TB on that instance.
Eventually I'm planning to have the client ask the transit server ahead of time for the size it intends to use, and the server can tell them to go away or make a donation or something.
"wormhole --transit-helper=tcp:HOST:PORT send" is how you can use a different server: the sender will tell the receiver about it in-band, so the receiver doesn't need to do anything special. The receiver accepts that argument too.
AirDrop: waaaay better UI, awesome animated drag-and-drop, dead-simple to use, works offline. Not so strong at clearly identifying who the file came from or is going to. Not clear what sort of integrity/confidentiality properties you get (probably better than nothing, knowing Apple, but since the send-to-which-device picker UI shows their self-selected names, there's not any obvious way to distinguish between the real "Alice's iPhone" sitting next to you and the attacker who's within bluetooth range.
Magic-Wormhole: CLI only (so far), no OS integration anywhere, better security properties. Also it's got a spiffy wizard-hat logo (thanks Katie!).
* the network-side attacker gets to see and modify all your data
* the receiver must have a public IP address
* the receiver must tell something to the sender, which is the opposite of the direction the data will flow
* you have to transcribe your IP address and port number to the other person, which I always get wrong (so many meaningless numbers!)
* you don't get much confirmation that all the data arrived, or that it arrived accurately
The wormhole code uses a wordlist that was carefully designed (not by me.. I'm using the PGP wordlist, as used by PGPfone and Zfone) for accurate spoken transcription in noisy environments. So it's more likely that they'll type in the right thing.
Yeah, if you've already gotten a public key set up (and an account on the target machine), then scp is much easier and completely secure. magic-wormhole is more aimed at situations where you don't yet have that pubkey copied over. Or where your receipient doesn't want to give you an entire account just to receive a single file.
In fact there's a mode (kinda experimental right now) to use magic-wormhole to transfer an ssh pubkey into the ~/.ssh/authorized_keys on a new account. Ideally your site admin should be able to give you access to a new machine with a wormhole code, instead of having you email them a pubkey.
> Copying files with ssh/scp is fine, but requires previous arrangements and an account on the target machine, and how do you bootstrap the account?~
Assuming that you have openssh and rssh installed, you bootstrap like this:
useradd -m -g users -s /usr/bin/rssh tmp
passwd tmp
edit /etc/rssh.conf and uncomment allowscp
Share the password with the party you want to exchange data with. Make sure your ports are open.
The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.
You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted,
and extends to cover other use cases much more easily (rsync, VNC, etc.).
When both parties are in a corp network (eg across companies) you would need a server anyway. Many either offer a FTP server or have switched to Accellion (which is kinda cr.p, and full of security holes)... so this is a nice, fast and secure alternative.
When both parties are in a corporate network their IT policy would forbid using magic wormhole. They'd have to use the file-transfer program managed by their IT department.
Instead you get to pip install. But pip isn't installed. easy-install pip? What's easy-install - it's not there? (brew|yum|apt-get) disttools. Forget this... download get_pip.py, run python get_pip.py... Some error about libsodium now? Where do I get gcc for Windows 10 again?
Python's greatest weakness is its packaging and distribution, and this project makes no effort to make it simple.
And that covers 90% of the people that care. Granted I think you're right that software packaging and distribution is still generally broken in 2017, but that's a problem across the board. It's a problem with java, node.js, python, etc.
So... 'brew install rssh' is bad and kludgy, but 'brew install magic-wormhole' is easy and light? And hey, if you're not on a mac, you have to also install a bunch of other deps too.
You probably shouldn't have tried to pad out your steps by taking a detour into package management.
Honestly, even if I have both rssh and magic-wormhole installed already, just creating a new user that can read (some of) the filesystem is already orders of magnitudes more hassle.
Disagree. I don't know a single non-programmer with brew installed on their Mac, and non-programmers make up 90% of the people who have the most trouble copying files between two computers.
sysadmin here in MAD world using homebrew since Lion. First thing I did when I got in this morning was to pull out my personal MBP and install magic-wormhole.
This is true but not completely. You will only get pip when you install the binary downloaded from python.org. On osx, people use brew, on Debian, they use apt. It is most likely only Windows people will download those binaries but actually they use Anaconda, WinPython instead
I'm actually getting tired of package managers reinventing the wheel (literally) every time they want to install something.
In production when I deploy a django app, now I might have two libraries in different places in my system. One from the OS, and one from the pip dependency.
I'm not gonna argue against that. Using pip-install certainly limits our current audience to people who are comfortable with python packaging tools, which basically means python developers.
I'm hoping to get beyond that, once I get the protocol and feature set stabilized. Using something like PyInstaller or py2app to get a single-file executable will be the first step. Porting it to other languages (I've started on SPAKE2 in Rust) might help too.
FWIW, "apt install magic-wormhole" now works on Debian (stretch) and Ubuntu (zesty). Also homebrew, as mentioned before.
Quick survey: what packaged form would be most useful to you (for desktop usage.. having some kind of iOS/Android app is a whole other beast). PPA? .dmg? .exe? .msi?
A stand alone static binary that does not depend on system libraries.
Specifically, one that 'just works' on windows, and doesn't require that you open powershell and need to change into an obscure directory to use it, or have the binary sit in a folder full of DLLs to run.
In fact, ideally one you don't have to even type anything in; for example, if you can just say; grab this one file from some safe known url (eg. github), and rename it from 'magic.exe' to 'zesty-fruit-324234.exe' and run it.
if only to address the dependency issue, one can rewrite the magic wormhole in go, then do cross-platform compilation and distribute the standalone binaries
UPnP could have helped with the router bits and dynamic DNS could help with the internal/external bits. https://upnp-portmapper.sourceforge.io is fun but UPnP isn't enabled everywhere reliably, and explaining how to do that + ensure it's working is probably only going to work for someone who would know what homebrew is.
AirDrop is cool in theory but works about 20% of the time for me. In 2017, the best way to send someone a large file is still to upload it somewhere then give them the link to it. https://getdropsha.re and similar stuff makes that easy enough that your non-technical relatives can use it successfully.
The equivalents to steps 1-11 were done by the Wormhole authors when they created the
rendezvous server. So yes, if you use Wormhole in SaaS mode, it's simpler, but you have
to trust the rendezvous server.
Operating scp with a working ssh server is as simple as working with wormhole:
To push:
scp foobar.txt tmp@www.example.com: #equivalent to wormhole send
To pull:
scp tmp@www.example.com:foobar.txt . #equivalent to wormhole receive
To revoke access, you simply change the password, instead of deleting the user account.
In fact, the steps you mention are what I already have by default on most of my machines,
so there's 0% extra effort. I got rssh working in five minutes.
Steps 10/11 are my responsibility, and the only remaining step for the other developer is step 7.
Compare explaining the above two commands to explaining virtualenv and pip.
On a busy public IRC channel, I'm not going to do that, I'll use scp, since it's also
preinstalled on their system.
So yes, I do rejoice in the simplicity.
I commented for the benefit of those already running ssh, and who wondered how to create a similar setup to wormhole with what they have. rssh will work fine.
Do you? It seems that magic-wormhole does end-to-end encryption, and the rendezvous server acts only as a relay if one or both parties are behind NAT. So yes, you leak the two parties' IP addresses, but not the files you transfer.
That doesn't make sense. The client needs the passcode to read the file, and that passcode is sent out of band. The Relay server can't simply "play the role of the client" and steal the file.
Surprised no-one has mentioned socat ('netcat on steroids') in this context, which is what I use to quickly transfer files, especially in closed network contexts.
There are some handy docker images for this over on the docker hub if you want to try them and dont have/want the needed python setup but just happen to have docker installed
191 comments
[ 6.0 ms ] story [ 440 ms ] thread"Moving a file to a friend's machine, when the humans can speak to each other (directly) but the computers cannot
Delivering a properly-random password to a new user via the phone
Supplying an SSH public key for future login use"
i had never even thought about those, and this is a great solution afaik
It's public so it can be emailed in cleartext to the admin of the server, copied in any instant messenger or painted on walls. It's the secret key that ensures all the security of the connection.
* at least one side has a public IP address * both sides are on the same (private) LAN * a TURN-like "Transit Relay" server that I run
That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.
Also see https://github.com/warner/magic-wormhole/issues/48 for some discussion about making things work when you're connected to each other but not to the internet, e.g. an ad-hoc wifi network. It doesn't work at all now, but it totally should.
Yes, an attacker can denial-of-service by guessing once on all the (possible) requests. There is some work towards stopping this sort of behavior (see e.g. https://github.com/warner/magic-wormhole/issues/126)
EDIT: was just explained in other comment by meejah, thanks! (https://news.ycombinator.com/item?id=14649727#14650551)
https://github.com/zerotier/toss
... and another less magical one:
http://www.fefe.de/ncp/
Also, you only need to send the public part of an SSH key to the remote end to set up future keyed connections to that system.
This seems like a solution with very narrow problems to solve.
And S/MIME is essentially PGP/GPG, except you bootstrap the key from a central Certificate Authority. So yes, it's still a hassle.
As for SSH, how would /you/ place the public key on /their/ remote end? That's a bit of a chicken and the egg problem right there, don't you think?
Why not email the ssh public key in plaintext and verify the md5sum, sha1sum, fingerprint, and / or first and last X characters of the key itself over the phone?
... or... Why not just put the public key on a web server with SSL and a free cert and speak the URL, then scp the payload file over? Or go ahead and get the free S/MIME cert from Comodo for your email since you can sign without the other end sending a signed email first and attach the payload file itself or an ssh public key and then scp? Or use Pidgin or a similar client with the OTR plugin on any XMPP server and send the payload file in the first place? Or issue SSL keys from your own local CA and communicate the fingerprint orally? Or send the public ssh key plaintext and only allow ssh through the firewall from the IP of your friend?
... or ... allow ssh via password rather than key for a small timeframe and communicate a password out of band rather than a shared secret for this thing?
... or ... put your ssh public key on a well-known account of yours like GitHub, Facebook, HN, etc and let your friend install it from there?
And for the rest, they're still a hassle compared to just having your hackerspace friend install magic-wormhole so you can toy around with the nonsense he has on his Raspberry Pi.
Your last point, however, I think will be the key to the future (no pun intended). I'm hoping asymmetric crypto based communication will become easy, ubiquitous, and the default. Cheers to Keybase!
What I would to see from this is a JS which serves every asset on a site via webtorrent so visitors are sharing the bandwidth costs.
Nice.
why not make use of https://docs.syncthing.net/users/strelaysrv.html ? lots of servers http://relays.syncthing.net/
We've got a ticket open (https://github.com/warner/magic-wormhole/issues/72) about distributing this rendezvous server.. I'll add a note to check out syncthing.
_AFAIR Signal has a size limit on the file you can send
_you need a phone number and a smartphone to use Signal
_The Synching key you have to share is complicated, but sending it via email and making sure you add the hosts quickly on both sides would provide enough security guarantees for most people. If you have a secure messenger then you can simply share the key through this channel. And overall I find it easier to explain how to
1) install Signal
2) install Syncthing and share the keys
rather than install magic-wormhole and use some passphrase.
In Signal, the security of the initial message exchange depends upon the phone network (did somebody spoof caller-id to claim Alice's phone number?) and the Signal servers (did they report the correct key for Alice's phone number)? Once you've verified keys in person, those concerns go away. In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code.
For Syncthing, if I remember right, you have to exchange "Device IDs", which are like public keys. You can send them over email, but the security depends upon the email servers (did any of the servers along the path replace that DeviceID with a false one?). The window of opportunity for that attacker is basically the same as it would be for a wormhole code sent via email. And Syncthing gets you long-term/repeated sharing of a folder, whereas magic-wormhole is one-shot.
My goal for magic-wormhole is to offer it as a provisioning protocol for other tools (with better UI and more functionality). Imagine if Syncthing had an "Invite A New Device" button, and pushing it gave you a wormhole code, and the other Syncthing instance had an "Accept Invitation" button where you type in that code. Then you could get all the nice UI and workflow of Syncthing, but you wouldn't have to transcribe the large Device ID (pubkey), and you could do it over something safer than email (like a phone call or just speaking the code to the coworker sitting next to you).
...and upon third-party rendezvous/relay server, doesn't it?
An evil relay server could not send the information, or send information to the wrong server, but neither would cause data to be lost because of the encryption.
P.S.: some have mentioned that using apt to install dependencies and then pip to install Magic-Wormhole itself is complicated. You should probably replace these instructions for Debian by "sudo apt install magic-wormhole", as it is included in Debian as of Stretch (stable). It should be the recommended option anyway.
Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).
FWIW, there's also a --verify option, which causes the program to print out a hex hash of the session key, and wait for you to approve it before sending anything. Not as ergonomic, but it removes the MitM threat pretty effectively.
I realize this complicates things a touch - you need a program to encrypt and decrypt the file - but that seems much more secure.
https://www.schneier.com/blog/archives/2011/08/new_attack_on...
Close though :)
This is plenty enough.
Another option is to use the ssh model whereby the sender has a persistent keypair, uses it to sign the handshake and sends the pub key to the peer. If the peer has this key in its key cache, it proceeds quietly. Otherwise it pops up a "New key, please verify and approve" message before proceeding.
The more popular this program gets, the easier it is to steal people's information?
I'm hoping to add NAT/UPnP support, but it's not there yet.. still looking for an easy library with Python support.
Eventually I'm planning to have the client ask the transit server ahead of time for the size it intends to use, and the server can tell them to go away or make a donation or something.
"wormhole --transit-helper=tcp:HOST:PORT send" is how you can use a different server: the sender will tell the receiver about it in-band, so the receiver doesn't need to do anything special. The receiver accepts that argument too.
http://techcrunch.com/2017/06/27/magic-wormhole-is-a-clever-...
Magic-Wormhole: CLI only (so far), no OS integration anywhere, better security properties. Also it's got a spiffy wizard-hat logo (thanks Katie!).
Still cool though :)
* the network-side attacker gets to see and modify all your data * the receiver must have a public IP address * the receiver must tell something to the sender, which is the opposite of the direction the data will flow * you have to transcribe your IP address and port number to the other person, which I always get wrong (so many meaningless numbers!) * you don't get much confirmation that all the data arrived, or that it arrived accurately
The wormhole code uses a wordlist that was carefully designed (not by me.. I'm using the PGP wordlist, as used by PGPfone and Zfone) for accurate spoken transcription in noisy environments. So it's more likely that they'll type in the right thing.
In fact there's a mode (kinda experimental right now) to use magic-wormhole to transfer an ssh pubkey into the ~/.ssh/authorized_keys on a new account. Ideally your site admin should be able to give you access to a new machine with a wormhole code, instead of having you email them a pubkey.
Assuming that you have openssh and rssh installed, you bootstrap like this: useradd -m -g users -s /usr/bin/rssh tmp passwd tmp edit /etc/rssh.conf and uncomment allowscp Share the password with the party you want to exchange data with. Make sure your ports are open.
See: https://serverfault.com/questions/197545/can-non-login-accou...
The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.
You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted, and extends to cover other use cases much more easily (rsync, VNC, etc.).
Ah, yes. oh come on please it's easy just /etc/init.apt-get/frob-set-conf --arc=0 - +/lib/syn.${SETDCONPATH}.so.4.2 even my grandma can do that
Step 1. Open ports on your router. It's your job to figure out which ports those may be.
Step 2. Redirect said ports to the box in question, hopefully you'll know the ip address that was assigned by your home router's DHCP
Step 3. Make sure rssh is installed.
Step 4. If rssh is not installed, please simply follow the simple instructions to get it installed for your system.
Step 4a. If it's a mac, use brew. Type brew install rssh
Step 4b. If it'a a redhat system, type yum install rssh
Step 4c. If it's an ubuntu system, type apt-get install rssh
Step 4d. If step 4b and step 4c fail, use sudo.
Step 5. Get the external facing ip address, and give it to your friend. Note that this is different than the internal address that you used in step 2.
Step 6. Create an account on your system, using rssh, and allowing sftp
Step 7. Give him the username/password
Step 8. Copy the file into his account
Step 8a. Don't forget to chmod it so he can read it.
Step 9. Tell him to get the file
Step 10. Remove the account from /etc/passwd and /etc/shadow and remove him from /etc/groups. Also delete his home directory
Step 11. Rejoice in the simplicity.
Python's greatest weakness is its packaging and distribution, and this project makes no effort to make it simple.
brew install magic-wormhole [1]
And that covers 90% of the people that care. Granted I think you're right that software packaging and distribution is still generally broken in 2017, but that's a problem across the board. It's a problem with java, node.js, python, etc.
[1] https://github.com/warner/magic-wormhole
You probably shouldn't have tried to pad out your steps by taking a detour into package management.
Disagree. I don't know a single non-programmer with brew installed on their Mac, and non-programmers make up 90% of the people who have the most trouble copying files between two computers.
I'm not even sure I see how this is much easier than ssh if you know the basics.
It's been bundled with Python for years now, and even if you don't have it, it's easy to get:
https://pip.pypa.io/en/latest/installing/
In production when I deploy a django app, now I might have two libraries in different places in my system. One from the OS, and one from the pip dependency.
I'm hoping to get beyond that, once I get the protocol and feature set stabilized. Using something like PyInstaller or py2app to get a single-file executable will be the first step. Porting it to other languages (I've started on SPAKE2 in Rust) might help too.
FWIW, "apt install magic-wormhole" now works on Debian (stretch) and Ubuntu (zesty). Also homebrew, as mentioned before.
Quick survey: what packaged form would be most useful to you (for desktop usage.. having some kind of iOS/Android app is a whole other beast). PPA? .dmg? .exe? .msi?
Specifically, one that 'just works' on windows, and doesn't require that you open powershell and need to change into an obscure directory to use it, or have the binary sit in a folder full of DLLs to run.
In fact, ideally one you don't have to even type anything in; for example, if you can just say; grab this one file from some safe known url (eg. github), and rename it from 'magic.exe' to 'zesty-fruit-324234.exe' and run it.
AirDrop is cool in theory but works about 20% of the time for me. In 2017, the best way to send someone a large file is still to upload it somewhere then give them the link to it. https://getdropsha.re and similar stuff makes that easy enough that your non-technical relatives can use it successfully.
The equivalents to steps 1-11 were done by the Wormhole authors when they created the rendezvous server. So yes, if you use Wormhole in SaaS mode, it's simpler, but you have to trust the rendezvous server.
Operating scp with a working ssh server is as simple as working with wormhole:
To push:
scp foobar.txt tmp@www.example.com: #equivalent to wormhole send
To pull:
scp tmp@www.example.com:foobar.txt . #equivalent to wormhole receive
To revoke access, you simply change the password, instead of deleting the user account. In fact, the steps you mention are what I already have by default on most of my machines, so there's 0% extra effort. I got rssh working in five minutes.
Steps 10/11 are my responsibility, and the only remaining step for the other developer is step 7.
Compare explaining the above two commands to explaining virtualenv and pip. On a busy public IRC channel, I'm not going to do that, I'll use scp, since it's also preinstalled on their system.
So yes, I do rejoice in the simplicity.
I commented for the benefit of those already running ssh, and who wondered how to create a similar setup to wormhole with what they have. rssh will work fine.
Do you? It seems that magic-wormhole does end-to-end encryption, and the rendezvous server acts only as a relay if one or both parties are behind NAT. So yes, you leak the two parties' IP addresses, but not the files you transfer.