Overview
In many circumstances, it is simply not feasible to manually type in the password when connecting to a remote system using ssh. Examples include automated scripts, and central management, where one central computer may be administering hundreds of machines.
Use of this procedure also can increase security in most cases, as it encrypts multiple passwords under a single local login, thus requiring a single password to be remembered and avoiding multiple passwords being written on scraps of paper around the computer, and being frequently typed.
Scenario
The following steps assume that you are sitting at a central machine which will be connecting automatically to many remote machines.
Simply use the real names for your particular setup in place of:
- <local-user>your user name at the local computer
- <local-host>the host name of your local computer
- <remote-user>the user name that you connect to the remote computer as
- <remote-pass>the remote user’s password on the remote system
- <remote-host>the host name of the remote computer
You type the bold lines, the computer responds with the rest.
Set Up Your Local System Once
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<local-user>/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<local-user>/.ssh/id_rsa.
Your public key has been saved in /home/<local-user>/.ssh/id_rsa.pub.
The key fingerprint is:
62:a5:fc:a4:b0:d8:87:f0:98:28:17:d4:e3:8e:aa:2f <local-user>@<local-host>
$ ls ~/.ssh
id_rsa id_rsa.pub known_hosts
Set Up Each Remote Host
$ scp ~/.ssh/id_rsa.pub <remote-user>@<remote-host>:<local-user>_<local-host>.ssh
<remote-user>@<remote-host>’s password:<remote-pass>
id_rsa.pub 100% 227 824.0KB/s 00:00
$ ssh <remote-user>@<remote-host>
<remote-user>@<remote-host>’s password:<remote-pass>
$ cat ~/<local-user>_<local-host>.ssh >> ~/.ssh/authorized_keys
–> [Note: if the above step fails, it is probably because the ~/.ssh directory does not yet exist, in which case:
–> $ mkdir -m700 ~/.ssh
–> and then re-run the previous step.]
$ chmod 644 ~/.ssh/authorized_keys
$ ls -l ~/.ssh
total 8
-rw-r–r– 1 <remote-user> <remote-group> 227 Feb 23 14:27 authorized_keys
-rw-r–r– 1 <remote-user> <remote-group> 222 Dec 13 02:13 known_hosts
$ exit
Connection to <remote-host> closed.
$ ssh <remote-user>@<remote-host>
Last login: Thu Feb 23 14:26:00 2006 from 192.168.1.67
Access to, or unauthorized use of data on this computer by any person other
than authorized employee(s) or owner(s) of an account is strictly prohibited
and may result in legal action against such person.
$
If Something Goes Wrong
Usually the problems have to do with file permissions and can be fixed with chmod in ~./ssh locally or remotely. The writers of sshd are extremely picky about file and directory permissions, and will not warn you if you fall afoul of their paranoid obfuscation. There is no excuse for such poor treatment of their users. The ~/.ssh directories on both local and remote machines must be owned by the user who’s home directory they are in. These directories need to be chmod 700. The files within should also be self-owned, and have permissions 644. To get more information about the problem, use ssh in verbose mode, as in:
ssh -v <remote-user>@<remote-host>
If this is not informative enough, you can also run the daemon on the server in debug mode as follows:
You need be root, then stop the running daemon:
/etc/init.d/ssh stop
* Stopping OpenBSD Secure Shell server sshd
Then run a debug version of the daemon:
/usr/sbin/sshd -d
Now try to connect from the client again. You will see lots of diagnostic information about the failure on the server console.
When you have finished, exit the daemon (ctrl-C) and restart the normal sshd server:
/etc/init.d/ssh start
Script to automate all of the above
Here is a bash script to automate all of the above. To use it, download the following file. You may have to right-click -> save link as if your mime types do not support shell scripts. The file should end up as ssh-pwd in your home directory ( i.e. ~/ssh-pwd ) and should have execute permission ( i.e. chmod 777 ~/ssh-pwd )