CNT-2311-Chapter 10 Notes

Configuring SSH (page 499)

Secure Shell (SSH) is the preferred remote login tool.

SSH Basics (page 499)

Linux supports remote login access through several different servers including Telnet, VNC and even X. They all transfer data over the network in unencrypted form. SSH encrypts the password exchange and all subsequent data transfers. SSH provides file transfer features & the ability to tunnel other network protocols Several SSH servers are available, the most popular is the OpenSSH server OpenSSH can be launched using a super script or with a SysV startup script (preferred) Configuring Basic SSH Features (page 500) The main configuration file for the OpenSSH server is /etc/ssh/sshd_config The default settings work for most systems. You might want to check or modify: Protocol Level: Version 2.0 is preferred due to known vulnerabilities in earlier versions. Permit_Root_Login: The default is yes, but this is a security risk. X11_Forwarding: (X tunneling features) The default is no If you make changes to the configuration file, be sure to restart the server.

SSH Keys (page 501)

SSH uses a security system that involves two keys: a Private Key and Public Key All parties that engage in an SSH communication have their own keys. These keys are mathematically linked so that data encrypted with a Public Key may only be decrypted with the matching Private Key. On the server, there are normally 4 to 6 keys and they are stored in /etc/ssh If keys are not present, you can generate them with the ssh-keygen command On the client, keys are stored in the ~/.ssh/known_hosts file. You can pre-populate this file on the client to prevent security warnings.

Controlling SSH Access (page 503)

You may restrict access to an SSH server by requiring password authentication You may be able to limit access by IP Address with TCP Wrappers You can use a firewall to restrict access to the SSH server to port 22 only. If you have the file /etc/nologin on the server, only root may log in.

Copying Files via SSH (page 503)

SSH includes a file-copying command: scp It works like cp but you must specify the target computer You must use a colon at the end of this command to prevent renaming the file

Configuring Logins without Passwords (page 504)

SSH can be configured to allow logins without passing a password A security risk is if someone gains access to your account on the client, then they have your access to the server. To do this, you must generate a special key pair on the client, transfer the Public Key to the server, and place it in the ~/.ssh/authorized_keys file.

Using ssh-agent (page 505)

Another SSH authentication option is to use the ssh-agent program. This program requires a password to start a connection, but remembers the password for the remainder of the session. It is configured using a slight variation to the no-password method.

Using SSH Login Scripts (page 505)

SSH text-mode login sessions run the user’s configured shell. That runs the shell’s defined login scripts. The OpenSSH server supports its own login script – sshrc

Setting Up SSH Port Tunnels (page 505)

SSH has the ability to encrypt other protocols and thus protect them in transit On the server side, must make sure that the /etc/ssh/sshd_config file has the option AllowTCPForwarding set to yes On the client side, you must establish a special SSH connection using the -N, -f, and the -L options.

SSH Security Considerations (page 507)

SSH can be a security liability. If you need to use SSH, you should consider: - Only accept protocol level 2 connections - Refuse direct root logins - If X forwarding is not necessary, disable it - Use TCP Wrappers or a firewall to limit the machines that can connect - Keep SSH up to date - Protect the keys

Using GPG (page 507)

GPG or Gnu Privacy Guard is a tool for encrypting e-mail. GPG can encrypt an entire message or digitally “sign” a message.

Generating and Importing Keys (page 508)

GPG keys are similar to SSH keys in that you need a Public and Private key. You can sign a message with your Private key and readers can verify it with your Public key. You can encrypt a message with the readers Public key and they can decrypt it with their Private key. To encrypt e-mail, you must obtain the Public key from others. Then you can add their keys to your keyring, which is a file that contain the e-mail address and corresponding keys that you have imported from others.

Encrypting and Decrypting Data (page 509)

This section explains the command syntax for encrypting data with GPG. You can encrypt an entire file and attach it to your text-based e-mail message. You can use the --armor option to create ASCII output which can be cut and pasted into a message. When you receive a message that was encrypted with your Public key, you can reverse the encryption with the --decrypt option.

Signing Messages and Verifying Signatures (page 510)

GPG can be used to sign messages and to verify signatures. The –sign option creates a new file encrypted with your Private key. The --clearsign option leaves the message unencrypted but adds an encrypted signature that can be decrypted with your Public key. If you receive a signed message, you can verify it with the --verify option.

Administering Network Security (page 476)

The two simplest ways to prevent unwanted acces to computers is by shutting down access to network servers or controlling network ports that are used. You can also disable servers that aren't being used and check for open ports. Use Super Server restrictions to limit acces.

Using Super Server Restrictions (page 477)

A super server listens for network connections on behalf of another program and after a connection is found hands off control to the intended server. Super servers can reduce memory load because it handles many small seldom used servers. Usually only one or two of the servers that it handles are in memory. Security checks can be launched from the super server to protect all servers that it manages. The two major super servers are: inetd and xinetd.

Configuring inetd (page 477-479)

Type ps ax | grep inetd to see wether inetd or xinetd is running on your system.The output should have either an inetd or xinetd command. Servers that launch via inetd are controlled through the /etc/inetd.conf file or files within /etc/inetd.d directory. Newer versions of inetd allow you to split configurations into several files instead of using a single /etc/inetd.conf file. This allows you to easily add or delete server configurations by adding or deleting their configuration files. After modifying inetd.conf you have to restart the inetd super server. In order to to restart the server type in a command similar to this one: #/etc/rc.d/init.d/inetd restart. Instead of using SysV startup scripts the kill or killall command can be used.

Controlling Access via TCP Wrappers (page 479)

The TCP Wrapper package includes a program known as tcpd. Instead of calling a server directly inetd calls tcp which checks wheter a client is authorized to access a server and if the client has authorization tcp calls the server. /etc/hosts.allow and /etc/.hosts.deny are the two files that TCP Wrappers are configured through.The allow file specifies computers that are allowed access to a system where as the deny filelists computers that aren't allowed access. If a computer is listed in both the allow and deny files the allow fule takes precedence. Both files consist of the same daemon-list : client-list format. The daemon=-list is a list of servers, and the client-list is a list of computers to be granted or denied acces to specified servers (daemons).