Linux Servers : SSH Server

SSH Server

What Is SSH?

There are a couple of ways that you can access a shell (command line) remotely on most Linux/Unix systems. One of the older ways is to use the telnet program, which is available on most network capable operating systems. Accessing a shell account through the telnet method though poses a danger in that everything that you send or receive over that telnet session is visible in plain text on your local network, and the local network of the machine you are connecting to. So anyone who can "sniff" the connection in-between can see your username, password, email that you read, and commands that you run. For these reasons you need a more sophisticated program than telnet to connect to a remote host. 

An unencrypted telnet session SSH, which is an acronym for Secure Shell, was designed and created to provide the best security when accessing another computer remotely. Not only does it encrypt the session, it also provides better authentication facilities, as well as features like secure file transfer, X session forwarding, port forwarding and more so that you can increase the security of other protocols. It can use different forms of encryption ranging anywhere from 512 bit on up to as high as 32768 bits and includes ciphers like AES (Advanced Encryption Scheme), Triple DES, Blowfish, CAST128 or Arcfour. Of course, the higher the bits, the longer it will take to generate and use keys as well as the longer it will take to pass data over the connection. 

An encrypted ssh session

These two diagrams on the left show how a telnet session can be viewed by anyone on the network by using a sniffing program like Ethereal (now called Wireshark) or tcpdump. It is really rather trivial to do this and so anyone on the network can steal your passwords and other information. The first diagram shows user jsmith logging in to a remote server through a telnet connection. He types his username jsmith and password C0lts06!, which are viewable by anyone who is using the same networks that he is using.

The second diagram shows how the data in an encrypted connection like SSH is encrypted on the network and so cannot be read by anyone who doesn't have the session-negotiated keys, which is just a fancy way of saying the data is scrambled. The server still can read the information, but only after negotiating the encrypted session with the client. 

Package-                 openssh
Port-                        22
Daemon-                 sshd  
Script-                     /etc/init.d/sshd
Configuration file-/etc/ssh/sshd_config

Private keys

Private key must be secure and used only by you to decrypt messages encrypted with you public key. Secure SSH encrypted communications are based on keeping the private key secure.

Public keys

Public key is publicly available. The recipient of your messages will encrypt the data with your public key that previously you have send. Only you using your private key will be able to decrypt that message.

SSH Tools

These are the most basic SSH tools than a Linux user must be aware.

sshd

The daemon service that implements the ssh server. By default it must be listening on port 22 TCP/IP.

ssh

The Secure Shell command ssh is a secure way to log and execute commands in to a remote machine using the private/public key encryption method replacing the insecure tools traditionally used for it: telnet, rlogin, rexec, rsh, etc.

scp

The Secure Copy command is a secure way to transfer files between computers using the private/public key encryption method replacing the insecure tool traditionally used for it: ftp.

ssh-keygen

This utility is used to create the public/private keys with the command 'ssh-keygen -t keytype' where keytype can be DSA (Digital Secure Algorithm) or RSA1 (RSA Security). Later in this lesson will be shown how to use it.

ssh-agent

This utility holds private keys used for RSA authentication. The idea is that the ssh-agent command is started in the beginning of an X session or a login session, and all other windows or programs are started as clients to the ssh-agent program. In this way all clients of the ssh-agent can remember through the use of environment variables the public/private keys used when ssh-agent was started, so the user will not be ask for this in all these client sessions.

ssh-add

Adds RSA identities to the authentication agent ssh-agent

SSH Server

The SSH server configuration file is /etc/ssh/sshd_config. This file is well commented so just having a look on it one can understand the meaning of the main directives.

# cat /etc/ssh/sshd_config # This directive configures SSH version 2, which is more secure that version 1 
Protocol 2 # The following sends all logging attempts to the appropriate log file /var/log/secure 
SyslogFacility AUTHPRIV # This directive authorizes authentication based on local user passwords 
PasswordAuthentication yes # Set this to 'yes' to enable PAM authentication, account processing, and session processing 
UsePAM yes # The following directive allows to open remote GUI tools executed through SSH using the local X Server 
X11Forwarding yes # This directive supports the use of SSH encryption for secure FTP file transfers 
Subsystem sftp /usr/libexec/openssh/sftp-server

Once the configuration file has been set lets start the ssh server and make sure it will start at system boot.

# /etc/init.d/sshd restart
# chkconfig sshd on

SSH client

The SSH client standard configuration file for all system is /etc/ssh/ssh_config. Each user can have custom SSH client configurations in their ~/.ssh/config files.

Some examples of SSH client tools can be :

ssh

Allows to login and execute shell commands on remote systems.

node01> ssh rhel6 -l khan
It will login as khan on rhel6 system.

node01> ssh rhel6 "ls -lrt /home/khan".
It will execute the command 'ls -lrt /home/khan' as user khan on rhel6 system. The command output is displayed on node01 the SSH client from where are launched the connection

scp

Used to transfer data between computer systems using SSH.

node01> scp /tmp/file.txt khan@rhel6:/tmp/file.txt
This command will transfer file /tmp/file.txt from SSH client node01 to SSH server rhel6 on /tmp directory using 'khan' account.

node01> scp -r khan@rhel6:/tmp/dir /tmp/
This command will transfer from SSH client rhel6 the directory /tmp/dir to the SSH server node01 on /tmp dir using 'khan' account. In this case node01 receives the data so node01 is the SSH server, sshd daemon must be running on node01.

SSH Security

Firewall

As has been commented the sshd server listen on port 22 TCP/IP so this port must be open in order to allow ssh server service through a firewall.

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

User and Host Based Security

