SSH Protocol

Posted on 9:31 PM by Bharathvn

SSH Protocol
It was already mentioned that the Telnet protocol is not very suitable for controlling a remote server because it is far from secure. There is considerable need and an even greater wish to control servers remotely. There are several servers in large networks, and it is inconvenient to scurry about the monitors to configure each of them. Any administrator wants to be able to control the entire network complex without leaving the workplace and to do this over secure channels.

During server management sessions, the administrator sends voluminous confidential information onto the networks (e.g., root passwords) that should under no circumstances be intercepted by eavesdropping utilities. There are numerous programs for providing secure communications. The most popular of them is SSH, which is included in most Linux distributions.

Using this utility, you can administer your network servers remotely from one work-place without having to equip each of them with a monitor and to run to each server every time you have to implement a minor configuration change. This is how I administer my network: from one monitor that I can connect to any system block if the problem cannot be solved over the network.

The advantage of SSH is that this protocol allows commands to be executed remotely but requires authentication and encrypts the communications channel. An important feature is that even user authentication passwords are transmitted encrypted.

Presently, there are two versions of the SSH protocol, numbered 1 and 2. The second version employs a stronger encoding algorithm and fixes some of the bugs found in the first version. At present, Linux supports both versions.

In Linux, the SSH protocol is handled by the OpenSSH program. The native platform of this program is another UNIX-like operating system: OpenBSD, from which it has been cloned to all other UNIX platforms, including Linux. But even now the OpenBSD name can be encountered sometimes in configuration files.

The SSH protocol requires a server and a client for operation. The server waits for connection and executes user commands. The client is used to connect to the server and to send it commands to execute. Thus, both parts of the protocol have to be properly configured for normal operation.

Configuration Files
All configuration files for the SSH protocol are located in the /etc/ssh/ directory. These are the following:

The SSH server configuration file: sshd_config

The SSH client configuration file: ssh_config

The key files for different algorithms:

ssh_host_dsa_key

ssh_host_dsa_key.pub

ssh_host_key

ssh_host_key.pub

ssh_host_rsa_key

ssh_host_rsa_key.pub

What is the reason for so many key files? It is that SSH uses different encoding algorithms, including the two most popular and secure ones: the Digital Signature Algorithm (DSA) and RSA. (The latter abbreviation is composed of the first letters of the last names of its creators: R.L. Rivest, A. Shamir, and L.M. Adleman.) The ssh_host_dsa_key and ssh_host_dsa_key.pub files are used by DSA, and the ssh_host rsa_key and ssh_host_rsa_key.pub files are used by the RSA algorithm. The remaining two key files — ssh_host_key and ssh_host_key.pub — store the keys to the first SSH version. Each algorithm requires two files: The file with the PUB extension stores the public key, and the file without this extension stores the private key.

Data to be sent to the server are encrypted using the public key. They can only be decrypted with the help of the private key. The private key cannot be picked by any known algorithms within a reasonable length of time. It can, however, be stolen; thus, you should take all necessary measures to prevent this from happening.

SSH Server Main Configuration Parameters
Consider the contents of the SSH server (sshd) configuration file (Listing 5.1). The sshd file is not large, so its entire contents are listed with only some comments deleted.

Listing 5.1: The sshd configuration file


#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInerval 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 600
#PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# Rhosts authentication should not be used.
#RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files.
#IgnoreRhosts yes
# For this to work, you will also need host keys
# in /etc/ssh/ssh_known_hosts.
#RhostsRSAAuthentication no
# Similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication.
#IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to
# no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords.
#ChallengeResponseAuthentication yes

# Kerberos options
# KerberosAuthentication automatically enabled if
# the key file exists.
#KerberosAuthentication yes
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# AFSTokenPassing automatically enabled if k_hasafs()
# is true.
#AFSTokenPassing yes

# Kerberos TGT passing only works with the AFS kaserver.
#KerberosTgtPassing no

#PAMAuthenticaticnViaKbdInt yes

#X11Forwarding no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhcst yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no

#MaxStartups 10
# No default banner path
#Banner /some/path
#VerifyReverseMapping no

# Override default of no subsystems.
Subsystem sftp /usr/libexec/openssh/sftp-server





The main parameters that you may have to use are the following:

