@Trent > the 1024 RSA has already been cracked. Yeah but unless you've got 3 guys spending 100 hours varying the voltage of your processors it is still safe... :)
On Tue, Apr 6, 2010 at 11:35 AM, Reuti <re...@staff.uni-marburg.de> wrote: > 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 > > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users >
