Hi,

I have been using ssh automation (in a rocks cluster) by using the id_rsa.pub in authorized_keys file. It was working fine for last one year.

Recently, I tried to automate the connection from my laptop to the cluster, and I found that it didn't work. But, to my horror, the whole ssh automation didnt work, for any machine that is connecting to or within the cluster. I now needed to type 10 passwords for a job that requires 10 CPUs!!
I tried removing the .ssh directory, and creating a new authorized_keys file. But, no vain. Then, finally, I asked the system admin to delete and re-create my user id. Now it works flawlessly. Can anyone tell me what happened out there? Did the ssh server mark my user name as some security threat?

Though I solved the problem, I required the admin to do the stuff of re-creating my login id. But, is there a way to do it myself??

The authorized keys and known_hosts entry in the servers contain the userid and hostname of the client or maybe an ip address. ( The end of Authorized_Keys and the beginning of known_hosts ). Since you changed this by using another computer, you needed to enter your password.

There may also have been a dns lookup, depending on the server's configuration. If you usually connect from a host that has an entry in your networks nameserver, or the hosts /etc/hosts file, and this time you didn't, that could be a problem.

Also if the permissions of your private key in ~/.ssh/ are publicly readable, you won't be able to use the client at all.

Most often it's a permission issue. E.g., on the "server" where sshd runs, you must own ~, ~/.ssh, and ~/.authorized_keys, and they must only be writable for yourself. By design you won't get any hint as to what is wrong on the other computer where you run ssh (the "attacker", e.g., your laptop). Problems are logged on the server. E.g., /var/log/auth may contain a line like this,