Hacker Linux Uncovered

5.3. 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.

5.3.1. Configuration Files

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

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.

5.3.2. 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:

5.3.3. 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:

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:

5.3.5. 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.

5.3.6. 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:

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 <Enter> 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.

5.3.7. 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:

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.

5.3.8. 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, the same as considered in Section 5.3.5 , 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.

Related

Категории