Securing Terminal Traffic (SSH)

Terminal traffic, which is typically from the Telnet or rlogin application, is a result of remote users interacting with UNIX systems; you are probably accustomed to connecting to your FreeBSD machine remotely both to use it and to perform your administration duties. However, terminal use is probably the riskiest type of clear-text trafficand it's the easiest to fix. FreeBSD comes with a complete SSH (Secure Shell) package designed to supplant Telnet and rlogin. The SSH package is called OpenSSH, and it was developed originally for OpenBSD. OpenSSH allows users to establish a completely encrypted tunnel to your server, protecting their login passwords and any command-line activity from snooping intruders.

The SSH server, sshd, runs on port 22 as a standalone daemon that, like Apache, spawns off new sshd processes when new connections come in. To enable the SSH server, add the following line to /etc/rc.conf (if it's not already there) and then reboot (or simply type /etc/rc.d/sshd start):

sshd_enable="YES"

The SSH client is a replacement for Telnet. To use it instead of the command-line telnet program, issue the ssh command instead of the telnet command:

# ssh stripes.example.com

Instead of letting the server issue its own Login: and Password: prompts, the SSH client itself prompts for your password, assuming the remote username is the same as the local one. You can specify an alternate username with either of a couple of different methods:

# ssh stripes.example.com -l frank # ssh [e-mail]

The ssh program establishes the encrypted connection and passes the login data to the server in a secure fashion. From that point on, it acts just like a regular Telnet connectionthere's no difference as far as the user is concerned. A user on a FreeBSD, Linux, UNIX, or Mac OS X system can use this process to connect to your machine.

Users on desktop client systems such as Windows or classic Mac OS have a little bit more work to do. These platforms have no command-line SSH client programs, but there are some excellent graphical terminal programs that incorporate both Telnet and SSH functionality: Windows users have the commercial SecureCRT (from Van Dyke, http://www.vandyke.com) or the freeware PuTTY (by Simon Tatham, http://www.putty.nl), and Mac OS 9 users can use NiftyTelnet/SSH or MacSSH.

Your task lies in convincing your users to switch to SSH rather than using Telnet. Let them all know via your published server policy that they are advised to use SSH to protect themselves at their option; however, this doesn't guarantee they will use it, and you as the administrator are still faced with the threat of an attacker who sniffs the connection of someone who has chosen not to use SSH. A more heavy-handed but complete approach is to disable Telnet entirely and require your users to use SSH instead. To disable Telnet, comment out the telnetd line from /etc/inetd.conf:

#telnet  stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd

Then, restart the inetd process:

# /etc/rc.d/inetd restart

Note

SSH has two popular protocol flavors: SSH1 and SSH2. FreeBSD supports both, but SSH1 is less well designed and potentially more likely to exhibit security vulnerabilities than SSH2. You can disable SSH1 by adding the following line to /etc/ssh/ssh_config:

Protocol 2

However, note that not all consumer SSH clients have full support for SSH2. Don't worry about disabling SSH1 unless you have to.

Tip

Even if you disable the Telnet service in inetd, regular users can still launch the telnetd program themselves; because of this, you might want to remove telnetd from the system completely if you have a strict security model.