SSH is the Secure Shell, a secure replacement for telnet. The OpenSSH client comes in the default Debian install. We've installed the OpenSSH server to provide for remote access to our systems.

Install the package:

apt-get install -y ssh

Fix it so root cannot log in:

sed -i -e 's/^PermitRootLogin .*$/PermitRootLogin forced-commands-only/' /etc/ssh/sshd_config

Edit /etc/issue.net to present a warning message to users connecting via SSH:

echo 'This system for use by SLUUG members ONLY. Unauthorized access prohibited.' > /etc/issue.net

Configure the SSH daemon to add the warning message.

sed -i -e 's:#Banner .*$:Banner /etc/issue.net:' /etc/ssh/sshd_config

Have SSH accept connections on an alternate port for situations where port 22 is blocked at the client's end, or blocked by mistake on the server's end. Edit /etc/ssh/sshd_config to add new statement "Port 443" (without the quotes) after the existing Port statement.

Correct problem with "Request for subsystem 'sftp' failed on channel 0" when using SSH protocol version 2. Edit /etc/ssh/sshd_config to change value on sftp statement from "/usr/libexec/openssh/sftp-server" (which doesn't exist) to "/usr/lib/sftp-server". Also tell sshd to reread configuration using the kill command documented below. This was probably due to the upgrade to ssh a month or two ago on budlight and might not be needed on future uprades or installations. If "sftp -2" to the system works, then it is probably ok.

Restart to have the settings take effect:

/etc/init.d/ssh restart

Or just send the daemon a HUP signal to have it reread the configuration file and activate the changes.

kill -HUP `cat /var/run/sshd.pid`

Log into the system as a user via SSH.

Try logging in as root via SSH. Make sure the access is denied, and that the attempt is logged.

SSH access to the system is logged in /var/log/auth.log.

We've disabled direct root login via SSH. The OpenSSH server and client come built with just about every feature possible to help ensure as secure a connection as possible.

After installation, and any time the SSH server keys change, update http://www.sluug.org/members/accounts/ssh_keys.shtml with the new public key fingerprints. The fingerprints can be listed with:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub

While SSH replaces Telnet, we've kept the telnet client installed, because it's very helpful in troubleshooting network services by telnetting directly to the port the service runs on. The telnet client should never be used to log into a shell account. The telnet server should never be installed, except perhaps for non-critical non-shell restricted access.

Publish the host public keys.

Enable/disable some more features to provide better security.

Determine when it is appropriate to use key-based authentication instead of password authentication, and configure for such. Use ssh-agent and ssh-add as appropriate. (Note that users can use those already.)

Installation suggested installing ssh-askpass, rssh, molly-guard. Check into whether those might be of use.