Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
1. Firstly, generate your public/private keys using ssh-keygen
% ssh-keygen -t rsa
You must use the -t option to specify that you are producing keys for SSHv2 using RSA. This will generate your id_rsa and id_rsa.pub in the .ssh directory in your home directory. I strongly suggest using a passphrase.
2. Now copy the id_rsa.pub to the .ssh directory of the remote host you want to logon to as authorized_keys2 . [Note: If you have more than one host from which you want to connect to the remote host, you need to add the local host's id_rsa.pub as one line in the authorised_keys2 file of the remote host, i.e., you can have more than one entry. Thanks to Jinn Koriech for pointing out that this isn't obvious.Also you need to 'chmod 644 authorized_keys2' to make it unwritable to everybody apart from the user. Thanks to Matthew Lohbihler for making this known. ] You are basically telling the sshd daemon on the remote machine to encrypt the connection with this public key and that this key is authorized for version 2 of the ssh protocol. Try using something secure like scp for this copying.
3. Your public key based authentication has been setup. You won't be asked your password on the remote machine. However, you need a program that manages your keys for you called an agent. You need to start the agent, tell it your passphrase, and hook up to the agent whenever you need to connect to the remote machine.
4. We shall assume the following situation: You logon to a console and then startx as in say, an out-of-the-box Linux installation. You should figure out what exactly has to be done for your specific machine's X initialization. All the following steps are to be done on your local machine, in this case- localmachine.secondmachine.
5. Fire your favourite editor, and pull up your .profile file. Add the following line to the file:
alias startx='ssh-agent startx'
This means that every child of startx (i.e. anything under X) would be able to hookup to the agent.
6. Edit your .xinitrc file by adding the following lines:
# Change this to whatever window manager you use under X
# or leave whatever was there unchanged.
startkde
.xinitrc is the init file for X. Unfortunately, as ssh-add doesn't have a controlling terminal, it needs to be told to read input from an external source. When you specify, /dev/null, the program pops up a d-box program specified by $SSH_ASKPASS and ask you for your passphrase. The d-box can be as simple as an xterm, but you could use the x11-ssh-askpass that comes with your openssh installation. The DISPLAY is usually automatically set, but just in case.
Nota Bene: If you had to create .xinitrc, then you must add something after the ssh-add statement to start the window-manager/desktop/whatever. Otherwise, X will simply terminate after asking for the password. If you don't know how to set this up, you might want to dig in your /etc/X11/init.d files for the appropriate init sequences.
7. Now when you startx, a dialog box should pop up and ask you for your passphrase. You are all set. Open up an xterm, and say
% ssh secondmachine
Voila ! You'll be logged in without typing in your password. You'll have to re-enter your passphrase, everytime you start X. The passphrase can be side-stepped by giving the empty string, but I'd rather you don't.
8. As a fringe benefit, you can execute any GUI based programs on the remote machine for free, no setting up $DISPLAY , no need to xhost+ etc. Cool, eh ?
Is it the standard password prompt? (user@machine's password: )
On the server, is AuthorizedKeysFile option set in /etc/ssh/sshd_config? It may be that the ~/.ssh/authorized_keys2 file is not being processed. That file is depreciated in openssh v.3.
What versions of ssh are on each machine?
If that doesn't help, can you post the output of ssh -vvv user@machine (ssh -vvv 2>debugfile ) and cancel when you get the password prompt. I don't think it has anything sensitive in it, but you should check first. (a public key fingerprint, i think, and you can redo your keys after you get it working :) )
I'll take a look, and see if I can't reproduce your log. I've been intrigued by the key system lately.
quote:
----------
Note: If you do have write permissions for either the .ssh directory or for the authorized_keys file on the remote machine, then sshd will consider that the procedure is not safe enough, so it will abort the RSA challenge-authentication mode (mode 3) and will go to the default mode (mode 5) asking you for the password on the remote machine.
----------
Last time I was failed because I did 'chmod 644 authorized_keys2'
but not the the ~/.ssh it self.
I fixed it and ssh-without-password is working fine now.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
