Secure Shell

• Secure communication over the network between hosts
• Secure copying of files
• FTP-like client for secure copying of files
• Secure tunneling of insecure protocols

Years ago, remote connections between Linux systems were established using the Telnet protocol. This allowed remote users to log in to a Linux system and run commands from the shell prompt as if they were sitting at the system’s console.

However, Telnet had a serious shortcoming. It offered no safeguards in the form of encryption or other security mechanisms against eavesdropping. When you logged in to the remote system using a Telnet client, your username and password (as well as any data written to the terminal) could be easily sniffed and captured. Because of this, Telnet is no longer widely used to provide remote access. Instead, OpenSSH is used. OpenSSH works in much the same manner as Telnet, providing remote access to the Linux shell prompt. However, OpenSSH encrypts the data as it is transferred between systems.

The Secure SHell (SSH) suite was developed to provide secure communications between systems by encrypting authentication information (your username and password) as well as all the data exchanged between the hosts. With SSH, the data flow can still be captured by a third party, but the contents are encrypted and cannot be decoded into plain text unless the encryption key is known. The OpenSSH package is installed on SUSE Linux Enterprise 12 by default. The OpenSSH package includes programs such as ssh, scp, and sftp. You can use these commands as alternatives to the traditional telnet, rlogin, rsh, rcp, and ftp programs

Encryption

• • Symetric:

With symmetric encryption, the same secret key is used for encryption and decryption. To use secret key cryptography, the secret key has to be shared between the involved parties in a secret fashion one way or the other. If this secret key is known, then all data encrypted with that key can be decrypted.

The main advantage associated with symmetric encryption is that it can efficiently encrypt and decrypt data. Its main disadvantage is that key distribution and management can be difficult.

An important feature of an encryption procedure is the length of the key. A symmetric key with a length of 40 bits (1,099,511,627,776 possibilities) can be broken with brute force methods in a very short amount of time (seconds or in real time, depending on the hardware available). Currently, 128-bit (or longer) symmetric keys are considered secure. Basically, the longer the length of the encryption key, the more secure the data transmission, provided there is no cryptographic flaw in the encryption algorithm.

The following are some of the more important symmetric encryption technologies that you need to be familiar with:

DES (Data Encryption Standard): Standardized in 1977 and is the foundation of many encryption procedures (such as the hashing of UNIX/Linux passwords). The key length is 56 bits. However, in January 1999, the EFF (Electronic Frontier Foundation) decrypted a text encrypted with DES in 22 hours using brute force (trying one possible key after the other). Therefore, a key with a length of 56 bits is no longer secure, as messages protected with such a key can be decrypted in a short time.

Triple-DES: Extension of DES, using DES three times. Depending on the variant used, the effective key length offered is 112 or 168 bits.

IDEA: Algorithm with a key length of 128 bits. This algorithm has been patented in the USA and Europe (its noncommercial use is free); the patent expired in 2011.

Blowfish: Algorithm with a variable key length of up to 448 bits. It was developed by Bruce Schneier. It is unpatented and license-free and it can be freely used by anyone.

AES (Advanced Encryption Standard): Successor to DES. In 1993, the National Institute of Standards and Technology (NIST) decided that DES no longer met today’s security requirements, and it organized a competition for a new standard encryption algorithm. The winner of this competition was announced on October 2, 2000, and is the Rijndael algorithm, which supports key lengths of 128, 192, or 256 bits.

• Asymmetric:

In an asymmetric encryption there are two keys—a private key and a public key. Data that has been encrypted with the private key can be decrypted only with the public key. Data encrypted with the public key can be decrypted only with the private key. While the public and private key are mathematically linked, it is mathematically difficult (and infeasible in practice) to deduct the private key from the public key. Therefore the public key can be freely distributed.

