2014-03-13

SSH Key Magic for pkgs and fedorahosted (or how to not cause false logins)

So every couple of hours, I check the Fedora Project's servers logs to see if we have had failed logins, bad logins, etc. Sometimes people decide that they really really want to see if they can log in as someone else using '123456' or something. Its all fun and games until your atmosphere gets sucked into space (or something). One of the problems I see a lot though is that developers may get denials getting into fedorahosted.org or pkgs.fedoraproject.org due to the fact that they have multiple SSH public private keys.

Unless told otherwise, most ssh clients do not have a heuristic to know which public/private key to use for which site.. and so will have to play 20 questions to see if any of them work. If you have a lot of keys, this can result in you being denied access because your client tried 4 keys and didn't get the right one. Those 4 keys might get logged as seperate failed attempts which can make it look like someone is trying to break into an account, and then I need to send an email to make sure it was X really trying to log into fedorahosted.org at 4 am in the morning.

There is a way to avoid this problem by editing your .ssh/config file to know the appropriate key for each server (or set of servers). I use a variant of the following to cut down the problems.



Host  *.fedorahosted.org *fedorapeople.org *.fedoraproject.org
    User X
    IdentityFile ~/.ssh/id_fedora_rsa.pub
ForwardAgent no ForwardX11 no Port 22 KeepAlive yes HashKnownHosts no GSSAPIAuthentication no VerifyHostKeyDNS yes ControlMaster no

To explain the lines:

  1. The Host configuration option says for the following hosts the following settings are to be used.
  2. Set the account name to X. [EG change this to match the account you use.
  3. Use the specific public key in this file for this system. This is actually the most important line and should cut down the failed attempts per user.
  4. Do not forward my ssh credentials. I do this to cut off possible forwarding attacks where an malevolent host can leapfrog to other machines that id_fedora_rsa would be trusted.
  5. Do not forward X11. The boxes I log into don't normally run X11 so this is more about cutting down a "hey can I run X11?" question from my client to the server.
  6. Use port 22. I am being pedantic here because I have it set to other ports for some other boxes in my .ssh/config.
  7. KeepAlive is turned on because I am on wireless and sometime things quit talking.
  8. Don't hash my known hosts.. mainly because I find I need to read where I have been as much as someone who might break into my account.
  9. None of these systems use kerberos so turning off GSSAPI means its anotehr set of "Hey can I?" questions not asked during login.
  10. If possible verify the hosts public key in ssh. Not really useful without a signed DNS.. but someday :).
  11. Don't use controlmaster for this host. Multiplexing is good when you need it, but I don't generally need it. I have it here as another 'Can I?' which may slow down login for some connections.
Anyway, if you connect up your hosts with your keys, you can make sure your client isn't trying to authenticate your Fedora account with your GNOME, KDE, School, Home, etc etc keys.
Post a Comment