Candidates should be able to configure and secure an SSH daemon. This objective includes managing keys and configuring SSH for users. Candidates should also be able to forward an application protocol over SSH and manage the SSH login.
OpenSSH configuration files, tools and utilities
Login restrictions for the superuser and the normal users
Managing and using server and client keys to login with and without password
Usage of multiple connections from multiple hosts to guard against loss of connection to remote host following configuration changes
Private and public key files
PermitRootLogin, PubkeyAuthentication, AllowUsers, PasswordAuthentication, Protocol
sshd is the server (daemon) program for ssh.
Together these two programs replace rlogin and rsh, providing secure encrypted communications between two untrusted hosts on an insecure network.
SSH (Secure SHell) uses digital keys for both data encryption and authentication.
SSH protocol versions:
This version only supports RSA keys. Each node has a host key (normally 2048 bits) to identify it. When the daemon is started, an additional server key (normally 768 bits) is generated. It is not stored on disk and recreated every hour when used.
When a client connects, the server 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 and server keys, and sends the encrypted number to the server. Both sides then use this random number as a key that 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 from those offered by the server.
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-md5, hmac-sha1, umac-64, umac-128, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).
Finally, in both versions of the protocol, the server and the client enter an authentication dialog. The client tries to authenticate itself using host-based authentication, public key authentication, challange-response authentication, or password authentication. If possible, select SSH protocol version 2 as the only one to use.
ssh implements the RSA authentication mechanism
automatically. The user creates an RSA key pair by running
ssh-keygen. This stores the private key in
$HOME/.ssh/id_rsa and the public key in
$HOME/.ssh/id_rsa.pub in the user's home directory.
The user should then copy the id_rsa.pub into the
$HOME/.ssh/authorized_keys file in his home
directory on the remote machine:
# cat id_rsa.pub >> ˜/.ssh/authorized_keys
authorized_keys file has only one key per line which
can be very long. After this, the user can log in without giving the
password. Instead of using rsa, dsa can also be used. The names of
the keys reflect the kind of keys you created.
Make sure the ˜/.ssh directory and the files in it
have the proper rights. Use for example 700 on the .ssh directory and 600
on the files in it. If you don't, in some situations you can't login using
Configuring sshd is done by editing the
/etc/ssh/sshd_config. This file contains
configuration data for sshd. This file should be writable by root only, but it is
recommended (though not necessary) that it is world-readable.
The allowing or denying of root logins 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. Without the possibility of remote root access someone who wants to get root access on a remote server has to get access via a regular user first. Which is an additional layer of security.
Possible values for PermitRootLogin:
When set to no, root cannot login using ssh.
This means that password authentication is disabled for root.
This means that root can only use ssh to
login to the system with public key authentication and execute the commands that are
given on the command line. The allowed command(s) must be added to the public key(s) in the
~/.ssh/authorized_keys file. For example, if you add
command="/bin/date" at the beginning of your public key line on SERVERA,
only the date command will be allowed for a login using that public key. If you
execute ssh root@SERVERA
then only the date command will be executed on the remote system. (This may be useful
for taking remote backups even if root login is normally not allowed.) Please read the
man pages for more information.
There are a number of keywords that can be used to influence the behaviour of sshd in relation to logins.
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.
Specifies the protocol versions sshd supports. The possible values are "1" and "2". Multiple versions must be comma-separated. The default is "2,1". Note that the order of the protocol list does not indicate preference, because the client selects among multiple protocol versions offered by the server. Specifying "2,1" is identical to "1,2". Unless there are serious arguments for using protocol version "1", only use version "2" because it is far more secure.
Enables the Pluggable Authentication Modules interface. If set to “yes” it will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. The default is “yes”.
Specifies whether challenge-response authentication is allowed (e.g., via PAM or through authentication styles supported in login.conf(5)). The default is “yes”.
If you want to fully disable password based logins, the following
sshd_config settings should be set to no:
This topic stays here to give you some information about this topic but it isn't anymore in the Key Knowledge Areas of lpi.org.
X Windows keywords (sshd_config):
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 fully qualified location of the
xauth command. The default location is
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 be transferred through the SSH tunnel to machine A. To display the terminal, machine B will connect to the display on localhost that's opened by SSH for X11 Forwarding. SSH will forward the X-connection to X server on machine A where it will be displayed in your local display. Because the X output is seemingly created locally no xhost settings have to be changed to enable displaying the content.
To enable X11 forwarding this also has to be enabled on the client side. ForwardX11 has to be set to "yes" in the SSH configuration on the client, or on the command line when initiating the connection.
Using SSH there are different ways for authentication. One way to do this is by using a public/private keypair for authentication. If public key authentication is enabled users can login without having to use a password. When trying to authenticate with a keypair the user will be asked for the passphrase (or ssh_agent will be queried). Also, passphraseless keys can be used (e.g., for automated sessions).
Note on using passphraseless keys: because no passphrase is needed to use a passphraseless key, anyone who has access to the key can use it. This poses a serious security risk. The impact of connections with passphraseless keys should be reduced by allowing these connections only with forced commands and preferably from a limited set of clients, (see man authorized_keys).
This objective was moved to LPIC-1.
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 the use of environment variables the agent can be located and automatically used when logging in to other machines with ssh.
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_rsa (or id_dsa) which
contains the private key, as described earlier. You will be prompted to enter
your passphrase, if necessary.
When the user logs out from the 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:
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.
Using port forwarding, SSH will bind to a port and tunnel all traffic directed at that port through the SSH connection. Traffic is forwarded to the host at the other end of the SSH connection. The remote host may be the server on which the SSH connection terminates, but traffic can also be forwarded to another host. Port forwarding can be configured in both directions: local to remote, but also remote to local.
The syntax is:
ssh -R|L [bind_address:]port:host:host_port [user@]hostname [command]
As an example (example 1), consider the situation shown in the picture. We are working on MyMachine, and we want to connect to the mysql server on Machine 1. The firewall doesn't allow sql connections. The firewall has port forwarding configured so that incoming traffic on port 22 from the internet will be forwarded to port 22 on Machine1. John is an user on Machine1.
First open the tunnel by running ssh with the "-L" option:
MyMachine# ssh -L 13306:localhost:3306 firstname.lastname@example.org
Then run your application, connecting to the local port that is forwarded by the SSH tunnel:
MyMachine# mysql -P 13306
You are now connected to the remote MySQL server without the need to enable SQL connections over the network.
Another example (example 2) would be where one side of the connection wants/needs to
initialize the SSH connection to enable the remote party to connect back
through the tunnel. In this simplified example an ssh tunnel is started on Machine1 to machine2
-R. Then the sql client on machine2 can connect on localhost:13306 and gets a
connection with the mysql server on port 3306 through the SSH tunnel.
The tunnel will stay open as long as the SSH session is running or as long as there is a tunneled session going through it. This means there are two ways of working with SSH tunneling:
open an SSH session with port forwarding and keep it open for as long as you need it. This is useful if you want to be able to reconnect through the tunnel without the need to open a new SSH session. Useful for connecting to a remote host and initializing a tunnel in the reversed direction (example 2).
open an SSH connection with port forwarding in the background and keep it open just long enough to be able to initialize the connection through the tunnel. ("ssh -f -L <your:port:definition> remote_user@remote_host sleep 10 ; <your application>").