The main advantage of asymmetric encryption is the fact that key management is relatively easy. The public key can be distributed freely. However, as anyone can create public/private key pairs, the problem remains that a public key needs to be linked to a certain person or entity (such as a website). Solutions to the problem are Certification Authorities (SSL and TLS use these) or the so-called “Web of Trust” (used by PGP). Both have their advantages and shortcomings.

Asymmetric encryption procedures tend to be much slower than symmetric procedures. As a result, symmetric and asymmetric procedures are often combined. In fact, SSH uses a combination of both procedures. For example, a key for symmetric encryption can be transmitted through a channel encrypted asymmetrically.

Some important asymmetric cryptographic procedures include the following:

RSA: The name is derived from the surnames of its developers: Rivest, Shamir, and Adleman. Its security is mainly based on the fact that it is easy to multiply two large prime numbers, but it is difficult to regain the factors from this product.

DSA: (Digital Signature Algorithm) A US Federal Government standard for digital signatures.

Diffie-Hellman-Merkle: This key exchange describes a method to establish cryptographic keys securely without having to send the keys across insecure channels. Such a key can then be used as a secret key in symmetric encryption. The algorithm also allows public/private key generation.

Keys for asymmetric encryption need to be much longer than those used for symmetric procedures. For example, the minimum key length currently considered secure with RSA is 2048 bits.

SSH v2 Connection Process

Attach:netsrv1.png

Version 1 of the SSH protocol does not have a mechanism to ensure the integrity of a connection. This allows attackers to insert data packets into an existing connection (an insertion attack). Version 1 of the SSH protocol should therefore not be used anymore.

The main difference between version 1 and and version 2 of the SSH protocol is the mechanisms within the protocol that guarantee the integrity of the connection. A keyed-hash message authentication code (HMAC) is used for this purpose. The mechanism for the session key agreement (Diffie-Hellman) is different as well.

To see which SSH version an SSH server supports, you can log in to port 22 using a Telnet client:

    geeko@server1:~> telnet da20 22
    Trying 192.168.1.20...
    Connected to da20.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_6.6.1

SSH-2.0-... is used for version 2 only, SSH-1.99-... would be used if version 1 and 2 are possible, and SSH-1.5-... for version 1 only.

In the OpenSSH server configuration file(/etc/ssh/sshd_config), the Protocol parameter defines which protocol versions are supported. In SLES 12 this is set to 2.

Connection via SSH

• Secure Shell

• Secure Copy

• Secure FTP

    geeko@da20:~> sftp root@da1.digitalarilines.com
    sftp> get /etc/motd
    sftp> quit

Built into ssh is the ability to automatically redirect X applications output back through a SSH connection. To do this use the -X option for the ssh command when connecting to the remote host:

or

Retrieve SSH Host Keys

• When you contact an unknown server, you must download its host key if you don't already have it in your ~/.ssh/known_hosts file

Attach:netsrv2.png

To ensure security and to defend against man-in-the-middle attacks, the client needs to verify that the public host key of the server really belongs to the server.

SSH currently does not support directory services (such as LDAP) or certificates (such as with SSL) for public key management. This means that anyone, even a potential attacker, can easily create a random key pair and include it in the authentication dialog.

When you contact an unknown server, a fingerprint of its hostkey is displayed, as shown above. The administrator of the server can view the fingerprint with the ssh-keygen -l command and the fingerprints can be compared, for instance via telephone.

It is possible to learn the server's host key. When you do, the SSH client writes this key to the local key database, ~/.ssh/known_hosts. In the /etc/ssh/ssh_known_hosts file, the system administrator can provide host keys for the whole system.

Manually Retrieve SSH Host Keys

• ssh-keyscan can be used to retrieve ssh host keys without actually logging in to the ssh server.

Attach:netsrv3.png

The output of the ssh-keyscan command can be written to the ~/.ssh/known_hosts or the /etc/ssh/ssh_known_hosts file. When you contact a server whose host key is in one of those files you are not asked for confirmation before connecting to that server.

