GeodSoft logo   GeodSoft

A Beginner's Guide to SSH Clients

This section assumes that there is a working SSH server, normally sshd, running on the computer that you want to connect to. Before dealing with specific clients, I'll cover some things common to all ssh clients.

As a client, you need to know if the SSH server you wish to connect to allows password authentication. If so the ssh client is very easy to use. If your username is the same on the remote system as the current system, from a UNIX prompt simply type "ssh hostname" where hostname can be a name or IP address. If you want to connect as a different user simply type "ssh username@hostname". For Windows clients connecting to an SSH server that allows password authentication, just provide your username on the remote system and the hostname or IP address of the server, in the appropriate text entry fields. When ssh connects, it will display your username@hostname where hostname is the computer being connected to and prompt you for your user password.

If the SSH server does not allow password authentication, then the client setup is more involved because a pair of cryptographic keys needs to be created and placed in the proper locations. The keys, how they are created and what goes where may be the most confusing thing about ssh for new users. There are both client key pairs and one or more server key pairs. The client user does not need to know about the server keys except in a very superficial manner.

The client user does very much need to be concerned about the client keys. It's possible for an administrator to create these for you but it's much better if you create these yourself. On UNIX and UNIX like systems the program for this is ssh-keygen. Normally it's installed with the system and available to all users on the path. If not, you'll need to be an administrator or have one install the ssh client software for you. With Windows, the key generation program may be separate, like Putty's, puttygen.exe, or may be a menu selection like MindTerm's "Create RSA Identity" under the file menu.

For each of these programs you need to supply some information which will be covered shortly. Then these programs create two key parts. One is called the private key and the other the public key. The default name for the key parts are identity for the private key and for the public key. The private key is about 530 bytes long and filed with non displayable characters while the public key is about 330 bytes and mostly a very long number. The private key goes (stays) on the system from which the client connection will be started. The public key goes on the remote system that you will connect to via ssh. Normally on UNIX systems, the public key becomes one line in .ssh/authorized_keys located in the user's home directory on the remote system.

You should think about how many key pairs you may need or want. This will vary depending on where you expect to be using ssh. If you only have one ssh client system and one sshd server then you only need one pair. You may instead have one client system and several or many sshd servers or several clients and also several or many sshd servers. It's possible but less likely to have several clients and only one sshd server to log into. If anyone else has any access to any of your client machines, it's a bad idea to share private keys between different client computers. To me, it makes sense to have one private key for each client machine and to share the public key with all the remote servers that you will be logging into from that client. The private key should be protected with most restrictive access permissions the operating system allows. Only you, as the owner should be able to see or do anything with the private key.

One question all the key generation programs will ask for is a passphrase that must be typed twice to be sure it does not contain a typo. The typed characters will not be displayed; with some programs, the cursor won't even move, i.e., there is no visual indicator how many characters have been typed. This passphrase is used by the ssh client programs, not by the system you are logging into. It should not be the same as your password on the client computer on which it's used; if it is, anyone who cracks or guesses your computer password will then have access to your private key and most likely every system that you access from that client computer via ssh. If you have more than one remote computer you access, it can't be your remote system password (unless you share passwords among the systems). It's rather pointless to use a "secure" technology if you render it insecure by using the same password repeatedly.

I have no idea how easy or hard it is to crack RSA passphrases compared to typical host passwords but it seems reasonable they should be created like other good passwords. They should have a mixture of letter case, numbers and symbols or punctuation and should not consist of mostly dictionary words or items easily related to you personally. If your ssh / RSA passwords are strong and not used frequently, they are likely to be forgotten, like any other password. You could regenerate the key pairs but that would be a nuisance. If passwords are written down, they need to be kept in a secure location not easily matched to the private key. That is, don't store the passphrase electronically on the same computer the private key is on. Any one who gets both your private key and your passphrase has a very good chance of accessing the computers you use them for and anything they do, will likely be logged as having been done by you.

It should be obvious by now, why it's a bad idea for a system administrator to create key pairs for users. On any multi user system, they will automatically be able to access the private key. The only thing that prevents them from being able to use the private key as you, is lack of knowledge of the passphrase. If they create the key pairs, they will have that as well.

The key generators typically give you a chance to change the default name, "identity", to something else. On UNIX systems, the ssh client will default to looking for this file so it's best to leave the default name. As soon as the keys are saved, rename the public key, "", to (or something similar). As this key will be moved to other systems, this will help keep track of where it was created and where it should be used. If you follow my suggestion and create a key pair for each client, the username and hostname are the local client user and hostname on which the key pair is created and from which the SSH connection will be originating.

The last piece of information that the key generators may ask you for is a comment which will be included at the end of the public key. The UNIX like systems do not ask for this and automatically use username@hostname as the comment. On the systems that ask, you should provide similar information. If you follow my previous advice, the comment and filename will closely correlate but the filename will eliminate the need to check the file contents. Having several's around is likely to be confusing and may require re-transferring information if's are not immediately added to your .ssh/authorized_keys file.

If you have physical access to the remote host, you can put your public key on a floppy or e-mail it to yourself and then add it to your .ssh/authorized_keys file. If you do not have physical access, then you will need to send your public key to the system administrator and ask that they add it to your authorized_keys.

Often, systems running SSH servers have host restrictions or will be behind a firewall with host access restrictions so that in addition to the proper keys, only specific hosts or networks are able to access the SSH server. If you're not also the administrator, you may need to give them your IP address, or address range if you have a dynamic IP address from an ISP or DHCP, and request that they add this to /etc/hosts.allow or whatever host control mechanism is in place.

After the client specific pieces are added to the remote host, you can try to log on with your ssh client. On UNIX like systems, "ssh IP" or "ssh hostname" should work. If you want to login with a different user name use "ssh username@hostname. On Windows clients you will need to provide the location of the private key, your remote login name, perhaps the connection type and perhaps some connection parameters.

When an ssh client connects to the sshd server, the server gives the client the server's pubic key. On the first connection, the client has no way to know if this is the right host or not and will prompt the user, telling them that the authenticity of the host cannot be established. This will occur regardless of whether the client is using password authentication or a public / private key pair. A forty some character RSA "fingerprint" will be displayed which an administrator may have provided you for identification purposes. If the administrator has given you the fingerprint, it should definitely match the one displayed by the remote host or something is wrong.

You are asked if you want to continue. You should if you want to make the connection and unless you suspect something is wrong, e.g. you have the fingerprint and it does not match. If you continue, the public key will be saved and you are likely to never see this message again. If the host ever changes its keys, you are likely to see a stronger message indicating a key mismatch. If the host has aliases or you use an IP address once and a hostname latter, you will see the "authenticity of host cannot be established" message, each time you use a different host name.

When you continue, depending on whether you are using password authentication or a key pair, you will be prompted for the remote user's password or "Enter passphrase for RSA key 'comment':" The comment you entered into a Windows client or your username@hostname for UNIX machines will be displayed. You must enter the case sensitive passphrase used when you created your key pair. If you enter the correct passphrase and the sshd server is set up correctly, you will then see the prompt for the remote host and have an active ssh session.

transparent spacer

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in (or These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of (or cgi-bin/ from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.

Home >
How-To >
Secure Shell >

What's New
Email address

Copyright © 2000-2014, George Shaffer. Terms and Conditions of Use.