Connecting to Linux Remotely - Getting the Best from SSH
Connecting to Linux Remotely - Getting the Best from SSH
Contents
1. Introduction.
2. What is SSH?
3. Configuring SSH for Security.
4. Setting up Tunnels.
5. Links.
1. Introduction
This tutorial will assist you to set up SSH for Linux. SSH will allow you full access to any TCP/IP services or ports on a Linux server with only port 22 (SSH) open through your firewall. By ensuring the SSH connection is secure and closing access to other ports and services it is possible to allow very good connectivity and access to a Linux server without the necessary expertise required to secure every service required.
This tutorial will be written with a RedHat 9 (RH9) perspective, but should apply to most flavours of *nix.
2. What is SSH?
SSH stands for Secure SHell and is
Quoting from the man page:
Quote:
ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel.
SSH has two parts, an SSH Daemon (sshd) which runs on the remote server and a client (ssh) which is used to connect to the remote server from a local machine.
3. Configuring SSH for security.
Download the latest version for you distribution, both on the server and the client.
For RH9 keeping up to date with the Red Hat Network will accomplish this.
On your firewall close all ports except for port 22 (SSH)
On the Server as su-:
edit /etc/ssh/sshd_config and ensure the line for protocol is not commented with a hash and does not allow protocol 1, since this has poor security and passwords can be obtained from packet sniffing tools like ettercap:
Quote:
#Port 22
Protocol 2
#ListenAddress 0.0.0.0
Make sure the service is running/restarted:
service sshd restart
This should give adequate security for most uses of SSH. To test this on the client, open a terminal and type:
ssh server.username@server.internet.name or using the IP address of the server:
ssh server.username@192.168.1.1 where server.username is the name of the account on the server. (If the username on the client and server computers are the same then server.username@ can be ommitted.
The first time this is done you will see a message similar to:
Quote:
The authenticity of host 'server.internet.name (192.168.1.1)' can't be established.
RSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)?
The names will be different and the key fingerprint will have hex data in it, which will be specific to the server. Typing yes to accept the fingerprint will allow continuation, but this should only be accepted if you are confident that you are correctly connected to the server. you can verify the fingerprint physically from the server by typing:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
Once you have accepted the key you will then be asked for your password (for the account server.username on the server). Type in the password (don't worry, the connection is already encrypyted at this point) and if correct you will have a shell prompt for the account server.username on the server.
The key will be added to the file ~/.ssh/known_hosts on the client.
If you use SSH to connect to server.internet.name and obtain a message similar to:
Quote:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for server.internet.name has changed,
and the key for the according IP address 192.168.1.1
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Please contact your system administrator.
Add correct host key in /home/client.username/.ssh/known_hosts to get rid of this message.Offending key in /home/client.username/.ssh/known_hosts:1
RSA host key for internet.server.name has changed and you have requested strict checking.Host key verification failed.
You should heed the warning unless you are absolutely certain that the server has changed its key for some legitimate reason. In which case edit the ~/.ssh/known_hosts file and remove the key and try again.
Make sure that you use strong passwords for the server account you are using since a weak password can easily be cracked with a brute force attack.
4. Setting up Tunnels.
So what good is all of this? You can now set up secure tunnels for your services so that they can be accessed from the client computer, without being visible to anyone outside of the firewall.
X11 Forwarding.
This should be set up by default but if not add the following line to ~/.ssh/config on the client computer.
Now typing the command of any X11 program into the SSH shell on the Server will start an X11 program on the server, but will display it on the Client X screen. The efficiency of this will depend upon your connection speed. Try typing mozilla - This will display mozilla on the client, but you will actually be browsing from the server.
Other tunnels can be setup for any service on the server by modifying the ~/.ssh/config file:
Quote:
# Forwarding Ports
# vnc Screen 1
LocalForward 5901 192.168.1.1:5901
# http Webmin
LocalForward 10001 127.0.0.1:10000
# http Router
LocalForward 80 192.168.1.254:80
A brief explanation of what these do should help setting your own.
VNC: The server has VNC listening on port 5901. Typing vncviewer localhost:5901 on the client will connect a VNC session to the server since port 5901 on the client is forwarded to port 5901 on the client.
Webmin: Webmin is a web based configuration tool for linux. Webmin on the server is listening on port 10000, but since the client also has webmin listening on port 10000 then port 10000 can not be mapped to 10000. In this case we map port 10001. Webmin on the server is configured only to accept connections from localhost, so the address of 127.0.0.1 is used. Typing the url localhost:10001 into a browser on the client will connect to Webmin on the server.
Router: The ADSL router for the server is configured by a web connection, but it set up so that it can not be configured from the WAN. It's LAN address is 192.168.1.254. Typing the url localhost into a browser on the client will connect to the configuration of the ADSL Router.
Differing servers can be configured differently in the ~/.ssh/config file:
Quote:
host internet.server.name
# Forwarding Ports
# vnc Screen 1
LocalForward 5901 192.168.1.1:5901
# http Webmin
LocalForward 10001 127.0.0.1:10000
# http Router
LocalForward 80 192.168.1.254:80
host another.server.name
# Forwarding Ports
# http Webmin
LocalForward 10002 127.0.0.1:10000
# smtp
LocalForward 25 127.0.0.1:80
5. Links
Open SSH : http://www.openssh.com
Redhat : http://www.redhat.com
Redhat Network : http://rhn.redhat.com
VNC : http://www.tightvnc.com
Webmin : http://www.webmin.com
Ettercap : http://ettercap.sourceforge.net