Changed SSH Host Keys

• When you contact a server whose host key is different from the key you have in your ~/.ssh/known_hosts file, a warning is shown:

Attach:netsrv4.png

If you connect to a server whose host key has changed, you are warned, depending on the ssh client configuration. You can follow the instructions shown above to connect to the server, but you should verify the new key with the administrator of the system you want to connect to.

If you want to constrain client connections to only SSH servers whose keys have already been added to the ~/.ssh/known_hosts or /etc/ssh/ssh_known_hosts files, you can set the StrictHostKeyChecking option in the client configuration file (~/.ssh/config or /etc/ssh/ssh_config) to yes. This prevents the SSH client from simply adding new keys from unknown servers to ~/.ssh/known_hosts when connecting to unknown servers. Any new keys have to be added manually using an editor. In this configuration, connections to a server whose key is unknown or has changed are refused.

The default setting is ask, which means that the user is asked for permission before a new key is entered. A setting of no permitts to automatically add new keys.

Configure an SSH Server

• The server configuration file is /etc/ssh/sshd_config

Attach:netsrv5.png

For additional information on SSH server configuration options, enter man sshd and man sshd_config at the shell prompt.

Authenticate Users

• Users can authenticate using

• Configuration settings in /etc/ssh/sshd_config determine which is used

In the default configuration, username and password are used to authenticate to the server. In /etc/ssh/sshd_config, the following parameters are set:

    ChallengeResponseAuthentication yes
    UsePAM yes
    PasswordAuthentication no

Password authentication works despite the last parameter because of the UsePAM yes setting. The comments above the UsePAM setting in the /etc/ssh/sshd_config file explain this.

Public Key Authentication

• On the client, create a public/private key pair using the ssh-keygen command.
• Copy the public key to the ~/.ssh/authorized_keys file of the appropriate account on the server you want to connect.
• On the server, turn off password authentication by setting ChallengeResponseAuthentication no in /etc/ssh/sshd_config

If you turn off password authentication, only users that have their public keys in the ~/.ssh/authorized_keys file can log in. In view of the fact that ssh servers are constantly probed with password guessing attempts, this setting is recommended.

After successful authentication, a work environment is created on the server. For this purpose, environment variables are set (TERM and DISPLAY), and X11 connections are redirected if this is permitted. The X11Forwarding parameter in the SSH server configuration file (/etc/ssh/sshd_config) determines whether or not the graphical output is forwarded when the client requests it. If you want to use X forwarding, you must set the parameter to Yes and you must start the SSH client with the -X option (or set ForwardX11 yes in ~/.ssh/config, either in general or for specific hosts).

NOTE: The redirection of the X11 connections works only if the DISPLAY variable set by SSH is not subsequently changed by the user. The SSH daemon must appear to the X11 applications as a local X11 server, which requires a corresponding setting of DISPLAY. In addition, the program xauth (used to edit and display the authorization information used in connecting to the X server) must exist. This program is contained in the xorg-x11-xauth package.

Configure the SSH Client

• You can also configure the SSH client system.

The precedence for configuration options is:

• Command line options
• ~/.ssh/config
• /etc/ssh/ssh_config
• ssh-keygen allows you to generate ssh keys that can be used either as host keys or individual user keys.

Attach:netsrv6.png

The secret key should be protected by a passphrase. Without passphrase protection, simply owning the file containing the private key is sufficient for a successful authentication. However, if the key is additionally protected with a passphrase, the file is useless if you do not know the passphrase.

Using keys that are not protected by a passphrase is nevertheless useful when access to other servers is needed as part of shell scripts.

The keys are stored in the ~/.ssh directory. For SSH1, the default for these files is ~/.ssh/identity (private key) and ~/.ssh/identity.pub (public key). For SSH2, the default files are @~/.ssh/id_rsa and ~/.ssh/id_dsa@@, respectively, plus the corresponding public key files with the .pub extension.