Port — Shows the port, to which to connect on the remote machine. By default, this is port 22. Some administrators like to change this value and to move the server to another port. This action is justified to an extent. For example, if you do not have a Web server, the port normally used by it can be given to SSH. Hackers will think that this is a Web server and will not try to break into it.

Protocol — Gives the protocol versions supported. Note that first version 2 is specified, and then version 1. This means that the server will first try to connect over the version 2 protocol and only then over the version 1 protocol. I recommend removing the comments from this line and deleting the 1 number so that only the last protocol version is used. It's high time we updated the client software and started using more secure technologies. Getting stuck on old software only causes losses.

ListenAddress — Specifies the addresses to listen for a connection. Your server may be equipped with several network adapters. By default, all of these interfaces are monitored. You should specify only those interfaces that will be used for the SSH connection. For example, often one network adapter is used to connect to a local network, and another one is used to connect to the Internet. If the SSH protocol is used to connect only within the local network, only this adapter should be monitored. It is specified in the address:port format. Several address entries can be made to describe all necessary interfaces.

HostKey — Specifies the path to the files containing the encoding key. Only private keys need to be specified, used to decrypt incoming packets.

KeyRegeneraticnInterval — The key can be regenerated during the session in version 1. The purpose of regeneration is to make it impossible to decrypt intercepted packets by later stealing the keys from the machine. Setting this value to 0 disables regeneration. If you followed my recommendation not to use the version 1 protocol (see the Protocol parameter), this parameter does not affect the operation.

ServerKeyBits — Gives the length of the server key. The default value is 768; the minimal value is 512.

SyslogFacility — Specifies the types of messages to be stored in the system log.

LogLevel — Specifies the level of the event to be logged. The possible levels correspond to the system levels, which are considered in Section 12.5.6.

LoginGraceTime — Gives the time interval, within which the user has to enter the correct password before the connection is broken.

PermitRootLogin — Specifies whether the root user can log in using SSH. It was already said that root is the god in the system and its account's privileges must be used with care. If it is not advisable to log in as root regularly, this is all the more so using SSH. Change this parameter to no at once.

StrictModes — Specifies whether sshd should check the status of the files and their owners, user files, and home directory before accepting the login. It is desirable to set this parameter to yes because many novice users make their files accessible for writing to everyone.

RSAAuthentication — Specifies whether RSA authentication is permitted. This option is valid for protocol version 1 only.

PubkeyAuthentication — Specifies whether public key authentication is allowed. This option is valid for protocol version 2 only.

Authorizedkeyfiles — Specifies the file storing the public key that can be used for user authentication.

RhostsAuthentication — Allows authentication using the $home/.rhosts and /etc/hosts.equiv files. The default value is no. It should not be changed without a justified need, because this may have a negative effect on the security.

IgnoreRhosts — When set to yes, the ~/.rhosts and ~/.shosts cannot be read. The value should not be changed unless really necessary, because doing so may have a negative effect on the security.

AuthorizedKeysFile — Specifies the file for storing the list of the authorized keys. If a user logs into the system with a key stored in this file, no further authentication is performed.

RhostsAuthentication — When this parameter is set to yes, a host key from the /etc/ssh/ssh_known_hosts directory will be requested. The parameter is used in protocol version 1 only.

IgnoreUserKnownHosts — When the parameter is set to no, computers listed in ~/.ssh/known_hosts should be trusted during RhostsRSAAuthentication. Because you should not trust anyone, it is better to set this parameter to yes.

PasswordAuthentication — When set to yes, a password will be requested. When authentication is performed using keys, the parameter can be set to no.

PermitEmptyPasswords — Specifies whether empty passwords can be used. The default value is no, and it ought not to be changed.

KerberosAuthentication — Specifies whether Kerberos authentication of the user password should be performed. This authentication has been gaining popularity lately because of the security it provides.

KerberosOrLocalPasswd — When set, if the Kerberos password authentication failed, the password is validated using the /etc/shadow file mechanism.

KerberosTicketCleanup — When set, the user's Kerberos ticket cache file is destroyed on logout.

Banner — Specifies whether a warning message is displayed before the login procedure.

The sshd Server Access Parameters
In addition to those listed in Listing 5.1, the following keywords can be used in the sshd configuration file:

AllowGroups — Allows only the users of the specified groups to log into the system. The user group names are listed after the keyword, separated by spaces.

