Secure Shell (ssh) lets you connect to a remote host and start a shell session just like Telnet. Unlike Telnet, ssh uses cryptography to log in and protect the data flow between you and the remote host.

Setting up ssh access is conceptually involved, but once this is done, ssh is very easy to use. For example: To start a shell session on a remote host you simply type:

SSH can perform many other marvels such as port forwarding: This lets you channel tcp/ip traffic between any selected client and server port through the secure connection. A common use of this feature is to run remote X-Windows programs and have them display on the client automatically.

The following sections deal with understanding and configuring basic ssh access.

SSH supports several encryption mechanisms, but one of the best is based on the RSA public key system.

To use RSA, you need a pair of numerical keys. One key is public: You can pass it out to your friends or publish it in a public directory. The other key is private and must be keep secret.

RSA is a Good Thing™ because it works without ever exchanging private keys over an insecure communication channel, e.g. the internet. It also supports signatures: A person who recieves a message can verify that only you could have sent the message.

First, you need to create a hidden directory in your home directory and set restricted permissions:

Next, run ssh-keygen to create your public and private key files.

The program will propose default filenames for your, public and private key files, which you should accept:

You will also be asked for a passphrase. If you specify a passphrase, you will need to enter it whenever ssh or other programs want to use your private key.

The comment parameter is optional. If you don't supply a comment using "-C", the default is a string derived from your login name and the name of your host formatted like an email address:

The comment appears as plain text in your public key string. When examining an authorization file on a remote server, this text helps you remember who is authorized.

Once you have a key set, you can freely distribute copies of your id_rsa.pub file to anyone who wants to send you secure messages.

The file permissions for private key files must be set correctly or the ssh program will not work. The ssh-keygen program will do this properly, but to set them by hand you would use these expressions:

You must setup your client ssh keys as decribed above. They will be in the hidden .ssh directory in your home directory on the client machine.

Email, ftp or otherwise copy your id_rsa.pub file to your home directory on the remote machine. To avoid confusion, we rename the file "client_rsa.pub". You must append the contents of this file to the authorized_keys file in the .ssh directory at the top-level of your remote home directory.

To do this, you need to log into your remote account by some other means or ask someone who has access to do this for you. This command will append your key to the authorized_keys file:

If you're creating a new .ssh/authorized_keys file, you must set the permissions or remote access will be denied:

If some other user such as "root" does this for you, they also need to make sure that you own the file:

Similarly, the remote .ssh directory must have the correct permissions and owner:

Here's a quick check on how the .ssh directory should look:

The above listing shows the known_hosts file, which is automatically created and/or updated whenever remote clients connect to this account.

By adding a "config" file to your .ssh directory, different configuation options and defaults can be set for each host you commonly use. Here is an example .ssh/config file:

By specifying a username as shown above, the command line for remote login becomes very simple:

Most of the options you can specify system-wide for the ssh client in /etc/ssh/ssh_config may alternatively go in your local .ssh/config file, elminating the need to modify the system defaults.

Permissions for the config file should be 644.

An entire host machine may have a key set. The public part of this key is kept on remote servers to authorize access by the entire machine. Many services can be configured to use host-level authorization.

Host keys should be located in:

The automatic installers for many Linux distributions create the host key files in /etc/ssh automatically.

To create them by hand, run ssh-keygen and specify the path names shown above. Passphrases are not normally used with host keys.

The ssh client package is usually bundled with the scp (secure copy) program. This allows you to copy files between hosts using the secure ssh protocol. To use scp, you must have the keys properly configured as described in the previous sections.

The syntax is similar to the regular cp (copy) command, but the source and destination path may have an optional prefix to denote the host and username associated with the access keys.

To copy a local file to a remote host where you have an account with the same username as your local session:

To copy the file to some other user's account:

The general syntax is:

If the path names are not absolute, they are relative to the login directories for the designated users.

Newer linux distributions are configured to require SSH authorization for remote X clients. In this document, see "SSH access with RSA keys" for details about creating and using keys.

When using RSA, you still need the ip name or number of each client machine in the server's Xaccess file.

The X server has a file that contains the SSH public keys of each user and/or entire client machines that are allowed to connect:

If you create this file, you must set the permissions:

You don't need to authorize the whole client if you only want to allow selected users on that client.

Public keys are copied or mailed from the client machines. A special public and private key set may be created for the whole host. It is kept in:

You append the contents of this file to the server's kdmkeys file to authorized everybody on the whole client.

Public key files for individual users are found in:

Simply append the contents of this file to the server's kdmkeys file to authorize this user.

With all the setup completed, you can login to the remote machine using ssh and run X-Windows programs. The display will be automagically sent back to your machine!

UPDATE: Newer Redhat/Fedora systems need some additional setup on the client side: In the file /etc/ssh/ssh_config you must add these directives:

Without these changes, you would have to login to the server using ssh with the "-Y" switch to enable access by a trusted host.