Some additional directives can be added to /etc/sshd/sshd_config file in order to make the access to ssh server more restrictive.

# Do not allow empty passwords
PermitEmptyPasswords no

# The following directive will not allow to root user to log on the system using ssh. (Do not allow remote root logins)
PermitRootLogin no

# Limit the users allowed to access a system via SSH. In this case only users 'khan' and 'charles' are allowed to login on the system using SSH
AllowUsers khan charles

# Or even more restrictive, only allow login through SSH users 'khan' and 'charles' from 192.168.1.101 node.
AllowUsers khan@192.168.1.101 charles@192.168.1.101

# In addition you can restrict the access to users. In this case all users less 'khan' are allowed to connect to the SSH server.
DenyUsers khan

SSH using only public/private keys

If the system where SSH server is running is directly connected to the Internet it will be a good idea to disable password authentication on the SSH server and allow only public/private keys authentication. This will reduce dramatically the chance that a cracker has login on your system because the probability that he has to guess the pair user/private_key is much lower that user/password pair. In order to accomplish this the following directives must be changed/added to /etc/ssh/sshd_config file.

# cat /etc/ssh/sshd_config
...
# Do not allow password authentication
PasswordAuthentication no

# Allow public/private key authentication
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
...

Next step is create the public/private key pair on the ssh client node01 from where are going to connect to the SSH server (rhel6).

node01> su - khan
khan-$>ssh-keygen -t dsa (It will ask for a passphrase in order to protect your private key on the local node)

This command will create khan private key on /home/khan/.ssh/id_dsa (permissions 600) and khan public key on /home/khan/.ssh/id_dsa.pub (permissions 644)

Change de .ssh directory permissions to 755.

khan-$> chmod 755 .ssh

Copy the content of /home/khan/.ssh/id_dsa.pub (khan public key) generated on node01 (the node from we want to login as khan on SSH server) to /home/khan/.ssh/authorized_keys on SSH server. If necessary create /home/khan/.ssh directory with permission 755 on SSH server.

khan-$> cat /home/khan/.ssh/id_dsa.pub --> >> SSH server(rhel6):/home/khan/.ssh/authorized_keys

On SSH server (rhel6) change the permissions of /home/khan/.ssh/authorized_keys to 644.

# chmod 644 /home/khan/.ssh/authorized_keys

The final step is restart the ssh server and verify that you can connect from SSH client (node01) to SSH server (rhel6) only using public/private key and not using the user password. Have a look on Lab2.

# /etc/init.d/sshd reload

Note: In order to use the private key on SSH client to connect to SSH server the passphrase introduced when the private key has been created with 'ssh-keygen' is asked. If you have left this passphrase empty you will be able to login to SSH server directly without passphrase BUT using your public/private keys. We do not recommend to left this passphrase empty but in any case this method is more secure that using standard password because in this case the cracker must guess the public/private keys that normaly are random strings with at least 512K of size !!!

Using ssh-agent

When we are running a graphical environment on SSH client as gnome or kde we can use the ssh-add utility in order to do not have to enter the passphrase every time we try to connect to the SSH server.

khan-$> exec /usr/bin/ssh-agent $SHELL
khan-$> ssh-add
(--> Enter khan passphrase)

The khan passphrase now is stored in the environment variables for 'khan' graphical session, so khan must not be to retype his passphrase any time that try to login to the SSH server from this graphical environment on SSH client.

SSH Port Forwarding

SSH can secure insecure TCP/IP protocols via port forwarding, SSH server becomes an encrypted conduit to the SSH client. Port forwarding maps a local port on the SSH client to a remote port on the SSH server.

client> ssh -l khan -L 2525:server.info.net:25 server.info.net

Once the user khan has been logged on server.info.net through this ssh connection an SSH encrypted Tunnel has been established between port 25 TCP/IP on server.info.net and port 2525 TCP/IP on client.info.com. In this way if you execute the command 'telnet localhost 2525' on client.info.com you are making the telnet directly to port 25 TCP/IP on server.info.net.

client> telnet localhost 2525
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 server.info.net ESMTP Sendmail 8.13.8/8.13.8; Fri, 25 Mar 2011 13:18:29 +0100

!!! IT IS MAGIC !!!

If you want forward a port from a machine that is not running an SSH server, but another machine on the same network is, SSH can still be used to secure a SSH tunnel.

client> ssh -l khan -L 1100:pop.info.net:110 server.info.net

With this command you are making a ssh tunnel from pop.info.net:110 (that is not running an SSH server) to your local machine client.info.com:1100 connecting as user 'khan' on server.info.net that is in the same LAN as pop.info.net. As POP service does not encrypt the data itself, with the SSH tunnel the data is encrypted by SSH, so you are making more secure the connection to your pop service.

Note: SSH Tunnels can be used to skip firewalls. Imagine that there is a firewall that blocks the connection between your local machine client.info.com and your POP service on pop.info.net port 110 TCP/IP. If the firewall is not blocking access to the SSH server on pop.info.net:22 (or a machine in the same LAN running SSH server) you can establish an SSH tunnel from client.info.com:110 and pop.info.net:1100 and skip the firewall. !!! In reality you can forward any port and skip the firewall if you can connect through ssh!!!

Maybe for security reasons you want to disable port forwarding through your SSH server. In this case the following directive must be configured on the SSH server configuration file /etc/ssh/sshd_config and then reload the SSH server service.

Reference  http://support.suso.com/supki/SSH_Tutorial_for_Linux

- See more at: http://www.linuxforfreshers.com/p/ssh-server.html#sthash.afRNG6Zg.dpuf