Upload Public Key to Server

• Copy the public key to the server:

• Append the public key file to ~/.ssh/authorized_keys:

    geeko@da10:~> ssh geeko@da50
    Password:
    Last login: Fri May 30 12:03:29 2014 from da10.digitalairlines.com
    geeko@da50:~> cat geeko-pubkey >> ~/.ssh/authorized_keys
    geeko@da50:~> exit

• Verify authentication with the DSA key:

    geeko@da10:~> ssh geeko@da50
    Enter passphrase for key '/home/geeko/.ssh/id_dsa':
    Last login: Fri May 30 12:03:40 2014 from da10.digitalairlines.com

• Alternative: Use ssh-copy-id

    geeko@da10:~> ssh-copy-id -i /home/geeko/.ssh/id_dsa.pub geeko@da50
    Password:

Use the SSH Agent

• The ssh-agent can be used to eliminate the need to type the passphrase upon each connection
• After starting the ssh-agent it is necessary to once enter the passphrase for the key using the ssh-add command

Attach:netsrv7.png

• No check for passphrase afterwards:

Attach:netsrv8.png

The SSH agent can be used to eliminate the need to type the passphrase upon each connection. The SSH Agent serves as a wrapper for other processes. Start ssh-agent and enter the passphrase using the ssh-agent command. After that, ssh-agent monitors all SSH requests and provides the required private key as necessary.

You can also use ssh-agent with a graphical login. If you log in by using a display manager, the X server loads the /etc/X11/xdm/sys.xsession file. Add the usessh=”yes” parameter to the sys.xsession file (this parameter is set by default in SLES 12).The SSH Agent starts automatically the next time the user logs in to the graphical interface and can use ssh-add in a terminal window to provide the passphrase for the private keys (without having to start the ssh-agent, as it is already running).

SSH Command Summary

Attach:netsrv9.png

Tunnel Unencrypted Traffic via SSH

• Tunnel traffic to a local port to a remote host

Attach:netsrv10.png

SSH can be used to tunnel connections in a secure fashion. In this example the insecure POP3 protocol (port 110) is being tunneled through ssh by attaching it to the local port 4242.

If you do not need the ssh connection and just want to forward ports, use the -f (fork) -N (no command) options. The ssh connection will then run in the background.

The email client would be configured to connect to port 4242 on server1. SSH would then redirect and tunnel that traffic to port 110 on the destination host.

Another scenario would be that you want to connect to a Web server through an ssh tunnel, assuming that you are allowed to log in to the Web server with ssh:

You could then connect with your browser to port 8080 on localhost (http://localhost:8080) to view the Web pages on www.example.com, through an encrypted tunnel.

• Tunnel traffic to a remote port back to the local host
• Tunnel traffic to a local port to a remote host

Attach:netsrv11.png

In this example the insecure POP3 protocol (port 110) is being tunneled through ssh by attaching it to the remote port 4242.

The email client would be configured to connect to port 4242 on server2. SSH would then redirect and tunnel that traffic to port 110 on the destination host (server1 in the example above).

• Tunnel traffic to a local port via an SSH Server to a remote host

Attach:netsrv12.png

In this example the insecure POP3 protocol (port 110) is being tunneled from server 1 by ssh to server2 and from there in clear text to port 110 of the destination host by attaching it to the local port 4242.

The email client would be configured to connect to port 4242 on server1. SSH would then redirect and tunnel that traffic to server2, and then from there to port 110 on the destination host (server3 in the example above).

Other uses of SSH include using ssh as a SOCKS server with the D port option, or use SSH to set up a Virtual Private Network (VPN). For details on how to set up a VPN, see the SSH manual page.

Warning: Tunneling traffic as shown above can be used to create tunnels through firewalls which may very well be forbidden by company policy. Before setting up any tunnel with ssh, make sure that doing so does not violate any existing security policy.