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 identity.pub 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, "identity.pub", to username_hostname_key.pub (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 identity.pub's around is likely to be confusing
and may require re-transferring information if identity.pub'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.
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
http://GeodSoft.com/terms.htm
(or http://GeodSoft.com/cgi-bin/terms.pl).
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
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) 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.
|