"ssh setup" feature

[warner]

We came up with a neat feature idea at PyCon: using magic-wormhole to set up SSH pubkeys.

The use case is that Alice owns a computer, and wants to give Bob SSH acccess to it. Either Alice is root on the host and she's setting up a new account for Bob, or Alice is a normal user (logged in already) and is trying to add her own pubkey.

Alice runs something like wormhole add-ssh, maybe as wormhole add-ssh --user=bob. Then Bob runs wormhole send-ssh. The add-ssh command generates and displays a wormhole code. The send-ssh command looks in ~/.ssh/, finds your pubkeys, and asks you which one you want to send, then accepts the wormhole code, and sends the pubkey. When add-ssh receives the pubkey, it appends it to ~/.ssh/authorized_keys of the given user account.

[kneufeld]

May I suggest ssh-copy-id as the command (or some subset of that) so it more closely matches the unix command of the same name. The whole looks like a duck thing... ;)

[meejah]

Brainstorming about some basic use-cases. The simplest is:

A user with access to two machines wishes to enable machine A to ssh to machine B. So, they would:

1. run "wormhole ssh add" on machine B (yielding a wormhole code)
2. run "workhole ssh send" on machine A (transcribing the wormhole code)

Once the wormhole is established, ~/.ssh/identity.pub is copied from machine A to machine B and appended to ~/.ssh/authorized_keys.

[jrollins]

+1 for @meejah's suggested syntax/implementation

[warner]

We landed PR #57 just now. There are a few items I want to figure out before making a release with this feature:

• remove the verification prompt from the side that provides the SSH key
• add a verification prompt to the side that receives the SSH key (this is the side that is granting some authority, so they're the one that needs to be sure)
• the send/receive-a-blob utility functions that got added.. they currently take strings, rather than bytes. We should make that clear by adding a type check as a precondition assertion
• the current implementation defaults to adding the pubkey to the current user's authorized_keys file, creating it if necessary, and setting the permissions correctly to appease sshd. And there's an argument to point to a different username instead.
  • I'm still uncertain about what a safe default value should be here. I think the majority use case will be for root to set up SSH for some non-root user, followed by a minority use case of users setting up SSH for themselves. So I want an easy way to point to someone else, and an easy way to point to yourself, but I'm nervous about defaulting to yourself, because when root runs this, I want to make it hard for root to give out root access by mistake.
  • when root gives access to a non-root account, the ownership of the .ssh/* files must be correct. the current implementation doesn't do os.chown.
  • maybe the root-gives-non-root pattern should be sudo -u bob wormhole ssh invite ? Does that set up $HOME correctly?
• it'd be nice to get some more test coverage

[warner]

At a meetup tonight, @gtank and his pal Ryan helped me realize that the actual high-level command I want here is basically wormhole adduser [adduser-args] USER.

That command would pass all its arguments to /usr/sbin/adduser, adding --disabled-password to skip creating a password entirely (leaving the account incapable of password-based login, and only accepting pubkey-SSH). Then it'd display the wormhole code, and either wait for the client to finish, or fork itself into the background and wait. Internally, it would use its root powers to modify the ~USER/.ssh/authorized_keys file (fixing both mode and ownership).

root@host# wormhole ssh adduser bob
Adding user `bob' ...
Adding new group `bob' (1001) ...
Adding new user `bob' (1001) with group `bob' ...
Creating home directory `/home/bob' ...
Copying files from `/etc/skel' ...
Changing the user information for bob
Enter the new value, or press ENTER for the default
    Full Name []: Bob
    Room Number []:
    Work Phone []:
    Home Phone []:
    Other []:
Is the information correct? [Y/n] y

Account created, using wormhole to request SSH public key.
Please ask user 'bob' to run:

 wormhole ssh accept

and enter the wormhole code:

 4-purple-sausages

now waiting for wormhole to be established..

That would satisfy what I'm describing as the "primary" use case (run as root, create account for somebody else), which could let a lower-level wormhole ssh command address only/mostly the secondary, and be cleaner. In particular, wormhole ssh invite doesn't need to be so short, so could be pointed at an authorized_keys file directly:

• wormhole ssh request ~/.ssh/authorized_keys
• wormhole ssh send ~/.ssh/id_rsa.pub

My friend Sam likes to have each client generate a new pubkey for each host (so the ssh-agent can be used to empower/revoke logins for specific hosts). So I think the high-level accept command should have a --generate option which makes a new pubkey and sends it to the adduser side. If you don't provide that, then it should either look for existing keys (and maybe make you choose if ther are multiple ones), or require an explicit path to the .pub file.

I'm still uncertain about how all these commands should be named. I don't want to overpopulate the top-level namespace of the wormhole command. And I'm aware that a subcommand which can spawn adduser or ssh-keygen is starting to drift beyond the core purpose of magic-wormhole. So part of me wants to hide the commands slightly, probably all under a shared subcommand like wormhole ssh (except that adduser is only 50% an ssh thing). Gotta think about that some more.

[jrollins]

I have to say I really don't like this "wormhole adduser" proposal. It seems in violation of a lot of unix-y principles I hold dear, and I would certainly never use such a feature. I really don't think wormhole should get in the business of creating user accounts on systems, or do anything that would require superuser privileges for that matter.

I think all an ssh feature should do is just send a specified pubkey, and then receive a pubkey and append it to the authorized_keys file of the user calling it. So something like this would be most intuitive to me:

• wormhole ssh send [~/.ssh/id_rsa.pub]

where you can optionally specify the pubkey file (~/.ssh/id_rsa.pub otherwise), and

• wormhold ssh receive [~/.ssh/authorized_keys]

where you can optionally specify the authorized_keys file to which the received key is appended (~/.ssh/authorized_keys otherwise). It should probably be smart enough to not double add the same key for the same host.

That would very naturally cover the most common use cases in the most intuitive manner. If wormhole did anything beyond this it would be extremely unexpected imho.

If you want to add a key to a different user then why not just:

• sudo -u otheruser wormhold ssh receive

[meejah]

As a slight tweak to what @jrollins says above, I'd also thought of being allowed to specify - instead of the authorized_keys file so e.g. you could pipe it to some file (and this would also play more-nicely with shell-script type things). But, then you'd need to output the wormhole code (and other "messages") to stderr, probably ... so.

FWIW, I agree that adduser smells like "too far". Also, running something like this as root is probably a thing that should be discouraged?

[ghost]

This feature is in magic-wormhole 0.10.5 but I don't see it in the docs anywhere. Am I missing it, or could some documentation be added?

https://magic-wormhole.readthedocs.io/en/latest/search.html?q=ssh&check_keywords=yes&area=default