It's often very useful to execute a command on a remote host and
have input or output from that command be read from, or written to, a network
connection.
Each of these commands spawns a shell on the remote host and allows the user
to execute commands. Of course, the client needs to have an account on the
remote host where the command is to be executed. Thus, all these commands
use an authentication process. The r commands use a simple
username and password exchange between the hosts with no encryption, so anyone
listening could easily intercept the passwords. The ssh
command suite provides a higher level of security: it uses a technique
called Public Key Cryptography, which provides
authentication and encryption between the hosts to ensure that
neither passwords nor session data are easily intercepted by other hosts.
It is possible to relax authentication checks for certain users even further. For
instance, if you frequently have to log into other machines on your LAN,
you might want to be admitted without having to type your password every
time. This was always possible with the r commands, but the
ssh suite allows you to do this a little more easily. It's
still not a great idea because it means that if an account on one machine
is breached, access can be gained to all other accounts that user has
configured for password-less login, but it is very convenient and people will
use it.
Start by removing the r commands if they're
installed. The easiest way to disable the old r
commands is to comment out (or remove) their entries in the
/etc/inetd.conf file. The relevant entries will
look something like this:
# Shell, login, exec and talk are BSD protocols.
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd |
You can comment them by placing a
# character at the start
of each line, or delete the lines completely. Remember, you need to restart the
inetd daemon for this change to take effect. Ideally, you
should remove the daemon programs themselves, too.
OpenSSH is a free version of the ssh suite of programs; the Linux port can
be found at
https://violet.ibs.com.au/openssh/ and in
most modern Linux distributions.[1]
We won't describe compilation here; good instructions are included in the
source. If you can install it from a precompiled package, then it's probably
wise to do so.
There are two parts to an ssh session. There is an
ssh client that you need to configure and run on the local
host and an ssh daemon that must be running on the remote
host.
The sshd daemon is the program that listens for network
connections from ssh clients, manages authentication, and
executes the requested command. It has one main configuration file called
/etc/ssh/sshd_config and a special file containing a
key used by the authentication and encryption processes to represent the host
end. Each host and each client has its own key.
A utility called ssh-keygen is supplied to generate
a random key. This is usually used once at installation time to
generate the host key, which the system administrator usually stores
in a file called /etc/ssh/ssh_host_key. Keys can
be of any length of 512 bits or greater. By default,
ssh-keygen generates keys of 1024 bits in length,
and most people use the default. To generate a random key, you would
invoke the ssh-keygen command like this:
# ssh-keygen -f /etc/ssh/ssh_host_key |
You will be prompted to enter a passphrase. However, host keys must not use
a passphrase, so just press the return key to leave it blank. The program
output will look something like:
Generating RSA keys: ......oooooO...............................oooooO
Key generation complete.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_key
Your public key has been saved in /etc/ssh/ssh_host_key.pub
The key fingerprint is:
1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria |
You will find at the end that two files have been created. The first is
called the private key, which must be kept secret and will be in
/etc/ssh/ssh_host_key. The second is called the public
key and is one that you can share; it will be in
/etc/ssh/ssh_host_key.pub.
Armed with the keys for ssh communication, you need to
create a configuration file. The ssh suite is very
powerful and the configuration file
may contain many options. We'll present a simple example to get you started;
you should refer to the ssh documentation to enable other
features. The following code shows a safe and minimal
sshd configuration file. The rest of the configuration
options are detailed in the sshd (8) manpage:
# /etc/ssh/sshd_config
#
# The IP adddresses to listen for connections on. 0.0.0.0 means all
# local addresses.
ListenAddress 0.0.0.0
# The TCP port to listen for connections on. The default is 22.
Port 22
# The name of the host key file.
HostKey /etc/ssh/ssh_host_key
# The length of the key in bits.
ServerKeyBits 1024
# Should we allow root logins via ssh?
PermitRootLogin no
# Should the ssh daemon check users' home directory and files permissions?
# are safe before allowing login?
StrictModes yes
# Should we allow old ~/.rhosts and /etc/hosts.equiv authentication method?
RhostsAuthentication no
# Should we allow pure RSA authentication?
RSAAuthentication yes
# Should we allow password authentication?
PasswordAuthentication yes
# Should we allow /etc/hosts.equiv combined with RSA host authentication?
RhostsRSAAuthentication no
# Should we ignore ~/.rhosts files?
IgnoreRhosts yes
# Should we allow logins to accounts with empty passwords?
PermitEmptyPasswords no |
It's important to make sure the permissions of the configuration files are
correct to ensure that system security is maintained. Use the following
commands:
# chown -R root:root /etc/ssh
# chmod 755 /etc/ssh
# chmod 600 /etc/ssh/ssh_host_key
# chmod 644 /etc/ssh/ssh_host_key.pub
# chmod 644 /etc/ssh/sshd_config |
The final stage of sshd administration daemon is
to run it. Normally you'd create an rc file
for it or add it to an existing one, so that it is automatically executed
at boot time. The daemon runs standalone and doesn't require any entry in
the /etc/inetd.conf file. The daemon must be run as the
root user. The syntax is very simple:
The
sshd daemon will automatically place itself into the
background when being run. You are now ready to accept
ssh
connections.
There are a number of ssh client programs:
slogin, scp and ssh.
They each read the same configuration file, usually called
/etc/ssh/ssh_config. They each also read configuration
files from the .ssh directory in the home directory
of the user executing them. The most important of these files is the
.ssh/config file, which may contain options that override
those specified in the /etc/ssh/ssh_config file, the
.ssh/identity file, which contains the user's own
private key, and the corresponding .ssh/identity.pub
file, containing the user's public key. Other important files are .ssh/known_hosts and
.ssh/authorized_keys; we'll talk about those later in Section 12.5.2.3.” First, let's create the global
configuration file and the user key file.
/etc/ssh/ssh_config is very similar to the server
configuration file. Again, there are lots of features you can configure, but
a minimal configuration looks like that presented in
Example 12-5. The rest of the configuration
options are detailed in the sshd(8) manpage. You can add sections that match
specific hosts or groups of hosts. The parameter to the
“Host” statement may be either the full name of
a host or a wildcard specification, as we've used in our example, to match all
hosts. We could create an entry that used, for example,
Host *.vbrew.com to match any host in the
vbrew.com domain.
Example 12-5. Example ssh Client Configuration File
# /etc/ssh/ssh_config
# Default options to use when connecting to a remote host
Host *
# Compress the session data?
Compression yes
# .. using which compression level? (1 - fast/poor, 9 - slow/good)
CompressionLevel 6
# Fall back to rsh if the secure connection fails?
FallBackToRsh no
# Should we send keep-alive messages? Useful if you use IP masquerade
KeepAlive yes
# Try RSA authentication?
RSAAuthentication yes
# Try RSA authentication in combination with .rhosts authentication?
RhostsRSAAuthentication yes |
We mentioned in the server configuration section that every host and user has a key. The user's key is stored in his or her
~/.ssh/indentity file. To generate the key, use the
same ssh-keygen command as we used to generate the
host key, except this time you do not need to specify the name of the file
in which you save the key. The ssh-keygen defaults to
the correct location, but it prompts you to enter a filename in case you'd like
to save it elsewhere. It is sometimes useful to have multiple identity files,
so ssh allows this.
Just as before, ssh-keygen will prompt you to entry a
passphrase. Passphrases add yet another level of security and are a good idea.
Your passphrase won't be echoed on the screen when you type it.
Warning |
There is no way to recover a passphrase if you forget it. Make sure it is
something you will remember, but as with all passwords, make it something
that isn't obvious, like a proper noun or your name. For a passphrase to
be truly effective, it should be between 10 and 30 characters
long and not be plain English prose. Try to throw in some unusual
characters. If you forget your passphrase, you will be forced to generate a
new key. |
You should ask each of your users to run the
ssh-keygen
command just once to ensure their key file is created correctly. The
ssh-keygen will create their
~/.ssh/
directories for them with appropriate permissions and create their private and
public keys in
.ssh/identity and
.ssh/identity.pub, respectively. A sample session
should look like:
$ ssh-keygen
Generating RSA keys: .......oooooO..............................
Key generation complete.
Enter file in which to save the key (/home/maggie/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/maggie/.ssh/identity.
Your public key has been saved in /home/maggie/.ssh/identity.pub.
The key fingerprint is:
1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria
$ |
Now ssh is ready to run.
We should now have the ssh command and it's associated
programs installed and ready to run. Let's now take a quick look at how to
run them.
First, we'll try a remote login to a host. We can use the slogin program in much the same way as we used the rlogin
program in our example earlier in the book. The first time you attempt a
connection to a host, the ssh client will retrieve the
public key of the host and ask you to confirm its identity by prompting you
with a shortened version of the public key called a
fingerprint.
The administrator at the remote host should have supplied you in
advance with its public key fingerprint, which you should add to your
.ssh/known_hosts file. If the remote
administrator has not supplied you the appropriate key, you can
connect to the remote host, but ssh will warn you
that it does have a key and prompt you whether you wish to accept the
one offered by the remote host. Assuming that you're sure no one is
engaging in DNS spoofing and you are in fact talking to the correct
host, answer yes to the prompt. The relevant key is then stored
automatically in your .ssh/known_hosts and you
will not be prompted for it again. If, on a future connection attempt,
the public key retrieved from that host does not match the one that is
stored, you will be warned, because this represents a potential security
breach.
A first-time login to a remote host will look something like:
$ slogin vchianti.vbrew.com
The authenticity of host 'vchianti.vbrew.com' can't be established.
Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/
known hosts.
[email protected]'s password:
Last login: Tue Feb 1 23:28:58 2000 from vstout.vbrew.com
$ |
You will be prompted for a password, which you should answer with the
password belonging to the remote account, not the local one. This password
is not echoed when you type it.
Without any special arguments, slogin will attempt to log in
with the same userid used on the local machine. You can override this
using the -l argument, supplying an alternate login name
on the remote host. This is what we did in our example earlier in the book.
We can copy files to and from the remote host using the scp
program. Its syntax is similar to the conventional cp
with the exception that you may specify a hostname before a filename, meaning
that the file path is on the specified host. The following example illustrates
scp syntax by copying a local file called
/tmp/fred to the /home/maggie/ of
the remote host chianti.vbrew.com:
$ scp /tmp/fred vchianti.vbrew.com:/home/maggie/
[email protected]'s password:
fred 100% |*****************************| 50165 00:01 ETA |
Again, you'll be prompted for a password. The scp command
displays useful progress messages by default. You can copy a file from a
remote host with the same ease; simply specify its hostname and filepath as
the source and the local path as the destination. It's even possible to copy
a file from a remote host to some other remote host, but it is something you
wouldn't normally want to do, because all of the data travels via your host.
You can execute commands on remote hosts using the
ssh command. Again, its syntax is very simple. Let's
have our user maggie retrieve the root directory of
the remote host vchianti.vbrew.com.
She'd do this with:
$ ssh vchianti.vbrew.com ls -CF /
[email protected]'s password:
bin/ console@ dos/ home/ lost+found/ pub@ tmp/ vmlinuz@
boot/ dev/ etc/ initrd/ mnt/ root/ usr/ vmlinuz.old@
cdrom/ disk/ floppy/ lib/ proc/ sbin/ var/ |
You can place ssh in a command pipeline
and pipe program input/output to or from it just like any other command,
except that the input or output is directed to or from the remote host
via the ssh connection. Here is an example of how you might
use this capability in combination with the tar command
to copy a whole directory with subdirectories and files from a remote host
to the local host:
$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf -
[email protected]'s password:
etc/GNUstep
etc/Muttrc
etc/Net
etc/X11
etc/adduser.conf
..
.. |
Here we surrounded the command we will execute with quotation marks to make it
clear what is passed as an argument to ssh and what is used
by the local shell. This command executes the tar
command on the remote host to archive the /etc/ directory
and write the output to standard output. We've piped to an instance of the
tar command running on our local host in extract mode
reading from standard input.
Again, we were prompted for the password. Now you can see why we encouraged
you to configure ssh so
that it doesn't prompt you for passwords all the time! Let's now configure
our local ssh client so that it won't prompt for a password
when connecting to the
vchianti.vbrew.com host. We mentioned
the .ssh/authorized_keys file earlier; this is where
it is used. The .ssh/authorized_keys file contains the
public keys on any remote user accounts that we wish to
automatically log in to. You can set up automatic logins by copying the
contents of the
.ssh/identity.pub from the remote
account into our local .ssh/authorized_keys file. It is
vital that the file permissions of .ssh/authorized_keys
allow only that you read and write it; anyone may steal and use the
keys to log in to that remote account. To ensure the permissions are correct,
change .ssh/authorized_keys, as shown:
$ chmod 600 ~/.ssh/authorized_keys |
The public keys are a long single line of plain
text. If you use copy and paste to duplicate the key into your local file,
be sure to remove any end of line characters that might have been introduced
along the way. The .ssh/authorized_keys file may contain
many such keys, each on a line of its own.
The ssh suite of tools is very powerful and there are many
other useful features and options that you will be interested in exploring.
Please refer to the manual pages and other documentation that is supplied
with the package for more information.