Linux
Secure Shell(SSH)
OpenSSH
is the open source version of SSH secure shell protocol. It provides
secure (encrypted) communication between systems using a
client/server architecture. It allows users to log into remote
systems or execute remote commands in a safe way because of all data
transferred between ssh client and server is encrypted. It also
allows secure (encrypted) data transfers between systems using scp
or sftp
the encrypted secure FTP version.
By default SSH tools are installed on RHEL6 systems, the openssh* rpms are included on the default installation. The server daemon sshd listens on port 22 TCP/IP and the configuration files are located in the /etc/ssh directory.
By default SSH tools are installed on RHEL6 systems, the openssh* rpms are included on the default installation. The server daemon sshd listens on port 22 TCP/IP and the configuration files are located in the /etc/ssh directory.
Introduction to Encryption
Encryption with SSH requires a private key and a public
key, generated by 'ssh-keygen' command. In order to establish
an SSH encrypted communication between you and others the first step
is send your public key to others keeping always your private key
private. When others want to send data to you through SSH, their
messages are encrypted with your public key that you have send
previously. Your computer can decrypt the message with your private
key. As can be seen the public and private keys are related with not
easy to guess mathematical algorithms.
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.
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.
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
# 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 john
It will login as john on rhel6 system.
node01> ssh rhel6 "ls -lrt /home/john".
It will execute the command 'ls -lrt /home/john' as user john 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 john@rhel6:/tmp/file.txt
This command will transfer file /tmp/file.txt from SSH client node01 to SSH server rhel6 on /tmp directory using 'john' account.
node01> scp -r john@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 'john' account. In this case node01 receives the data so node01 is the SSH server, sshd daemon must be running on node01.
Some examples of SSH client tools can be :
ssh
Allows to login and execute shell commands on remote systems.
node01> ssh rhel6 -l john
It will login as john on rhel6 system.
node01> ssh rhel6 "ls -lrt /home/john".
It will execute the command 'ls -lrt /home/john' as user john 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 john@rhel6:/tmp/file.txt
This command will transfer file /tmp/file.txt from SSH client node01 to SSH server rhel6 on /tmp directory using 'john' account.
node01> scp -r john@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 'john' 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
-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 'john' and 'charles' are allowed to login on the system using SSH
AllowUsers john charles
# Or even more restrictive, only allow login through SSH users 'john' and 'charles' from 192.168.1.101 node.
AllowUsers john@192.168.1.101 charles@192.168.1.101
# In addition you can restrict the access to users. In this case all users less 'john' are allowed to connect to the SSH server.
DenyUsers john
# 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 'john' and 'charles' are allowed to login on the system using SSH
AllowUsers john charles
# Or even more restrictive, only allow login through SSH users 'john' and 'charles' from 192.168.1.101 node.
AllowUsers john@192.168.1.101 charles@192.168.1.101
# In addition you can restrict the access to users. In this case all users less 'john' are allowed to connect to the SSH server.
DenyUsers john
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 - john
john-$>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 john private key on /home/john/.ssh/id_dsa (permissions 600) and john public key on /home/john/.ssh/id_dsa.pub (permissions 644)
Change de .ssh directory permissions to 755.
john-$> chmod 755 .ssh
Copy the content of /home/john/.ssh/id_dsa.pub (john public key) generated on node01 (the node from we want to login as john on SSH server) to /home/john/.ssh/authorized_keys on SSH server. If necessary create /home/john/.ssh directory with permission 755 on SSH server.
john-$> cat /home/john/.ssh/id_dsa.pub --> >> SSH server(rhel6):/home/john/.ssh/authorized_keys
On SSH server (rhel6) change the permissions of /home/john/.ssh/authorized_keys to 644.
# chmod 644 /home/john/.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 !!!
# 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 - john
john-$>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 john private key on /home/john/.ssh/id_dsa (permissions 600) and john public key on /home/john/.ssh/id_dsa.pub (permissions 644)
Change de .ssh directory permissions to 755.
john-$> chmod 755 .ssh
Copy the content of /home/john/.ssh/id_dsa.pub (john public key) generated on node01 (the node from we want to login as john on SSH server) to /home/john/.ssh/authorized_keys on SSH server. If necessary create /home/john/.ssh directory with permission 755 on SSH server.
john-$> cat /home/john/.ssh/id_dsa.pub --> >> SSH server(rhel6):/home/john/.ssh/authorized_keys
On SSH server (rhel6) change the permissions of /home/john/.ssh/authorized_keys to 644.
# chmod 644 /home/john/.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.
john-$> exec /usr/bin/ssh-agent $SHELL
john-$> ssh-add
(--> Enter john passphrase)
The john passphrase now is stored in the environment variables for 'john' graphical session, so john must not be to retype his passphrase any time that try to login to the SSH server from this graphical environment on SSH client.
john-$> exec /usr/bin/ssh-agent $SHELL
john-$> ssh-add
(--> Enter john passphrase)
The john passphrase now is stored in the environment variables for 'john' graphical session, so john 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 john -L 2525:server.info.net:25 server.info.net
Once the user john 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 john -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 'john' 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.
AllowTcpForwarding no
client> ssh -l john -L 2525:server.info.net:25 server.info.net
Once the user john 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 john -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 'john' 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.
AllowTcpForwarding no
No comments :
Post a Comment