?The Secure Shell (SSH) Server is a secure replacement for telnet and rlogin, etc. SSH uses encryption from the point the client connects to a server, to the time the connection is terminated. SSH uses encryption to hide passwords, usernames, and other sensitive information that is normally sent "in the clear" in servers such as telnet and rlogin. SSH as of this writing supports the following encryption algorithms: 3DES, Twofish, Blowfish, Arcfour, CAST128, AES (Rijndael), and DES. SSH now comes with a variety of distributions, so downloading the server and the client should be a pinch. If, however, your distribution lacks a SSH server package, you may download it from the SSH website at /pagead/show_ads.js"> Once installed, SSH should work properly. To test it, you may login to your server by issuing the following command: ssh -l username 127.0.0.1 Replace "username" with your desired user name. If all is working correctly, you will be prompted for a password, and then connected. If this does not work, if you installed SSH from source, and don't have an /etc/init.d or /etc/rc.d file for the SSH daemon, you can build one from scratch following the guidelines for Pro-FTPD. The SSH config file (normally located in /etc/ssh or /etc/ssh2) is sshd_config or sshd2_config. An example configuration file looks like the following: # sshd2_config # SSH 2.0 Server Configuration File *: Port 22 ListenAddress 0.0.0.0 Ciphers AnyStd # Ciphers AnyCipher # Ciphers AnyStdCipher # Ciphers 3des IdentityFile identification AuthorizationFile authorization HostKeyFile hostkey PublicHostKeyFile hostkey.pub RandomSeedFile random_seed ForwardAgent yes ForwardX11 yes PasswordGuesses 1 MaxConnections 50 PermitRootLogin no # AllowedAuthentications publickey,password,hostbased AllowedAuthentications publickey,password # RequiredAuthentications publickey,password ForcePTTYAllocation no VerboseMode no PrintMotd yes CheckMail yes UserConfigDirectory "%D/.ssh2" SyslogFacility AUTH # SyslogFacility LOCAL7 Ssh1Compatibility yes Sshd1Path /usr/sbin/sshd1 # AllowHosts localhost, foobar.com, friendly.org # DenyHosts evil.org, aol.com # AllowSHosts trusted.host.org # DenySHosts not.quite.trusted.org # NoDelay yes KeepAlive yes RequireReverseMapping yes / UserKnownHosts yes # subsystem definitions subsystem-sftp sftp-server Most of these settings you shouldn't have to change from the default. One notable exception is the port that SSH will use. You can change this to any port within the 65535 limit. Also, you might want to change PasswordGuesses from its default (3) to 1. The reason for this is that it deters cracking attempts (the cracker has to make a new connection for each failed password). MaxConnections is a very important setting if this server is going to have any other services on it. MaxConnections helps keep your connections down, so that SSH requests and processes don't take up 90% of the server's resources. However, there is a downside to it- someone can login to your server the amount of times allowed in MaxConnections, then just leave the sessions logged in, which will prevent other users from logging in. PermitRootLogin is also an important setting, *ALWAYS* set this to no (the default is yes). If you need to login as root, simply create a user with a GID of 0 and UID of 0. This is known as a suid root account. Leaving root with the ability to login leaves a small chance that someone may crack root. SSH1 compatibility is crucial, many people have not yet upgraded (or are aware of the upgrade) to SSH2. AllowHosts and DenyHosts really shouldn't be used as a security measure in my opinion. Instead, ipchains or a similar kernel-level firewall should be used instead. However, you may elect to use them, but be warned that when using a application level security measure, exploits in the application can allow denied (or blocked) hosts from connecting anyways. One great thing about SSH is that it comes with the sftp server, which allows encrypting of FTP sessions. Also, no FTP daemons are needed on the server, just the SSH daemon. However, the client must have a SSH package, in order to take advantage of the sftp server. SSH is an extremely valuable service. It allows encryption of what were traditionally non-traditional services (such as telnet and FTP). This section has only briefly touched on the subject of the SSH server. For more information, read the FAQs and HOW-TOs available at ssh.org, or feel free to visit my website below. Christopher J. Pace is a freelance Linux consultant who has worked with Linux since 2001. He provides remote Linux consulting services for Linux servers.