> 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).
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 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.
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.
> 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.).
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.
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.
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.
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.
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.
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.
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.
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.
Both pwnat and chownat are very clever techniques, but I have massive doubts they work _well_ in practice, when exposed to hundreds (or even dozens) of popular NAT devices and network configurations.
Vast majority of NAT boxes change the source port on outbound packets even if a respective externally-facing port is not yet allocated. Anything that's BSD derived will randomize the port, lots and lots of others will +1 the port for each new session, thirds will +2 the port, etc.
There's also egress filtering, intrusion detection systems and NAT devices that do things that make little sense such as remapping ID field in the IP header, presumably for security reasons. Also, depending on the OS, this will need root privileges to craft fake ICMP packets.
All in all, pwnat/chownat are essentially very cool "tech demos" that can't be realistically used just on their own and require a conventional rendezvous server as a fallback.
Yeah these are excellent points. I think the biggest blocker is definitely the symmetric NAT case, since this would still be a problem even if both sides already knew the public IP of the other end...
I wonder if there is still some opportunity to find workarounds in this space. I did see some papers on prediction of the external ports based on local port and NAT vendor, but this is obviously not going to work for a no-bs-magic-wormhole-style solution.
Probably moderate with this specific technique, but I imagine you could use some simpler method where each end of the transfer is willing to share their public IP. This would reduce the problem to UDP hole punching/scanning across some pre-defined port range and then running whatever traffic you need through that pipe. I feel like this would look less "suspicious" to an IDS than crafting odd-looking ICMP packets.
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.
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.
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?
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.
Eh,I like the concept of kbfs and have it installed on my PC and phone, but it's not really a competitor to this. Keybase reminds me of a secure alternative to Dropbox or Google drive. You've got a quota that you can upload to their server (encrypted). While you can use it to move files between destinations, that isn't it's primary goal.
And it's not a lossless storage at that, as their filesystem doesn't support all metadata . I.e. it removes any timestamps from the files.
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.
I see you guys arguing what is easier, wormhole, syncthing, ssh. I'll argue that Keybase is by far the easiest. Just but the files in /Keybase/private/person0,person2
I love Keybase.. they're doing great things to bind public keys to names at large identity providers (twitter, github, etc). And in many cases, the github username of your intended recipient is the only thing you know about them anyways.
magic-wormhole can help you in the case where you're sitting next to someone at a conference and they don't have a github/twitter account, or if you want don't want to depend on github/twitter/etc access control (e.g. if some bug in github allowed gists to be published under other people's usernames, that aspect of the keybase security story would fail).
It might also appeal to folks who don't care for centralized identity providers. When we worked on Mozilla Persona, we tried to make it possible for individuals to run their own IdPs and "own your own identity". Keybase can sorta do that (by proving ownership of an HTTP or HTTPS URL), but magic-wormhole is "better" in the sense that it doesn't have any concept of identity at all. The file goes-to/comes-from the person who knew the same code, end of story.
I'm interested in some sort of combination: maybe a confirmation step that uses a wormhole code to exchange the expected public keys with a Keybase peer, to make sure they're the same, without needing to type or read the full RSA key. (There's a protocol named SAS, "Short Authenticated Strings", that can be useful in this case).
> Copying files onto a USB stick requires physical proximity, and is uncomfortable for transferring long-term secrets because flash memory is hard to erase. 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? Copying files through email first requires transcribing an email address in the opposite direction
I had similar motivations in 2006 to write a tool to copy files "point to point". So here's my shameless plug:
(they use a few other scripts from the same repo) used like follows (only practical when being able to copy-paste, my use case is to copy things between servers without needing ssh authentication between them, but having open ssh sessions into both from the same desktop/laptop):
chris@a:/tmp/chris$ echo Hello > World
chris@a:/tmp/chris$ netoffer World
--Run:--
echo jxqtrb7xfq2e4dqy3uitc7986ydj56w59iqu84b | netfetch 78.47.51.206 15123
chris@b:/tmp/chris$ echo jxqtrb7xfq2e4dqy3uitc7986ydj56w59iqu84b | netfetch 78.47.51.206 15123
chris@b:/tmp/chris$ cat World
Hello
It also allows you to share any data but also deals with incremental updates. The main use-case is to share big scientific datasets that update over time.
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.
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.
https://transfer.sh/ is another neat service which allows you to upload a file easily using a tool such as curl and get a shareable link. There was one time when I only had Chrome Remote Desktop access to a machine without root, where this was a convenient way to share some files.
additionally, the file is automatically cleared when it goes unused for a while. There is also FEX[2], which is geared more towards power-users and includes bi-directional transfers. Both are fully self-hosted and trivial to set-up.
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)
Great collection of tools here. I'm adding here my own approach, aimed at getting around proxies/firewalls:
the files are encrypted and sent in the body of a HTTP request. The receiving end is a simple nodejs http server that can be started on the fly.
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.
* 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.
Users may also want to look into NitroShare. Although it only works on the local network, it uses IP broadcast for automatic peer discovery (next version will use mDNS). It includes installers for Windows and macOS. Debian, Ubuntu, and Fedora include it in their respective package archives. There is also an Android app. (Disclaimer: I am the maintainer.)
Anybody know how the author generated the word-list? I generated one for my own passphrase use; I took the 2000 most common english words and used metaphone to prune any similar sounding words, which got me down to around 600; I then truncated the list to 512 yielding 9 bits per word.
Looks like another application the key exchanges algorithms used in Mozilla Weave/Firefox Sync. They used to do that to associate new devices and send them the keys, but they killed that because the UX was more complex than user/password.
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!).
This is so handy. I pushed it to the snap store. So if you're on a snap supported Linux distro you can just run "snap install wormhole" to get it and future updates.
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
Isn't this solving a different problem. pushbullet is for sharing data between all your devices. magic-wormhole is for sending files to other people's devices.
Seems likely the use of the "Rendezvous" term is going to get you a cease-and-desist just like Apple got over what is now known as "Bonjour" (aka mDNS)
Strictly for internal networks, and no crypto in transit, but dead easy - also for grandma - and covering phones as well as the three pc platforms: Dukto. I use it all the time.
I just use socat or netcat on home networks. Pipeview for a progress meter. I am as paranoid as they come, but if someone has my small home network they already have my data :)
When I want to give things, I use ssh to put it in the static part of my website in a directory with a random name, then I send the url by mail. My sftp client is already configured with ssh keys. When the things I have to send is a collection of jpeg files, I use fgallery.
My point is that everybody should have a website somewhere (my C1 at cloudscale is 3.59€ per month). Everybody should have a ftp client configured to access it without hassles.
Everybody? That's a very brave idea. As in "non-techies are non-people," or "everybody should become a techie"?
(Also, FTP is an insecure, broken, incomplete, horrible, ancient protocol that should have died in a fire 20 years ago; never mind that I may want to transfer files between two people, not hang those files out onto the web)
> 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.
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.
Not exactly the same, but for those Linux/KDE users who look for a tool to connect to another machine within the same LAN, I can recommend KDE-Connect (file-transfer, notifications, shared-clipboard, etc.).
Supports Windows (XP and up), OS X/macOS (10.6 and up), Linux (packages for Ububtu and Fedora), and Symbian. Ports available for iOS, Blackberry, and more.
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!
why not make use of https://docs.syncthing.net/users/strelaysrv.html ? lots of servers http://relays.syncthing.net/