Installing and Configuring the Secure Shell Server

Document Sample
Installing and Configuring the Secure Shell Server Powered By Docstoc
					?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.

				
DOCUMENT INFO