Hi, Am 06.04.2010 um 09:48 schrieb Terry Frankcombe:
>> 1. Run the following command on the client >> * -> ssh-keygen -t dsa >> 2. File id_dsa and id_dsa.pub will be created inside $HOME/.ssh >> 3. Copy id_dsa.pub to the server's .ssh directory >> * -> scp $HOME/.ssh/id_dsa.pub user@server:/home/user/.ssh >> 4. Change to /root/.ssh and create file authorized_keys containing >> id_dsa content >> * -> cd /home/user/.ssh >> * -> cat id_dsa >> authorized_keys >> 5. You can try ssh to the server from the client and no password >> will be needed >> * -> ssh user@server > > That prescription is a little messed up. You need to create id_dsa and > id_dsa.pub on the client, as above. > > But it is the client's id_dsa.pub that needs to go > into /home/user/.ssh/authorized_keys on the server, which seems to be > not what the above recipe does. > > If that doesn't help, try adding -v or even -v -v to the ssh command to > see what the connection is trying to do w.r.t. your keys. inside a cluster I suggest hostbased authentication. No keys for the user, a common used ssh_known_hosts file and a central place to look for errors. Passphraseless ssh-keys I just dislike as they tempt the user to copy them to all remote location (especially the private part) to get more comfort while using ssh between two remote clusters, but using an ssh-agent would in this case be a more secure option. -- Reuti > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users
