Herman Oosthuysen
July 2002
System: Mandrake 8.1
The Secure Shell, is an incredibly powerful utility. It allows you to completely control one Unix machine from another. You can not only transfer files between computers securely, but you can execute programs remotely, with the screen display forwarded to the local machine, all the while being completely safe from eavesdroppers.
In effect, ssh makes your keyboard and monitor independent from the box it is connected to. You can be at home and work as if you are at your office, or the other way around. This is the ultimate telecommuting solution in one application and has been part of Unix for decades. While this sounds complex to a MS Windows user, working on multiple computers from a single terminal is as natural on a Unix system, as a penquin takes to water...
When running applications on multiple machines, it can be difficult to remember what is running where, but KDE on Linux features multiple desktops (virtual screens). I usually use the first screens for the local machine and the last screens for the distant machine, to help keep my wits together.
Installing and running the secure shell, should be dead simple. If it isn't, then you either have an old version or mis-matched versions at the two sites, or more likely you have a firewall or TCP Wrappers problem, preventing a connection from being established.
Note that there are many ssh versions: ssh1, ssh2 and openssh. That is apart from the commercial versions of ssh - ssh2 is preferred.
Other howto guides explain how to get a connection up, but fail to give any trouble-shooting advice. Figuring out why it won't work can be a harrowing experience with secure systems, since NOT telling you what is wrong, is also a security requirement, since you don't want to make it easy for an intruder. This guide tries to fill this gap.
Do not change the default configuration files ssh_config or sshd_config until you have the basic setup working and even then, the default is probably OK for a home user, but not for a corporate user. See Batting Down the Hatches below.
Use the Control Centre, Services and stop the sshd daemon (or do killall sshd).
You must have the same user name on both systems, the server and the remote system. This keeps it easy.
Logged in as the required user, generate a set of RSA keys:
The following keys are generated in directory ~/.ssh:
Copy the public key to authorized_keys to give you permission to log into the server from its own terminal:
Find your server IP address using ifconfig:
Restart sshd from Control Centre, Services. (or killall sshd and run it again).
Try to log into the server from its own terminal. If it doesn't work here, it won't work remotely:
If all went well, you'll be asked for your passphrase and after that you'll get a message like: Last login: time and date.
The very first time, you'll get a message like: Warning: Permanently added www.xxx.yyy.zzz to the list of known hosts.
After this, you'll get a new shell prompt and the shell will work as usual, except that it is now a ssh session. Type exit, to get back to a normal session.
If sshd is dead or unreachable, you will get the message: ssh: Connect to www.xxx.yyy.zzz port 22: Connection refused.
On a server with two ethernet cards, sshd will by default listen on both ethernet interfaces, on port 22. This is usually what you want.
If you can't log in using the one IP address, try the other one.
If the local interface works, but the external interface doesn't, the trouble lies with your firewall.
Ensure that port 22 is open for TCP and UDP traffic:
will tell you what the firewall is doing. If required, modify the file /etc/rc.d/rc.firewall.
Add someting like the following rules:
to poke a hole for port 22 in the firewall.
Restart the firewall and try to log in again:
Confirm that the new rules are OK with iptables -L as before.
TCP Wrappers presents another layer of firewalling which you may have to reckon with.
If you have poked a hole in the iptables firewall and ssh still doesn't want to connect, edit the file /etc/hosts.allow and add the following line:
Now try again. This should be the last issue.
Basically, you need to give your local public key to the remote
system in order to log into the remote from the local system.
Once you can log in from the local terminal using the external ethernet interface IP address, generate and distribute the public keys so that the server has all the remote public keys in its authorized_keys file and try to log in from the remote.
RSA keys of 2048 bits are recommended. This is secure as of the time of writing and should remain secure for the next five years or so, given the current rate of computer progress.
Note that each public key is a single line, a very long one. Do not use an editor that will truncate or wrap the lines - vi to the rescue... well, I use gedit, do not use kate.
The ssh system only use the RSA public and private keys to authenticate the remote machines (to ensure that only valid users log in). Session keys for data transfer are generated automatically at regular intervals. The default encryption method used for data transfer is the Blowfish algorithm by Bruce Schneier, which is still known to be secure as of writing. The result is a very fast and secure link.
Ssh2 offers sftp as a Subsystem. This is configured at the bottom of the file /etc/ssh/sshd_config. The default install of the program sftp-server is in /usr/lib/ssh, but the program should be in the user path, to allow sshd to execute it. Look at the last line of the /etc/ssh/sshd_config file and modify it to read:
and make a link to it from /usr/bin:
Now, you can use the sftp program or the gftp GUI program for secure ftp transfers. The gftp GUI program is recommended.
Windows users can use the PuTTY program available from http://www.chiark.greenend.org.uk/~sgtatham/putty/ for secure ftp or telnet access. PuTTY is text based and runs in a DOS box - nothing fancy, but it gets the job done. It consists of a collection of small programs, to do telnet (not useful to windoze users), ftp (for file transfer) and key generation (for authentication).
Basically, once you made and distributed your keys, you only need to run psftp. RSA keys of 2048 bits in size are recommended.
Why PuTTY? Because it can be used to repair broken windows... ;-)
A Google search should yield many other possibilities, but it is best to start off with a simple client until you have your keys and IP addresses under control. Also, PuTTY is free of charge, while more fancy programs are anything but.
The usual FTP commands work with PuTTY. Here is a brief list of the most frequently used commands:
If you only need to do occational file transfers, a simple FTP client like this is OK.
Once you are confident that the system works, examine the /etc/ssh/sshd_config file and disable simple password based log in. Also consider disabling root log in.
Look for the following lines and change them to no:
To discourage trivial attacks following port scans, it is recommended that you do not use the default ssh port 22 for communication, but rather change it to something else, such as the now obsolete gopher port 70, or the defunct Napster port 6699, which will confuse your average script kiddie.
You can monitor what the sshd daemon is doing by looking at the messages log file. Open a terminal as root and keep tail running:
Don't bother trying to log in from a remote station, if you cannot do the same from the local machine's own keyboard...