I've learned at myriad sources online that (roughly), in order to login to a remote server without a password: generate an ssh key, put the pub version in authorized_keys on the remote system; put the private version in your local ~/.ssh/ directory; chmod it to 0600 and poof, you're in. While that is mostly correct, I find that the key (pair) has to be named id_rsa (id_rsa.pub) or id_dsa (id_dsa.pub) for SSH to offer it to remote servers.
Let me back up a bit. I have a login, SurnameG
on my local Mac. I have a SurnameG account on a remote system, otherserver.
I copied the contents of ~/.ssh/surnameg.pub
to that system's /home/surnameg/.ssh/authorized_keys. I've tested with the -i
option from my Mac to ssh in and it works fine.
I have an ~/.ssh/id_rsa
(which I generated for use with github.com).
And of course, I have ~/.ssh/surnameg
and even some other keys there, which are not being "tried" when I try to login the following way to otherserver.com :
ssh 1.2.3.4
Here, I am trying to use SurnameG
(the current local logged in user) to login to my SurnameG
account on otherserver. I am wanting openssh to offer ~/.ssh/surnameg
in its attempt to connect, but it does not - let's take a closer look with the verbose option:
BOX:~ SurnameG$ ssh -v 1.2.3.4
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/SurnameG/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [50.112.132.124] port 22.
debug1: Connection established.
debug1: identity file /Users/SurnameG/.ssh/id_rsa type 1
debug1: identity file /Users/SurnameG/.ssh/id_rsa-cert type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
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: Server host key: RSA ax:64:3e:4a:e3:2c:e4:30:dd:36:a4:a0:9x:fa:ba:6b
debug1: Host '1.2.3.4' is known and matches the RSA host key.
debug1: Found key in /Users/SurnameG/.ssh/known_hosts:88
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/SurnameG/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /Users/SurnameG/.ssh/id_dsa
debug1: No more authentication methods to try.
Curiously, openssh only offers ~/.ssh/id_rsa, but that's not all. It "tries" ~/.ssh/id_dsa also? I'm not sure on the difference between the two (offering versus trying) Anyway, if I am reading that correctly, openssh never tries any of my other private keys in ~/.ssh/*
.
Okay, I know I can explicitly describe each server in ~/.ssh/config
with something like
Host otherserver
HostName 1.2.3.4
User surnameg
IdentityFile ~/.ssh/surnameg
and then login with
ssh otherserver
and that's fine and dandy and works great. But really, my ~/.ssh/config is getting unwieldy. Sadly I didn't cd ~/.ssh && git init
a long time ago. But I digress.
My question is this: Is there a simpler, faster, more automated way to get ssh to try more keys in the ~/.ssh directory dynamically when attempting logins, or is editing your ~/.ssh/config for every server you need to connect to the only way to configure ssh? Have I misunderstood anything above about how SSH is supposed to work?