Tips for generating keys for sshd
This document (7000350) is provided subject to the disclaimer at the end of this document.
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)
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 id_rsa.pub or id_dsa.pub 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:
/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
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 DesktopSUSE Linux Enterprise Point of ServiceSUSE Linux Enterprise Real Time ExtensionSUSE Linux Enterprise Server
Did this document solve your problem? Provide Feedback< Back to Support Search