Print-friendly Version

Setting Up SSH For No Password

Peter Cvar, April 2006

This setup will allow you to log in to another account without having to provide the password.

man ssh-keygen is a start, but it might need some clarifying for beginners.

This Tech Tip concentrates on SSH2, the second version of SSH. Don't use the first version any longer; it contains security bugs. Also, older versions of the second version might contain security bugs. Check with ssh -V that your version matches the latest one available from OpenSSH.

If you can't find any of the SSH commands (ssh and scp, for instance) on your system, get the SSH package first and install it. This suite should also install the ssh-keygen command on your machine. Make sure that SSH is installed on every system that you want to access. Starting from the Solaris 9 OS, SSH is included in the distribution.

If you can't find a package suitable for your version, refer to the OpenSSH web site for the source, and then download, unpack, read the README, compile, and install. Systems missing OpenSSL have to add that package as well for SSH to work. Test, for example, ssh localserver; this will create a .ssh subdirectory in your home directory.

In your ~/.ssh directory, create your personal SSH key:

server1:~/.ssh> ssh-keygen -t dsa

If you want to enable remote connections that don't require a password, do not enter a passphrase. If you do enter a non-empty passphrase, when connecting to the remote server you will be asked for the passphrase instead of the password!

Append the public key to the file authorized_keys2:

server1:~/.ssh> cat id_dsa.pub >> authorized_keys2

Don't worry if authorized_keys2 does not yet exist before you execute this command.

Sun provides SSH in the Solaris OS starting from release 9, but uses SSH version 1 naming conventions. On the Solaris 9 OS, use the authorized_keys file instead of authorized_keys2.

Now you should already be able to make a secure connection to your own machine, using this account, without having to provide a password.

Check permissions on your keys and refer to the man page. The id_dsa file should be private, the other keys world readable. On the remote server, generate keys in the same way for your account on that server.

Copy your public key into ~/.ssh/ on the remote server.

server1:~/.ssh> scp id_dsa.pub server2:/your/remote/home/.ssh/server1.key.pub
user@server2's password:
id_dsa.pub            100% |*****************************|   236       00:00

Do the same thing for the remote key; copy it into your local ~/.ssh directory:

server1:~/.ssh> scp server2:/your/remote/home/.ssh/id_dsa.pub ./server2.key.pub
user@server2's password:
id_dsa.pub            100% |*****************************|   236       00:00

On both servers, append the key from the other server to the file authorized_keys2:

server1:~/.ssh> cat server2.key.pub >> authorized_keys2

And also for the second server:

user@server2:~/.ssh> cat server1.key.pub >> authorized_keys2

That's it! Try to connect to the remote server now. It should do something similar to this:

server1:~/.ssh> ssh server2
Last login: Mon Nov 21 16:23:26 2005 from :0
user@server2>

If things don't work, check the logs, possibly in /var/log/secure. This file contains useful information, such as:

Nov 21 10:24:41 ocean sshd[26446]: Authentication refused: bad ownership or 
modes for file /home/name/.ssh/authorized_keys

Most likely, the problem is too many permissions.

By default, the Solaris OS doesn't allow ssh as root. Edit /etc/ssh/sshd_config and change the PermitRootLogin directive. Restart sshd for these changes to take effect.

Also on the Solaris OS, make sure that you use the file ~/.ssh/authorized_keys, without the two suffixes. The Solaris OS uses version 2 of ssh but without the version 2 naming convention.

A typical entry in ~/.ssh/authorized_keys(2) looks like this:

ssh-dss FGKJTJUVFMAAACBAOk6t1czfh7nV9sb0syK1CebJ/6nwLb9OPLr0LcqcE1J8GYbePDVfg\
erUIJSpn1UDmujH8emiLR30y9BQN9JU+XmEc5Ab1rrwHWEMahWgZANgEmQt4FmgBNfv+BFGn/tRmd\
cHX07mauLbAB3Uf8sIHJHK57659KHJL8473JUHFRT39uBxv1HAAAAFQCoRN6CXBpYH5VjOzbO4Euj\
cTdXkQAAAIAMUxdVJ6CAFE54a3mdvVO0OWOzhvS8w0iCBbZMdDbzqxmqEexAh8PHaZM5oMN1VzhO9\
HX7qxjlZCqffzZOwepOMPWv5pWabtEf5hfWa4xb4QkLqZC42JhHtUr7KUUnJwkvaoLwKjOcWERAQY\
5anvABcUE/h5CbOS4fh0M21lPdnAAAAIBaZuS3a2qdrtYX/fJ72Bp1kAt9qDq7apMOnA0m4Vireiu\
t433qchgBrvfYBpNyuJ0OXMVLciingYkfAs7a6nl8avMmW3LM37Gkgt06LP+hfdgetsdhsyHAd7dl\
SS9VV1wDloE1fwkJSjtSLbdeJSliu3liu43uztu4u34zutNMI7== name@email.com

If you can't connect to a remote server using a particular user name on that server, check that the appropriate key is in your authorized_keys(2) file, and that the remote server name, encryption method, and user name exist.

Use ssh -v, scp -v or sftp -v to display verbose output and analyze any other problems that you might come across.

The information and links on this page have been provided by a BigAdmin user. The submitter is solely responsible for such information and links. Sun is not responsible for the availability of external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. Sun will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss caused by or in connection with use of or reliance on the information posted here, or goods or services available on or through any external site or resource.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.