2

I need to let untrusted users, strangers, upload their id_rsa.pub to my server and onto a given user's authorized_keys (user git in my case). What is the safest way of achieving that, without having to do anything manually?

I am particularily thinking about a web interface, but if there are strong advantages of another method, I am open to ideas.

The http daemon runs as user http, and git must not be vulnerable to attacks from the http user, in case http gets compromised.

Flavius
  • 351
  • 1
  • 9
  • We used a web interface at a company I used to work at. But we used additional verification: after an employee uploaded their key, an operator would call them back at their desk, and have them read the fingerprint. – Barmar Dec 18 '14 at 21:28
  • I have added *strangers* to my question. – Flavius Dec 18 '14 at 21:30
  • If you do it from the web, then `http` will need some way of writing to `~git/.ssh/authorized_keys`. This effectively makes `git` vulnerable to attacks from `http` -- if someone violates the webserver, they can use the same mechanism to upload keys of their choosing. – Barmar Dec 18 '14 at 21:47
  • I am sure there are ways to avoid that problem. I am aware of one, but I don't want to influence the answers. – Flavius Dec 18 '14 at 21:49

2 Answers2

2

Since you are fine with letting untrusted users add their public keys to the authorized_keys file of the git user, then you might as well let them know the password for git.

pdp
  • 707
  • 7
  • 8
2

Use another processes as a middle-man. Your web service (or whatever) writes new requests to a spool somewhere. The middle-man watches the spool, removes and sanity checks new entries, and append what's valid to git's authorized_keys file. The same middle-man can give feedback that the web service can read. But a compromised http user cannot manipulate the middle-man or the git user. Your middle-man can be a daemon or even a cron job.

Alternatively, since you're obviously into bad ideas :), we can take advantage of the fact that 1), no matter what, the git user will have write access to its own authorized_keys file and 2) you're ok with literally anyone having SSH access to the git user. So, since your http user falls under "anyone", give your http user an ssh key-pair and add the public key to the git user's authorized keys file. Now, your web service can simply do an ssh -n git@localhost echo $key >> ~/.ssh/authorized_keys. There's no lapse in security here, because a stranger with SSH access would be able to do exactly this anyway.

If getting a shell isn't something that you want to be possible for your open-access git user (because security is important, you know), but if you'll still allow git push to be issued over SSH, then you can get really meta by creating a repository just for public key commits. Your http user will have a clone of this repository and your web service will issue commits and pushes. Then, a server-side hook can sanity check the key(s) in the commit and add it to the authorized_keys file of your git user upon validation.

But let's assume that this all gets completed somehow in some fashion. What you'll have is a system where anyone can grant themselves SSH access for your git user. So then what's the point of SSH authentication at all? Do you want strangers to have shell access? Why not just null the git user's password and allow empty passwords? Or, if you don't intend on these users having anything but the ability to clone over SSH, then why not avoid this entire mess by just serving your repositories over http or the git protocol?

Christopher Neylan
  • 956
  • 2
  • 8
  • 17
  • Thanks, I was also thinking about a middle man, but additionally, I like your idea about a public repository for public keys, which didn't cross my mind. I will try to combine them. – Flavius Dec 20 '14 at 10:08