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 SSH client and server packages:

apt-get install ssh openssh-server

Fix it so root cannot log in, but allow selected commands, which will be authenticated by authprogs:

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
cat /etc/issue.net > /etc/issue

NOTE: On Bud, change the word members to administrators.

Configure the SSH daemon to add the warning message.

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

Add alternate port: Have SSH on BudLight 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.

This step seems obsolete and no longer needed since the reload of the systems. 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

NOTE: You can probably run /etc/init.d/ssh reload instead of /etc/init.d/ssh restart if you like.

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.

Log into the system as a user via sftp and try to transfer any file.

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.

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.