The counterpart of ssh_config on the client computer is the sshd_config file on the server. Many options that you can use in the ssh_config file are also available in the sshd_config file. However, some options are specific to the server side of SSH. Table 8-4 gives an overview of some of these options. Table 8-4. Important Options in sshd_config

Using Barcode maker for Reporting Service Control to generate, create Code 3/9 image in Reporting Service applications.

www.OnBarcode.com

Option

AllowTcpForwarding

Description

Use this option to specify whether you want to allow clients to do TCP port forwarding. This is a very useful feature, and you ll probably want to leave it at its default value (yes). Use this option to specify the port that the server is listening on. By default, sshd is listening on port 22. If the SSH process is connected directly to the Internet, this will cause many people to try a brute-force attack on your server. Consider running the SSH process on some other port for increased security. Use this option to specify whether you want to allow root logins. To add additional security to your server, consider setting this option to the no value. If set to no, the root user has to establish a connection as a normal user and from there use su to become root or use sudo to perform certain tasks with root permissions. Use this option to specify if you want to allow users to log in with an empty password. From a security perspective, this isn t a very good idea, and so the default no value is suitable in most cases. If, however, you want to run SSH from a script and establish a connection without entering a password, it can be useful to change the value of this parameter to yes. This option specifies whether users are allowed to log in using passwords. If you want to add additional security to your server by forcing users to log in with public/private key pairs only, give this parameter the value no. Use this option to specify if you want to allow clients to use X11 forwarding. On Ubuntu Server, the default value for this parameter is yes.

Port

PermitRootLogin

PermitEmptyPasswords

ChallengeResponseAuthentication

X11Forwarding

Using Key-Based Authentication

Now that you know all about the basics of SSH, let s look at some of the more advanced options. One of the most important is key-based authentication, which SSH uses via public/private key based authentication. Before diving into the configuration of key-based authentication, let s first have a look on how these keys are used.

CHAPTER 8 MAKING CONNECTION

A Short Introduction to Cryptography

In general, you can use two methods for encryption: symmetric and asymmetric. Symmetric encryption is faster but less secure, and asymmetric encryption is slower but more secure. In a symmetric key environment, both parties use the same key to encrypt and decrypt messages. With asymmetric keys, a public and a private key are used, and this is the important technique that s used for SSH. If asymmetric keys are used, every user needs his own public/private key pair and every server needs a pair of them as well. Of these keys, the private key must be protected at all times: if the private key is compromised, the identity of the owner of the private key is compromised as well. In short, stealing a user s private key is like stealing their identity. Therefore, a private key is normally stored in a very secure place where no one other than its owner can access it; typically this is in ~/.ssh. The public key, on the other hand, is available to everyone. Public/private keys are generally used for three purposes: encryption, authentication, and non-repudiation. To send an encrypted message, the sender encrypts the message with the public key of the receiver who can decrypt it with the matching private key. This scenario requires that, before sending an encrypted message, you have the public key of the person you want to send the message to. The other options are to use public/private keys for authentication or to prove that a message has not changed since it was created. This method is known as non-repudiation. In the example of authentication, the private key is used to generate an encrypted token, the salt. If this salt can be decrypted with the public key of the person who wants to authenticate, then that proves that the server really is dealing with the right person and access can be granted. However, this technique requires the public key to be copied to the server before any authentication can occur, which is also the case when keys are used to prove that a message hasn t been tampered with.