AllowUsers — Allows only the users listed after the key to enter the system. The user names are listed separated by spaces.

DenyGroups — Denies login to users of the specified groups. The user group names are listed after the keyword, separated by spaces.

AllowUsers — Denies login to users listed after the key. The user names are listed separated by spaces. This parameter comes in handy when a user of a permitted group has to be denied login.

I recommend specifying the names of the groups and users that can log into the system over SSH explicitly.

5.3.4. Configuring the SSH Client
The SSH client configuration settings contain even fewer parameters. The global settings for all of the system's users are stored in the /etc/ssh/ssh_config file. But any settings for any user can be redefined in the .ssh_config file in the particular user's directory. The contents of the global configurations file (with some comments omitted) are shown in Listing 5.2.

Listing 5.2: The contents of the /etc/ssh/ssh_config configuration file


# Site-wide defaults for various options

# Host *
# ForwardAgent no
# ForwardXll no
# RhostsAuthentication yes
# RhostsRSAAuthentication yes
# RSAAuthentication yes
# PasswordAuthentication yes
# FallBackToRsh no
# UseRsh no
# BatchMode no
# CheckHostIP yes
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2, 1
# Cipher 3des
# Ciphers aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc,arcfour,
# aes192-cbc, aes256-cbc
# EscapeChar ~
Host *
Protocol 1, 2





Some of the parameters in this file are the same as in the server configuration file. One of these is the Protocol parameter, which specifies the SSH version being used. But in the case of the client, the version 1 protocol should not be disabled. This will not affect the security of the client but will help you avoid problems when connecting to a server that supports only this protocol.

The following are the most common client parameters:

Host — Specifies, to which server the following declarations are to apply.

CheckHostIP — If this parameter is set to yes, the IP address will be checked in the known_hosts file.

Compression — Enables (yes) or disables (no) data compression.

KerberosAuthentication — Enables (yes) or disables (no) Kerberos authentication.

NumberOfPasswordPrompts — Specifies the number of password entry attempts. If no correct password is entered, the connection is broken.

IdentityFile — Specifies the name of the file containing the private user keys.

PasswordAutentication — Specifies authentication by the password.

Examples of Using the SSH Client
Consider how to connect to a remote server. This is done by executing the following command:

ssh user@server

For example, to connect to the server flenovm as the user flenov, the following command has to be executed:

ssh flenov@flenovm

This will be answered by the following message:

The authenticity of host 'localhost(127.0.0.1)' can't be established
RSA1 key fingerprint is f2:al:6b:d6:fc:d0:f2:al:6b:d6:fc:d0.
Are you sure you want to continue connection (yes/no)?

The program informs you that the authenticity of the host localhost cannot be estab-lished and displays a fingerprint of the RSA key. To continue establishing the connection, enter yes from the keyboard. The following message will be displayed:

Permanently added 'localhost' (RSA1) to the list of known hosts.

This message informs you that the key has been added to the list of the known hosts. This means that the known_hosts file containing the remote system's key was created (or updated) in the .ssh/ subdirectory of your home directory.

The program then prompts you to enter the user's password. If the authentication succeeds, you will be connected to the remote system and will be able to execute commands there as if entering them from its keyboard.

Authentication by Key
Authentication by key is more convenient and more secure than authentication by password. The latter can even be disabled. Accessing the system over SSH is not quite safe. The password can be intercepted when being entered in another program. What is the use, then, of encrypting the SSH connection, if the password can be found when working with other programs?

This can be prevented by using different passwords for each connection. But it is difficult to remember all of the passwords, so it is better to perform authentication by keys, which are protected exceedingly well. All you have to do for this is modify the configuration slightly.

Start by creating a new key. This is done with the help of the ssh-keygen program. It has to be passed the following two parameters:

-t — The key type. This can be rsa or dsa for the second SSH version, or rsal for the first version. The rsa key will be used in the example.

-f — The file, in which the private key is to be stored. The open key file will be named the same, but with the PUB extension.

-b — The key length, which should be 512 minimum. The default value is 1024, which you should leave in place.

The key is generated by executing the following command:

ssh-keygen -t rsa -f ~/.ssh/myrsakey

Note that I specified the place to store the key as the .ssh subdirectory of my home directory, as indicated by the ~ character. SSH will look for all configuration settings in this directory. If you have not connected to the server yet, this path and key do not exist. The situation is corrected by opening the user's home directory and creating the .ssh directory:

