My Favorites


Please to see your favorites.

  • Bookmark
  • Email Document
  • Printer Friendly
  • Favorite
  • Rating:

Tips for generating keys for sshd

This document (7000350) is provided subject to the disclaimer at the end of this document.


Novell openSUSE
Novell SUSE Linux
Novell SUSE Linux Enterprise Server 10
Novell SUSE Linux Enterprise Server 9
Novell SUSE Linux Enterprise Desktop 10
Novell Open Enterprise Server (Linux based)


Setting up Public/Private keypairs for SSH authentication between machines can be a thirty-second job or a long arduous research project to figure out the correct options to use. The key-based authentication technology is especially useful when making regular connections between machines and anywhere a connection needs to made when a password cannot be provided securely.


The basic principle behind Public Key authentication is very similar to regular password-based authentication. For any authentication to work the client must prove it is whom the server thinks it is. Typically a username and password are provided from the client to the server which the server compares against its copy of the same.

Public key authentication works on the same general principle but instead of a username and password you have a username and a private key's ability to encrypt and sign data used to authenticate to the server holding the username and the public key. The details of public/private key encryption are outside the scope of this TID and are documented online extremely well but suffice it to say that these "credentials" sent to the server prove an identity in a way similar to username and password.

When an SSH client authenticates to serverA as user 'john' the SSH server checks in a directory for a stored Public Key to verify the Private Key coming through the connection if one exists. The default directory on most distributions for the Public Key is in the destination user's home directory (~) in the ./.ssh/authorized_keys file. This file is just a plain text file holding Public keys of identities who should be able to authenticate as the remote user for the remote system. In the example above the SSH server would check in /home/john/.ssh/authorized_keys for a Public key matching the SSH client's Private key. If none exist the server will continue and usually prompt for a password for the user 'john' if password-based authentication is not disabled. If the key matches one stored in the ~/.ssh/authorized_keys file then the authentication is completed and the user is granted access.

On the client side Private keys are used and must be kept as safe as possible. Having somebody get access to a Public key is not that important because nothing can be done with it to give them access go a system; however a Private key's disclosure means whomever has that key immediately has the ability to authenticate anywhere the key's owner can just like when a password is found by a third party. The private keys are typically stored in the user's home directory in ~/.ssh. For our example user the keys would be in /home/john/.ssh/ and are usually named id_rsa or id_dsa. An or file is created when creating keys which is the corresponding Public key to be put on the remote server.

To create the Public/Private keypair the command 'ssh-keygen' is available as part of the SSH package. There are two types of key encryption which can be used including RSA and DSA. Both are considered secure though there are some limitations to using DSA. Currently DSA technology rules require a 1024-bit key. Depending on your SSH implementation this rule may or may not be followed to the letter allowing stronger keys such as ssh-keygen's default of 2048-bit keys. Because some versions of SSH do not allow DSA keys that are not 1024-bit for stronger encryption the RSA keys may be preferred. To create a key use the following syntax:

ssh-keygen -b -t

Substitute with a number representing the number of bits in the key. 2048 is the default and should be the minimum used. The can be either 'rsa' or 'dsa' (technically 'rsa1' is valid for SSHv1 connections but nobody should be using those anymore). When prompted to enter a passphrase enter one that you will remember as it will be required to access your Private Key and is used to secure this key from unauthorized use in case the key is stolen. Both Public and Private keys are stored in the ~/.ssh directory by default. The Public key should then be put on the server into which you will authenticate. The placement depends on which identity will be used on the remote machine but in any case it will go, by default, in that iuser's home directory at the following location:

/home/remoteusername/.ssh/authorized_keys #for a regular user
/root/.ssh/authorized_keys #for the root user

Keep in mind that you can have multiple keys in this file for multiple users to get in as the same remote identity so overwriting this file may not be desired. If you know there are already keys in this file simply append the new key to the end of the file. Another way to set this up is to use the 'ssh-copy-id' command which is made to copy the identity from the SSH client machine to the server to be accessed. The easiest way to use it is to first run `ssh-add` to add the identities on yoru client into the SSH agent (see more details on this command below). Once the SSH identity is ready in the SSH agent (via 'ssh-add') run `ssh-copy-id username@remotebox` and enter the user's password when prompted. The script will read your identity and copy it over to the remote system's user's authorized_keys file properly (appending instead of overwriting, fixing up permissions, and creating directories if necessary). This should prevent problems caused by overwriting authorized_keys files accidentally. The script can also accept an "identity" file from the command line explicitly with the '-i' switch to specify the path to the public key that will be copied to the remote system.

To have the SSH client use these keys simply the 'ssh-add' command. This will go through your ~/.ssh directory and look for private keys named 'id_dsa', 'id_rsa', or 'identity', and you can also specify other files explicitly to be loaded. See the 'ssh-add' man page for more details. When these keys are loaded you will be prompted once for a passphrase which is stored on the key for security reasons in case the private key is lost. All keys loaded can be viewed by running `ssh-add -l`.

With everything accomplished the following command should get the date from the remote server without any prompts:

john@localhost:~> ssh serverA date
Fri May 9 15:37:21 MDT 2008

Additional Information

Information regarding DSA support change due to a lack of an established standard

Algorithm Information: DSA

Algorithm Information: RSA

A wealth of additional information is available by querying for 'ssh key' or reading the man pages for the various SSH components.


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7000350
  • Creation Date:09-MAY-08
  • Modified Date:30-APR-12
    • SUSESUSE Linux Enterprise Desktop
      SUSE Linux Enterprise Point of Service
      SUSE Linux Enterprise Real Time Extension
      SUSE Linux Enterprise Server
< Back to Support Search

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center