Ssh is set of programs which employ public/private key technology for
authenticating and encrypting sessions between user accounts on
distributed hosts on the Internet. It can be compiled and used by a
normal user without having to ask permission or assistance from the
system administrator, or the system administrator can install it as a
plug-in replacement for the Berkeley "r" utilities without the users
needing to know it is there at all (or do anything to learn how to use
it).
Ssh can also be used as a way to "tunnel" other protocols, such as the
X Window System protocol, adding encryption to the channel to improve
security against packet sniffing and "man in the middle" attacks.
When used with X, ssh looks like a normal (albeit a proxy) X server on
the local machine which redirects X protocol communication across an
encrypted channel to the actual X server on the other end.
Ssh works by the exchange and verification of information, using
public and private keys, to identify hosts and users. It then
provides encryption of subsequent communication, also by the use of
public/private key cryptography.
In describing ssh here, the term
client means a workstation
or PC that you are already logged in to, e.g., your own personal
workstation or a group workstation that provides XDM session
management for several X terminals. The term
server means a
secondary remote workstation that you wish to log in to to do some
work; a login session server.
Put simply, the client is where you type "
rlogin server" or
"
rcp file server:newfile" and the server is where you get a
new login session and shell prompt or are copying files,
respectively.
As a user, you generate an "identity" on the client system by running
the
ssh-keygen program. This program creates a subdirectory
$HOME/.ssh and inserts in it two files named
identity and
identity.pub which contain your private
and public keys for your account on the client system. This latter
file can then be appended to a file
$HOME/.ssh/authorized_keys that should reside on any/all
servers where you will make ssh connections.
As a system administrator, you generate a public and private key pair
for the system itself. By use of this information contained within
the system itself, the possibility of someone spoofing the system's
identity by faking IP addresses or munging up DNS records that
associate IP addresses and domain names is removed. You would have to
break into the system and steal its private key in order to
sucessfully pretend to be that system. This is a big improvement in
security.
The biggest task if you manage a large number of systems that are
meant to be used together is collecting and distributing the keys that
identify all the hosts which run ssh. Tools exist for handling this
task: ssh includes the program
make-ssh-known-hosts.pl (which
requires
POSIX.pm be installed in your Perl library
directory) and another script (
http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list)
is available on the Internet.
See also: Kimmo Suominen's
Getting started with SSH.
First, you need to
get and install ssh
on your client workstation, plus it must be installed on the remote
system you wish to connect to. You can do this for your own account,
or your system administrator can install it for the entire system.
Once installed, there are several ways you can use ssh, each with
varying steps you must go through first.
The most basic use of ssh is transparent when compared with the
standard Berkeley "r" utilities. In fact, a system administrator can
install ssh on both client and remote server workstations and users
who connect using
rlogin server will see no difference
whatsoever, nor will they need to know anything new. This kind of use
gets you the most basic protection of encrypted sessions from systems
with ssh installed, usually with a fall back capability to the old
(and less secure) Berkeley methods if the other system does not
support ssh.
If you wish to make security tighter, you can stop using
.rhosts and
/etc/hosts.equiv files (or disable the
Berkeley utilities altogether) and only allow passwordless connections
with ssh keys.
Each system has its own public/private key pair that identifies it to
other systems. A client system's public key can be placed in a server
system's
/etc/ssh_known_hosts file to allow the server to
authenticate the client by a key exchange dialog.
If the client host's public key (from the
/etc/ssh_host_key.pub file) is found in the in the server's
/etc/ssh_known_hosts file, and you place the host name in
your own
.rhosts or
.shosts file, you get the same
passwordless connection behavior as the standard Berkeley "r"
utilities. If the client's key is not found, ssh will prompt you for
the password on the server and will transmit this password -- in
encrypted form, rather than plain text -- to the server for
authenticating your login. This method involves the system
administrator, who must place the client's public keys in the server's
/etc/ssh_known_hosts file. There is another way to use ssh
that doesn't require the administrator's intervention.
Each user account also has a public and private key that identifies
that user account. You get this key when you run the
ssh-keygen program. It creates a directory called
$HOME/.ssh and puts the keys in there. You can now take your
public key, found in the
$HOME/.ssh/identity.pub file and
place it on the server in your
$HOME/.ssh/authorized_keys
file. Once you have done this, even though the server doesn't know
the key of the client workstation, it
does now know your key
and will allow the login to your account without a password.
To use the X Window System protocol tunneling (if enabled), you only
need to log in successfully and ssh will create a DISPLAY environment
variable for you that points to a proxy X server on the server system,
which passes X protocol traffic to the real X server on the client
system. You can start running X client programs as soon as you get a
shell prompt.
