[ssh] tagged posts

Github says: Please audit your SSH keys

I got the following from Github after their benign hacker incident:

Please audit your SSH keys
On Sunday March 4, 2012 a security vulnerability related to SSH keys (public keys) was discovered. For your protection and to prevent unauthorized access we have disabled your public keys until you approve them.

They want me to audit my SSH keys (a simple process). First, find your public key that you use on GitHub (probably in your .ssh directory if you are using a Mac). Then get its fingerprint. Here’s how you do that on a Mac:

Trinity:~ kelvin$ ls -l .ssh/id_rsa*
-rw-------  1 kelvin  staff  1743 Sep 11  2009 .ssh/id_rsa
-rw-r--r--  1 kelvin  staff   400 Sep 11  2009 .ssh/id_rsa.pub
Trinity:~ kelvin$ ssh-keygen -lf .ssh/id_rsa
2048 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX .ssh/id_rsa.pub (RSA)
Trinity:~ kelvin$

Using ssh-keygen you can get the fingerprint from your private key filename (it will look for your public key for you). That long list of “XX:XX” things will be a hexadecimal number that matches the key fingerprint at the bottom of the GitHub SSH audit page. If it doesn’t match then either Egor hacked you or you might have used a different key (keep looking!).

Tags: , , , , ,

Manage multiple SSH private keys with IdentityFile

There are many guides that show you how to set-up your SSH client for password-less login using public-private key certificates. If you have different clients, you may have several different private keys. How can you manage them?

It was pointed out that ssh-agent and PuTTY’s Pagent can also be used to manage multiple private keys.

SSH has a per-user configuration file called ‘~/.ssh/config’ that it can use to select your private keys based on the remote user name and remote host by using wildcards. Let’s check out my ‘config’ file:

IdentityFile ~/.ssh/ids/%h/%r/id_rsa
IdentityFile ~/.ssh/ids/%h/%r/id_dsa
IdentityFile ~/.ssh/ids/%h/id_rsa
IdentityFile ~/.ssh/ids/%h/id_dsa
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dsa

The percent-h and percent-r take the host and the remote user from your SSH user and hostname arguments. Consider this example command:

$ ssh remote_user@remote_hostname.example.com

From the example command, the SSH client would use the wildcards to seek the correct key to use:


This means that if you had two private keys that you used to access two different servers, you would arrange them as follows. The first one is arranged as follows:

$ ls -l ~/.ssh/ids/remote.example.com/remote_user/
total 16
-rw-------  1 kelvin  staff  668 Mar 24 20:09 id_dsa
-rw-r--r--  1 kelvin  staff  610 Mar 24 20:09 id_dsa.pub
$ ssh remote_user@remote.example.com
[remote_user@remote ~]$

Our second example uses a simple hostname. If a remote user is not required, you can just use the hostname:

$ ls -l ~/.ssh/ids/webby.example.org/
total 16
-rw-------  1 kelvin  staff  668 Mar 24 20:09 id_rsa
-rw-r--r--  1 kelvin  staff  610 Mar 24 20:09 id_rsa.pub
$ ssh webby.example.org
[webby ~]$

For sure, these are totally contrived examples, but you can watch the cascade yourself by adding the verbosity flag(s) to your SSH client session (this one is my client’s WebFaction account):

Trinity:.ssh kelvin$ ssh -v user@user.webfactional.com
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/kelvin/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to user.webfactional.com [] port 22.
debug1: Connection established.
debug1: identity file /Users/kelvin/.ssh/ids/user.webfactional.com/user/id_rsa type -1
debug1: identity file /Users/kelvin/.ssh/ids/user.webfactional.com/user/id_dsa type 2
debug1: identity file /Users/kelvin/.ssh/ids/user.webfactional.com/id_rsa type -1
debug1: identity file /Users/kelvin/.ssh/ids/user.webfactional.com/id_dsa type -1
debug1: identity file /Users/kelvin/.ssh/id_rsa type 1
debug1: identity file /Users/kelvin/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'user.webfactional.com' is known and matches the RSA host key.
debug1: Found key in /Users/kelvin/.ssh/known_hosts:41
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/kelvin/.ssh/ids/user.webfactional.com/user/id_rsa
debug1: Offering public key: /Users/kelvin/.ssh/ids/user.webfactional.com/user/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Mar 31 22:31:08 2015 from
[user@web ~]$

Tags: , , , ,