Home Wiki > SDB:OpenSSH public key authentication
Sign up | Login

SDB:OpenSSH public key authentication

tagline: From openSUSE

Icon-update.png Update to version: 13.2
This article needs to be tested for a newer version. If you are using this guide on the newer version and you find the guide up-to-date to this version, please add the version number to the Knowledge bar. Please refer to version related jobs: SDB pages for more information.
This article describes the various ways off setting public key authentication, for ease of use or to obtain more security. Basic knowledge about the ssh syntax and setting are required. For custom settings one might need to be able to log in as root.
Tested on openSUSE Recommended articles Related articles

Icon-manual.png Icon-help.png


Public key authentication allows you to log in on the server, without a server-side password. The key pair is generated on the client side and the private key must be stored in a secure place. The public key is send to the server and stored in the “authorized key file”. Meaning that the computer (and user) holding the private key can sign in to the computer holding the public key. One can even choose to disable keyboard interactive login completely, as mentioned above. Be careful not to do this before you have set, created, uploaded and tested your Public Key Authentication! You might lock yourself out.

Disabling Password authentication on you SSH server, will dramaticly improve security. A password can easily be compromised by systematic attacks. Password are small compared to Public keys.

How it works

Before any authentication is performed, an encrypted connection is established. After this, the client will receive a list of possible authentication methods. If this includes "publickey" and a key pair is found in the .ssh/config directory, an encrypted signature is send.

This signature consists of data known only to both hosts and will be encrypted by your private key.The server will try to decrypt the signature, with the corresponding public key stored on the server. If this succeeds and the data is valid, authentication is successful and you will be granted access. If this attempt is unsuccessful (eg. no key pair set, or not yet uploaded to server) other authentication methods will be tried. (Password or Hostbased)

Choice of key type

You will be able to choose between to key types: DSA and RSA. If it comes to security, there is not a big difference between the methods (if both keys where the same size). DSA has a fixed size of 1024 bits and RSA can be any size more than 768 bits.

Until September 21, 2000 the use of RSA was restricted by a Patent, but it has been released to the public domain just two weeks before that, meaning no restrictions apply in the use of RSA.

The length of the key determines the strength. The default key length for RSA is 2048. Bigger is also possible, making RSA the most suitable key for authentication.


As said before: how longer the key, the more secure it will be. But this is not the only concern we are facing in security. If someone would have access to you client's file system and read your private key, he can steal your identity to log into any hosts you have set public key authentication fore. The principle is very simple: anyone may know your public key, but only your must know your private key.

This is the reason why your ~/.ssh directory should always be:

$ ls -al ~
drwx------ 2 timus users 95 Jan 11 07:42 .ssh

This means "timus" is the owner of the directory, and only he can read/write in it. No one else can read or write in this directory. When you are generating a key, the directory is automatic made for you, with proper permissions. If permissions are not correct, ssh will bail out when you invoke it.

Key passwords

You can choose to use public key authentication for security, or for the ease of not having to type a password every time you log on. The secure way would be: use public key authentication with a password protected key and disable Password authentication on the server. This will make you server less vulnerable for systematic attacks. If you are sharing your workstation or home file system with other users, this would be the best method. Eg. keep your system's administrator out of your private business.

However, if you are using ssh within your private network, or you are not sharing your workstation with anyone else, you can choose not to set a password for your key pair, and use it for easy connections all the time.

SSH Agent

You can also choose to use SSH Agent. This will make the use of password protected keys easy for you. You will have to enter the password the first time you use it in a session and sshagent will keep it open for you untill you logout. This gives you the opportunity to connect and disconnect to the remote host(s) all the time, without having to type the password again.

Key generation

If ssh-keygen is used without any arguments, a 2048 bit RSA key will be generated. The private key will be stored under ~/.ssh/id_rsa and the public key under ~/.ssh/id_rsa.pub. Based upon your needs, you can choose to set a password. Leaving the lines blank will cause no password to be set.

$ ssh-keygen
Enter file in which to save the key (/home/your_user/.ssh/id_rsa): <Enter>
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
Your identification has been saved...\

Custom key pairs

You might want to use a different size of key (bigger or smaller), DSA or save your key under a different name.

To create a RSA key pair with size 1152 under name /home/your_user/.ssh/my_id:

