The candidate should be able to configure sshd to allow or deny root logins, enable or disable X forwarding. This objective includes generating server keys, generating a user's public/private key pair, adding a public key to a user's authorized_keys file and configuring ssh-agent for all users. Candidates should also be able to configure port-forwarding to tunnel an application protocol over ssh, configure ssh to support the ssh protocol versions 1 and 2, disable non-root logins during system maintenance, configure trusted clients for ssh logins without a password and make multiple connections from multiple hosts to guard against loss of connection to a remote host following configuration changes.
Key files, terms and utilities include:
ssh, sshd |
/etc/ssh/sshd_config |
~/.ssh/id_dsa.pub and id_sa, ~/.ssh/authorized_keys
|
.shosts, .rhosts |
ssh is a client program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network.
sshd is the server (daemon) program for ssh. Together these programs replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network.
You can copy files using the scp command. Scp stands for Secure CoPy. scp uses ssh for data transfer.
There are several ways to do this, I use the Debian way:
# apt-get install ssh
To check which files are installed type this command:
# dpkg --listfiles ssh
Configuring sshd is done by editing the
configuration file /etc/ssh/sshd_config.
This is done by setting the keyword PermitRootLogin in the configuration file to the appropriate value. To make it more difficult for someone to gain full access, you shouldn't allow root logins.
Possible values for PermitRootLogin:
There are a number of keywords that can be used to influence the behaviour of sshd in relation to logins.
These keywords are:
This keyword is followed by a list of user names, separated by spaces. Login is allowed only for usernames that match one of the patterns. You can use “*” and “?” as wildcards in the patterns.
This keyword is followed by a list of user names, separated by spaces. User names that match one of the patterns can not login. You can use “*” and “?” as wildcards in the patterns.
This keyword is followed by a list of group names, separated by spaces. Login is allowed only for users who are a member of one or more groups that match one of the patterns. You can use “*” and “?” as wildcards in the patterns.
This keyword is followed by a list of group names, separated by spaces. Login is not allowed for users who are a member of one or more groups that match one of the patterns. You can use “*” and “?” as wildcards in the patterns.
There are a number of keywords that can be used to influence the behaviour of sshd in relation to the X Windows system.
The keywords are:
X11 forwarding is a mechanism where the program runs on one
machine and the X Windows output is shown on another
machine. The command ssh -X
remote will set the
DISPLAY in the server-shell to
localhost:num:0 which is actually the
tunnel-endpoint which is mapped back to the original
DISPLAY in the client context. This
tunnel is secured using ssh.
X11Forwarding can be set to yes or no. The
default is no.
This specifies the first display number that is available for the X11 forwarding of sshd. This prevents sshd from interfering with real servers. The default is 10.
This specifies the fully qualified location of the
xauth command. The default location is
/usr/bin/X11/xauth.
xauth is used to edit and display the
authorization information used in connecting to the X server.
If you connect to machine B from machine A using ssh your_account@machineB and start an xterm for instance, the process will run on machine B and the X output will go to machine A.
On machine A, you must authorise machine B for X with the command xhost +machineB.
There are a number of keywords that can be used to influence the
behaviour of sshd in relation to authenticating users.
The ability for users to identify themselves via a password can be turned on or off.
When turned off, users can authenticate with a public/private keypair. The public key must be added in the file ~/.ssh/authorised_keys on the system to which the user want to log in, the private key must be placed in ~/.ssh/ on the client system.
To completely torn off authentication with passwords, depending on your PAM configuration, the option UsePAM must be set to No.
The keywords are:
PasswordAuthentication can be set to yes or no. The default is yes.
The SSH protocol has 2 versions, version 1 and version 2. The most important difference between these versions is that version 1's cryptographic integrety chack is known to be weak and broken. Both versions are still available in the ssh server daemon. The daemon can be instructed to ony use one version or both.
The keywords are:
Version can be set to 1 or 2. Multiple values must be comma-seperated. The order of the protocol list does not indicate preference, because the client selects among multiple protocol versions offered by the server. The default is 2,1.
There are two types of keys: Server keys and User keys.
There is a slight difference between the protocol versions 1 and 2.
The man page of sshd describes this as follows:
Each host has a host-specific RSA key (normally 1024 bits) used to identify the host. Additionally, when the daemon starts, it generates a server RSA key (normally 768 bits). This key is normally regenerated every hour if it has been used and is never stored on disk.
Whenever a client connects the daemon responds with its public host and server keys. The client compares the RSA host key against its own database to verify that it has not changed. The client then generates a 256 bit random number. It encrypts this random number using both the host key and the server key, and sends the encrypted number to the server. Both sides then use this random number as a session key which is used to encrypt all further communications in the session. The rest of the session is encrypted using a conventional cipher, currently Blowfish or 3DES, with 3DES being used by default. The client selects the encryption algorithm to use from those offered by the server.
Next, the server and the client enter an authentication dialog. The client tries to authenticate itself using .rhosts authentication, .rhosts authentication combined with RSA host authentication, RSA challenge- response authentication or password based authentication.
Rhosts authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file if desired. System security is not improved unless rshd, rlogind, rexecd and rexd are disabled.
Version 2 works similarly: Each host has a host-specific DSA key used to identify the host. However, when the daemon starts, it does not generate a server key. Forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key.
The rest of the session is encrypted using a symmetric cipher, currently 128-bit AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES or 256-bit AES. The client selects the encryption algorithm to use from those offered by the server. Additionally, session integrity is provided through a cryptographic message authentication code (hmac-sha1 or hmac- md5).
Protocol version 2 provides a public key based user (PubkeyAuthentication) or client host (HostbasedAuthentication) authentication method, conventional password authentication and challenge-response based methods.
If possible, choose SSH protocol version 2 as the only possible or as the first protocol to use.
ssh implements the RSA authentication protocol
automatically. The user creates an RSA key pair by running
ssh-keygen. This stores the private key in
$HOME/.ssh/id_dsa and the public key in
$HOME/.ssh/id_dsa.pub in the user's home
directory. The user should then copy the id_dsa.pub to
$HOME/.ssh/authorized_keys in his home
directory on the remote machine. The
authorized_keys file has one key per line which
can be very long. After this, the user can log in without giving the
password. Instead of dsa, rsa can be used also. The names of
the keys reflect this.
ssh-agent is a program to hold private keys used for public-key authentication (RSA, DSA). The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through use of environment variables, the agent can be located and automatically used for authentication when the logging-in to other machines using ssh.
Add the following two lines to your
$HOME/.bash_profile file or equivalent
(depending on the shell you are using) to be able to login without
having to type your password each time:
eval `ssh-agent`
ssh-add
The eval `ssh-agent` sets a number of environment variables. In fact, ssh-agent returns the strings needed to set them and eval sees to it that they get set.
The ssh-add command without parameters reads the
contents of the file $HOME/.ssh/id_dsa which
contains the private key, as described earlier.
When the user logs out from the local system, the program
ssh-agent must be terminated. To see to it that
this happens automatically, add the following line to your
.bash_logout file or equivalent, depending on
the shell you are using:
ssh-agent -k
The process id of of the current agent is determined by examining the contents of the environment variable $SSH_AGENT_PID, which has been set by the eval `ssh-agent` command.
To set this up for all future users, modify files in the
/etc/skel directory which automatically get
copied to the new user's home directory when this user is created
with adduser or with the
useradd -m [-k skeleton directory].
There are several ways to do this, depending on how X is started and which display manager you are using.
If you start X from the command line with startx, you can type ssh-agent startx, open a terminal window in X and type ssh-add, which will prompt you for the passphrase and load your keys.
Since I am using Gnome and Debian, I have installed the graphical version of ssh-askpass by installing the appropriate .deb package:
# apt-get install ssh-askpass-gnome
This file is called gnome-ssh-askpass and is
started by the ssh-agent command which, in its
turn, is automatically started by Gnome. This is configured in the
file /etc/gdm/Session/Gnome.
As an example, consider the situation shown in the picture. We are
working on MyMachine, and we want to get the file
/home/willem/fs0_backup from the machine called
Yoda using scp.
Without ssh tunneling with port forwarding, we would have to do this in a few steps, assuming there is a user willem on both the firewall and on yoda:
on MyMachine do: ssh willem@101.102.103.104 'login on the firewall
on Firewall do: scp willem@yoda:fs0_backup . 'place file from yoda on firewall
on MyMachine do: scp willem@101.102.103.104:fs0_backup . 'get the file
on MyMachine do: ssh willem@101.102.103.104 rm fs0_backup 'remove the file
With tunneling, this can be done with one command, not including the command to set up the tunnel itself.
Before we get to the actual commands involved, let me explain what tunneling with port forwarding means. It is quite simple actually. What happens is that we use ssh to tell MyMachine that it has got a port that points to port 22, the port that is used by ssh, on yoda. After that, all data sent to that port on MyMachine will get forwarded to port 22 on yoda.
Let us assume that the local port is going to be port 8022. The ssh command used to create the tunnel becomes:
MyMachine # ssh -L 8022:yoda:22 willem@101.102.103.104
We are now logged in on the Firewall as the user willem and the tunnel has been established. We can now open a second terminal window and type the scp command that makes use of that tunnel and gets the file:
MyMachine $ scp -P willem@localhost:fs0_backup .
And we've got the file! The tunnel can be terminated by logging out from the firewall.
We are not quite there though. This can also be done in a different way without the need for two windows and without having to terminate the tunnel manually.
This is accomplished by the same set of commands we used earlier but we run the tunnel in the background. To be able to run the tunnel in the background without this resulting in the immediate closure of that tunnel, we have to fool the tunnel to stay open long enough. This is done by using ssh's ability to execute a remote command and terminate after the completion of that command, combined with the “-f” flag to tell ssh to run in the background. The command that we will execute on the other machine is sleep 60 which gives us 60 seconds to initiate the scp command. Yes, to INITIATE the connection. It does not matter how long the actual scp command takes, the connection will not be terminated before the scp is finished.
To illustrate the above, we will combine both commands on one line and use sleep 1 instead of sleep 60:
MyMachine $ ssh -f -L 8022:yoda:22 willem@101.102.103.104 sleep 1;\
scp -P8022 willem@localhost:fs0_backup .
willem@localhost's password: Waiting for forwarded connections to terminate...
The following connections are open:
#0 direct-tcpip: listening port 8022 for yoda port 22, connect from
127.0.0.1 port 1475 (t4 r1 i1/0 o16/0)
<here we type the password>
fs0_backup 100% |*****************************| 6525 00:00
MyMachine $
As you can see, we immediately got a timeout because we were not quick enough in typing the password. What you can also see is that this did not end the connection. As soon as the password was given, the file was copied with the scp command.
Note that we had to tell scp with -P8022 to use port 8022 since it would otherwise have used the default port 22.
In this example we have used scp as an example but the same trick also works for other protocols, such as smtp.
Since the tunnel is an ssh tunnel, all data going through the tunnel is encrypted.
The $HOME/.rhosts file was originally used by the
rlogin and rsh commands. The file
contained information about the machines the user can connect from.
Say you create a $HOME/.shosts file which contains
a line in the form:
machine-a.somedomain user-a machine-b.somedomain user-b
Then user-a can login to machine-b from machine-a using user-b's account without the need for user-b's password.
Although ssh can still make use of the
$HOME/.rhosts and
$HOME/.shosts files, this is configured in the
/etc/ssh/sshd_config file and it is highly
recommended you use the new authentication method. The new method uses
the ssh-keygen command and the
$HOME/.ssh/authorized_keys files, which are more
secure.