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
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.
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 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.
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
-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
# 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 !!!
# 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.
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.
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.
No comments:
Post a Comment