$ ssh-keygen -t rsa -b 1152 -f ~/.ssh/my_id
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
Your identification has been saved in /home/your_user/.ssh/my_id.
Your public key has been saved in /home/your_user/.ssh/my_id.pub.

If you want to use DSA, you are limited to a 1024 bits key size.

To create a DSA key pair with size 1024 under name /home/your_user/.ssh/id_dsa:

$ ssh-keygen -t dsa -f ~/.ssh/id_dsa
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
Your identification has been saved in /home/your_user/.ssh/id_dsa.
Your public key has been saved in /home/your_user/.ssh/id_dsa.pub.

Upload your key

In order to use your generated key for authentication, your public key is to be uploaded. If you did not create a custom key pair, as mentioned above, issue:

$ ssh-copy-id user@ssh.yourserver.org
Now try logging into the machine, with "ssh 'user@ssh.yourserver.org'", and check in:
to make sure we haven't added extra keys that you weren't expecting.

The 'user@' part can be omitted if you want to use the same username as you are currently logged in to.

Custom key pairs

If you used one of the above examples to create a custom key, you should use the -i ~./ssh/my_id.pub option, where my_id.pub is to be replaced by your custom key name (Eg. id_dsa.pub).

$ ssh-copy-id -i ~/.ssh/my_id.pub user@ssh.yourserver.org

Custom settings

OpenSSH accepts public key authentication by default. You only need to alter the following settings if you are using a custom keypair or if you want to disable Password authentication completely.

SSHD settings (server)

Warning Since openSSH 5.4 (which comes with openSUSE 11.3), relative paths in configuration are no longer allowed. When pointing to the authorized_keys file make sure you use %h/ in front of the path. Older versions still can do without.

Edit /etc/ssh/sshd_config (as root) on the server and un-comment options you would like to change. If you like to make sure Public key authentication is used, or change it to no here if you would like to disable this completly:

PubkeyAuthentication yes

To change the path and file name to look for authorized keys. Note that the ssh-copy-id<tt> command still imports to <tt>%h/.ssh/authorized_keys file, even is this settings is changed. (Client software can't read sshd_config) :

AuthorizedKeysFile %h/.ssh/authorized_keys

Disable Password authentication

If you are going for that extra bit of security, you can choose to disable Password authentication completely.

Warning Make sure a public key is already uploaded to your server and tested, before using the following settings, you may lock yourself out!

The following settings should be already in place. Because openSSH uses PAM in openSUSE, PasswordAuthentication should always be disabled.

PasswordAuthentication no
UsePAM yes

The ChallangeResponseAuthentication option is used instead. (You are being challenged to supply a PAM worthy password.) Set this option to no to disable password authentication.

ChallengeResponseAuthentication no

Save the file and restart the SSHD.

$ /etc/init.d/sshd restart

Read the Renew keys section if you want to upload a new key while Password Authentication is disabled.

Setting SSH

If you want to use DSA or any other custom key name (or path) edit the system wide configuration file /etc/ssh/ssh_config as root on the client. Uncomment and change the following option to your needs:

IdentityFile ~/.ssh/my_id

Renew keys

If you feel your key is being compromised or you are just plain paranoid, you might wish to renew your key pair. If you are still using Password authentication, you can proceed like the workflow above. This will overwrite your current key pair and upload your new key to the server (for which you will need to enter a password). Afterwards you can log in and edit ~/.ssh/authorized_keys to remove the old key(s).

More care is to be taken when you can not use Password authentication any more. You will need to create a new key under a temporary name, upload it to the server, then use the new key pair to overwrite the old one:

$ ssh-keygen -t rsa -f ~/.ssh/new_id_rsa
$ ssh-copy-id -i ~/.ssh/new_id_rsa.pub user@ssh.yourserver.org
$ cd ~/.ssh
$ mv new_id_rsa.pub id_rsa.pub
$ mv new_id_rsa id_rsa

Now log into the server to remove the old key from ~/.ssh/authorized_keys.

Trouble Shooting

Public key authentication is not working anymore

Version: 11.3+The following applies starting from openSUSE 11.3.

Since openSSH 5.4, relative paths in configuration are no longer allowed. When pointing to the authorized _keys file make sure you use %h/ in front of the path to your authorized_keys file. Older versions still can do without. In /etc/ssh/sshd_config change:

AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile %h/.ssh/authorized_keys

See also

Related articles

External links