2

I am trying to establish password-less ssh to myself on a CentOS6 system. I go through the following steps:

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

The appropriate public and private key files, as well as authorized keys are all created. The contents of ~/.ssh/id_dsa.pub is shown below:

ssh-dss AAAAB3NzaC1kc3MAAACBAMtCKpsSeE8DxjvMqCl2S62YGmR/UMXpLH+tOuCiHzITUnB44kTBfh16WGRjAKdoFcrx/xIZBXyP5YTo1rIGzLbIK+LILOyaIe17mVYWgBs5k5WENLQKwQ3W0kaNvkN+uTcGArDl9r6o8oi8Lnox0ldCp/zGsNZuJfUnCOxX0PthAAAAFQD9wyrHwmyjMKWUhva+pwzhkYjbgQAAAIAqxFHO/Cb834Wa+PcNB80PvcPlwKHMrPnPZcEl+INsNmENU+khLe812GMD8GEsLbLxMgVKlFVAGXT0WUhCYpx7VTeawZ6/dOYlOf44Bjn2z6KAPkQaZyfTzF9gcunDdBY3uHJnOnj9c2bNfMPNc46D5cfPbAov/cNNnue2VWsmtwAAAIEAvJxL25YgbwJdwusIwcVMGjoFj8pRjYKFJwOLvfW1N+UI9u1ZCEkNmuRuOCSRgqDhL0Zr7qv11S8GT4sDdMat6xR7Qhw/Q3NwG4XIOJ5hGoHqlwIleE095JPQnmy8/ffn4qOYPql19RGwTM3lynGVIXBxcIEKzdmeoZKWG3ejS+I= admin-cloud@computer.network.net

However, when I then run a "ssh computer.network.net" or "ssh localhost" command, I am prompted for a password (first problem). After entering the password and establishing the ssh session, I exit and inspect the ~/.ssh/known_hosts file, where the following key has been cached:

localhost ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApHXsA7mMOtqKO1XotKTk5vM5F1LRoqxLLZw2TVLUA36BrkJAMM1EqfnH3mIoNz6sJzOdmQV2ubYGkzvCUb1TX8wUId1KQki8I1l2S52vFEwHkJlFe+KFQcU4SBtxDRDEvHkiLid0D37V+O3W6ElxhhRjkL+nebFPSFEdDlwBUTzAmR3KPD9zFjLP3JJZrwYH1E1sEl52pHbrcr7ROhfRjtz+3glVog9tJC3Xbfwu74JeywYrKQXbtDV84CJ0FoD6WAtJ+V0Dh8hnyBDkdbBc/zVIEDcXfcVNA4yc2noAHdQQ6p11Q8zW94/aJVhi/t0D9vSVMZP8UbHmnM2RfElIww==

which is an RSA key, not the DSA key I generated (second problem). After doing some digging I found this RSA key in /etc/ssh/ssh_host_rsa_key.pub.

Why is SSH using the keys in the /etc/ssh folder and not the keys I generated in the ~/.ssh folder? How can I tell SSH to use the public private key pair in the ~/.ssh folder. A look at man ssh seems to indicate this is the default behaviour but is clearly not happening.

Thanks in advance.

UPDATE

Output of trying ssh -v localhost is verbose but I did find one interesting tidbit:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/admin-cloud/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
Agent admitted failure to sign using the key.
debug1: Trying private key: /home/admin-cloud/.ssh/identity
debug1: Trying private key: /home/admin-cloud/.ssh/id_rsa
debug1: Next authentication method: password

So it looks like it find my ~/.ssh/id_dsa key, gets accepted, and then comes the "Agent admitted failure to sign using the key". After that it looks for ~/.ssh/identity (doesn't exist) and ~/.ssh/id_rsa (doesn't exist) and then finally, just asks for a password. Any idea about that error?

2

The authorized_keys file should contain the public key, not the private one. The following command should have used the id_dsa.pub file instead:

cat ~/.ssh/id_dsa >> ~/.ssh/authorized_keys

The known_hosts file is for host keys, so that is as expected.

Furthermore, try adding one or more -v flags when running ssh, it will print lots of useful info.

Edit: Can you verify what keys ssh-agent has cached by using: ssh-add -L ?

Or run ssh-add (or ssh-add ~/.ssh/id_dsa) to ensure that the file on disk matches its cache and try again.

  • apologies, that was a typo. I am adding the public key to the authorized_keys file. If I had cated the private key it would have a ----BEGIN DSA PRIVATE KEY---- banner across the top – JHowIX Aug 27 '13 at 17:45
  • ssh-add fixed it. Thanks for the help – JHowIX Aug 29 '13 at 21:12
1

Check the value of your IdentityFile configuration variable in /etc/ssh/ssh_config, and ensure it is not overridden by ~/.ssh/config:

IdentityFile ~/.ssh/id_dsa

And, just to be sure (it should be redundant, ssh-keygen creates it with the correct permissions), verify that permissions on that file are 0600, or ssh won't use the file.

Specifies a file from which the user's DSA, ECDSA or RSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2. Additionally, any identities represented by the authentication agent will be used for authentication. ssh(1) will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile.

The file name may use the tilde syntax to refer to a user's home directory or one of the following escape characters: ‘%d’ (local user's home directory), ‘%u’ (local user name), ‘%l’ (local host name), ‘%h’ (remote host name) or ‘%r’ (remote user name).

It is possible to have multiple identity files specified in configuration files; all these identities will be tried in sequence. Multiple IdentityFile directives will add to the list of identities tried (this behaviour differs from that of other configuration directives).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.