cd /home/flenov
mkdir .ssh

If the file, in which to store the key, is not specified when the key is generated, by default an RSA key file, named id_rsa, will created in the ~/.ssh/ directory. The key file for DSA encoding will be stored in the same directory but will be named id-dsa. I specified the key file name on purpose to show how to do this.

If you did everything right, the program should display the following message:

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):

I recommend specifying a password at least 10 characters long or, even better, a passphrase. The password is submitted by pressing the key, after which the program asks you to confirm the password.

If the password confirmation is successful, the following messages are displayed:

Your identification has been saved in ~/ssh/myrsakey.
Your public key has been saved in ~/ssh/myrsakey.pub.


The first message informs you that the private key has been saved in the ~/ssh/myrsakey file. The public key is saved in the ~/ssh/myrsakey.pub file.

The ~/ssh/myrsakey.pub key file has to be sent to the remote computer for the SSH server to use it for the authentication. The file can be sent over open communication channels, because even if it is intercepted by nefarious individuals, it is useless without the password you entered when the keys were created and without the private key.

The administrator of the remote server has to add the contents of the public key file to the .ssh/authorized_keys file. This can be done by executing the following command:

cat myrsakey.pub .ssh/authorized_keys

You can now connect to the server using the public key instead of a password to authenticate your identity. But before you do this, make sure that the server configuration file contains the following directives:

RSAAuthentication yes
PubkeyAuthentication yes

To connect to the server, execute the following command:

ssh -i ~/.ssh/myrsakey

The -i parameter specifies the public key file. If this parameter is not used, the id_rsa file will be used by default; it is specified in IdentityFile in the SSH client configuration file.

Now the server will ask you not for the password but for the passphrase specified when generating the public key.

Enter passphrase for key

Setting the PasswordAuthentication parameter in the SSH server configuration file to no dispenses with password checking, and the authentication will be performed based on the keys only. This is sufficient to provide secure communications.

Running X11 in the Terminal
Using the command line to control the remote system allows traffic to be reduced significantly. But sometimes it is necessary to use the graphical mode. I personally do not recommend using the graphical mode for purposes of security and efficiency, but many Windows users simply cannot accept the command line as the only interface. So if you are one of them, the SSH server can redirect X11 (the Linux graphical shell) to your local terminal. For this, the following three directives have to be specified in the sshd_config file:

XllForwarding yes — Self-explanatory.

XllDisplayOffset 10 — The first display number available to the SSH server. The default value is 10, and there is no reason to change it.

XllUseLocalhost yes — If this parameter is set to yes, the local X server will be used.In this case, the client will work with the local X11 and the service information sent over the network will be encrypted.

If you want to connect to the Linux graphical shell from Windows, you will need a program like X11 for this operating system. I can recommend the X-Win32 client for this, which can be downloaded from this site: www.starnet.com.

I do not recommend using X11, because this technology is still in the development stage and there are methods to fake or break into the connection.

Secure Data Transfer
The SSH packet also includes two useful utilities: the sftp server (an FTP server that supports data encryption) and the sftp client (an FTP client to connect to the sftp server). Examine the last line of the SSH server /ect/ssh/sshd_config configuration file:

Subsystem sftp /usr/libexec/openssh/sftp-server

The Subsystem directive defines supplementary services. It launches the OpenSSH sftp server.

Working with the sftp client is no different from working with the SSH client. Execute the sftp localhost command; the login message, will appear. Enter the correct password and you will be taken to the ftp client command line, from which you can send and receive files using FTP commands. This protocol is considered in detail in Chapter 10; for now, you only need to know that most of its commands are similar to the Linux file handling commands.

Try to connect to your system through an ftp client. After logging in, you can try executing the ls or cd commands to verify that the connection is working. To quit sftp, execute the exit command. The main FTP commands are listed in Appendix 1.

If you have to upload to or download from the server confidential information (for example, accounting files or the password file), you should do this over a secure sftp connection. Regular FTP clients transfer files in plaintext; consequently, anyone can monitor the traffic and obtain information that can be used to compromise your server.

You should keep it in mind, however, that not all FTP servers and clients support SSH encoding. You should ascertain that your software supports this protocol before using it.