Section 11.4. My Other Computer Has No Monitor

11.4. My Other Computer Has No Monitor

There are two reasons why you may want remote access. First, the computer you want to use may be too far away. Second, the computer, as with many servers, may not even have a monitor.

There are several ways to configure remote access to a Linux server. As described in Chapter 9, in the "Users Are Still Demanding Telnet" annoyance, Telnet is one method. While Telnet is insecure, I described methods you can use to encrypt and further secure Telnet communications in that chapter.

Perhaps the best way to configure secure access to a remote Linux system is through the Secure Shell (SSH). Connections through SSH are encrypted. You can even set up encryption keys and password phrases that are not transferred during logins. As described in the next annoyance, you can even use SSH to access GUI applications remotely.

What I describe in this annoyance just covers the basics associated with creating an SSH server and connection. For more information, see SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett et al. (O'Reilly).

11.4.1. Configure SSH

Security is provided through the Secure Shell, and access can be configured through the appropriate SSH configuration file. You'll find two configuration files in the /etc/ssh directory, sshd_config and ssh_config. You can configure both files: sshd_config on the server, and ssh_config on each client. You can also use some of the switches available with the ssh command or customize a client for an individual user with a file in the appropriate home directory.

One possible security issue with SSH is related to user keys, which are stored in ~/.ssh/ under their home directories. If your workstations use NFS to mount home directories from a central server, your encrypted keys will be transmitted over the network in clear text. Anyone who intercepts this transmission can eventually decrypt those keys. If this describes your configuration, consult SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett et al. (O'Reilly) for an alternative configuration.

Generally, when you configure SSH, it's mostly done on the server. Any configuration you do on the client, through /etc/ssh/ssh_config, is secondary.

After you make any changes to the configuration files, remember that you'll have to restart the SSH server. On Debian Linux, you can do so with the following command:

 /etc/init.d/ssh restart 

On SUSE and Red Hat/Fedora Linux, the command is slightly different:

 /etc/init.d/sshd restart 

11.4.2. Limiting Access on the SSH Server

The SSH server configuration file, /etc/ssh/sshd_config, supports direct access by default. You can limit access by user, by group, and by network. If you're supporting access through a firewall, you'll need to provide appropriate access through that barrier.

11.4.2.1. Limiting access by user

You can limit access by user with the AllowUsers directive. If there is no such directive in the /etc/ssh/sshd_config configuration file, all users are allowed on the SSH server (unless otherwise prohibited via Pluggable Authentication Modules, as described in Chapter 10).

For example, if I want to allow only donna to access this server via SSH, I can add the following directive:

 AllowUsers donna 

You can add AllowUsers directives for all users for whom you want to authorize access via SSH. For example, I could add the following directives to limit access to three users:

 AllowUsers donna AllowUsers nancy AllowUsers randy 

Alternatively, you can use the DenyUsers directive to prohibit access to certain accounts.

You may want to deny access to the most privileged user. This requires a different directive:

 PermitRootLogin no 

SSH allows root logins by default. So if you want to minimize the risk to the administrative account, this directive is important.

11.4.2.2. Specific network

You can further refine the AllowUsers directive. For example, you can limit access from users on the remote computer named enterprise4a to donna's account:

 AllowUsers donna@enterprise4a 

Don't let the @ confuse you. This directive does not specify an email address. It specifies a local account and a remote computer from where users are allowed to log in to that account. You can substitute an FQDN for enterprise4a.

Some wildcards are supported. For instance, if you want to support access from the 192.168.0.0/24 network to all local accounts, use the following directive:

 AllowUsers *@192.168.0.* 

11.4.2.3. Specific group

Just as the AllowUsers and DenyUsers directives can help you regulate access via SSH to accounts on the local server, the AllowGroups and DenyGroups directives can do the same, based on group accounts as defined in /etc/group.

11.4.2.4. External access via firewall

If you have a firewall between desired SSH clients and servers, you'll need to make sure that the firewall allows SSH connections. For your convenience, allowing SSH connections is a standard option with the Red Hat/Fedora and SUSE firewall configuration tools. If you're configuring your firewall manually, you'll have to make sure to allow TCP and UPD connections through port 22.

11.4.3. Create Encryption Keys

Sending passwords over a network can be a problem. While SSH communications are encrypted, if a cracker can determine when you send your password and intercept it over your network, he can eventually decrypt it.

The SSH system supports the use of passphrases, which can be more complex than regular passwords (you can even use complete sentences such as "I live 40 feet from the North Pole."). Commands such as ssh-keygen allow you to create a private and public key based on the passphrase. The standard is 1024-bit encryption, which makes the passphrase (or the associated keys) much more difficult to crack.

Once the public key is transferred to the remote system, you'll be able to use SSH to log in to the remote system. The passphrase activates the private key. If matched to the public key on the remote system, an SSH login is allowed.

Create and transfer the private and public keys as follows:

1. Choose an encryption algorithm (I've arbitrarily selected DSA) and generate a private and public key in your home directory (I use /home/michael/.ssh here) with a command like:

    ssh-keygen -t dsa -b 1024 -f /home/michael/.ssh/enterprise-key 

   
   

   When prompted, enter a passphrase. Passphrases are different from standard passwords. They can include whole sentences, such as:

    I like O'Reilly's ice cream 

   
   

   This particular ssh-keygen command generates two keys, putting them in the enterprise-key and enterprise-key.pub files in the /home/michael/.ssh/ directory. You can (and probably should) choose a different passphrase for the encryption key.

2. Next, transmit the public key that you've created to the remote computer. The following command uses the Secure Copy command (scp) to copy the file to donna's home directory on the computer named debian:

    scp .ssh/enterprise-key.pub donna@debian:/home/donna/ 

   
   

3. Now log in to donna's account on the remote computer. Assuming the Secure Shell service is enabled on debian, you can do so with the following command:

    ssh donna@debian 

   
   

   You'll have to specify donna's password because you have not yet set up passphrase protection. You should now be in donna's home directory, /home/donna, on the debian computer.

4. If it doesn't already exist, you'll need to create an .ssh/ subdirectory. You'll also want to make sure it has appropriate permissions with the following commands:

    mkdir /home/donna/.ssh chmod 700 /home/donna/.ssh 

   
   

5. Create the authorized_keys file in the .ssh/ subdirectory:

    touch .ssh/authorized_keys 

   
   

6. Now take the contents of the public SSH key that you created and put it in the authorized_keys file:

    cat enterprise-key.pub >> .ssh/authorized_keys 

   
   

   Note that I used the the append sign (>>) because I want to keep all previous keys that might be in the file; it can contain all the keys referring to all the remote hosts from which you want to log in.

7. Log out of donna's account. The next time you log in, you'll be prompted for the passphrase as follows.

    Enter passphrase key for '/home/michael/.ssh/enterprise-key': 

   
   

Now you can connect securely, using SSH, without having to enter your password or a password on the remote system. With the other measures described earlier in this annoyance, you can also protect your SSH server by user, protect it by group, make sure SSH communications come from a permitted network, and allow SSH through firewalls.

11.4.4. SSH on the Client

The first time you use SSH to log in to a remote system, you may see the following message, which means you haven't configured passphrases:

 The authenticity of host 'debian (10.168.0.15)' can't be established. RSA key fingerprint is 18:d2:73:ec:53:ce:52:4f:2d:43:55:fb:0c:14:49:1e. Are you sure you want to continue connecting (yes/no)? 

Once you enter yes, you'll see the following message:

 Warning: Permanently added 'debian,10.168.0.15' (RSA) to the list of known hosts. 

Then you're prompted for the password on the remote system.

If you've configured passphrases, you'll see only the second message, followed by a request for the passphrase.

In either case, the remote system sends your client a public key, which is added to the user's ~/.ssh/known_hosts file. If the name or IP address of the remote system changes, you'll see an error, which you can address only by editing or deleting the known_hosts file.