3

Say I run a server which accepts SSH connections, and being a wise person, I use SSH keys instead of passwords to connect to it. There is one user, webmaster, which has access to and controls the website-related directories and programs. Whenever I connect to the server, I log in as webmaster.

This is working great, until one day I hire a third party company to work on the website for a week, and to make things go smoothly, I want them to log in as webmaster when they do their work. When the week is over and the job is done, I want to revoke access to the server with their key.

How would I go about doing this, having multiple keys for the same user on the server, that can be edited or removed independently?

IQAndreas
  • 1,550
  • 2
  • 20
  • 39
  • I'm sure this is a duplicate, but I'm having trouble searching for existing questions on this topic, as most of the result coming up are questions about how _clients_ (not servers) can use multiple public keys. – IQAndreas May 21 '14 at 19:21

1 Answers1

6

This functionality is already supported. When you add their public key to ~webmaster/.ssh/authorized_keys just make sure you remember which key is theirs. When they're done, remove the line for their public key in authorized_keys. You can always change the last little bit of a public key that looks like an email address. Please remember that the permissions for your authorized_keys file is important and that it must be the user webmaster and the permissions 0600 (rw-------).

IQAndreas
  • 1,550
  • 2
  • 20
  • 39
Some Linux Nerd
  • 3,327
  • 3
  • 19
  • 22
  • 2
    Why would it need to be 0600? Nothing in authorized_keys is secret. What matters is the write permissions. – andol May 21 '14 at 19:36
  • A public key by itself is no secret but the fact that the corresponding key to a public key will allow access to a particular account is. If I was up to no good on a server I could simply look at root's (or any other user) authorized_hosts.. Find a public key that works and start grepping files throughout the system to see if I find a match.. If I do, there might be the private key sitting right next to it. –  May 21 '14 at 19:44
  • 1
    @andol: It must be 0600 because it won't work otherwise, at least with OpenSSH. See: http://www.openssh.com/faq.html#3.14 – ThatGraemeGuy May 21 '14 at 19:55
  • But the private key is useless surely as it will be protected by a strong pass phrase and will be 600 surely ;) – user9517 May 21 '14 at 19:55
  • 3
    @ThatGraemeGuy - that's not accurate mine are all 644 because I'm lazy – user9517 May 21 '14 at 19:57
  • This actually helped me clear up a misunderstanding about SSH keys. I was under the impression that SSH keys were generated on the server, one for each user, and then sent to the users. – IQAndreas May 21 '14 at 20:26
  • 1
    It should be noted that authorized_keys uses new lines to separate key entries. Pretty basic, but sometimes confusing if it isn't documented in an obvious place. – Kyle May 21 '14 at 20:33
  • @Iain: then you've configured `StrictModes no`, against OpenSSH's recommandation. – ThatGraemeGuy May 22 '14 at 13:20
  • @ThatGraemeGuy, I haven't touched that setting at all. This is default CentOS installs which have StrictModes yes commented out (which means it's the default setting). I can log in with authorized_keys perms at 644. If I change that to 664 I can't (as expected) login. Changing StrictModes to no and restarting sshd then allows me to login with 644. – user9517 May 22 '14 at 13:38