User Tools

Site Tools



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:

sudo apt-get install ssh openssh-server


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

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

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

sudo sh -c 'echo "This system for use by BOOCHTEK employees ONLY. Unauthorized access prohibited." > /etc/issue'
sudo cp /etc/issue /etc/

Configure the SSH daemon to add the warning message.

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

Disable TCP port forwarding (suggested by

sudo sh -c '/bin/echo -e "\n# Disable TCP port forwarding.\nAllowTcpForwarding no" >> /etc/ssh/sshd_config'

Require SSH keys; don't allow password authentication. NOTE: Be sure you have set up SSH keys for your accounts first!

sudo sed -i -e 's:^#PasswordAuthentication.*$:PasswordAuthentication no:' /etc/ssh/sshd_config

Only allow "real" users to log in via SSH. NOTE: Be sure you've added all your users to one of the specified groups.

sudo sh -c '/bin/echo -e "\n# Allow only users in these groups to log in. (NOTE: Must be space-separated.)\nAllowGroups users" >> /etc/ssh/sshd_config'

Auto-Logout on Idle

Configure the SSH daemon to automatically log users off if they're idle for more than 30 minutes.

sudo sh -c 'echo "ClientAliveInterval 30m" >> /etc/ssh/sshd_config'
sudo sh -c 'echo "ClientAliveCountMax 0" >> /etc/ssh/sshd_config'


Restart to have the settings take effect:

sudo /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:

sudo kill -HUP `cat /var/run/`


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.

Public Keys

The SSH server defaults to allowing logins via public-key encryption, so you don't need to enter a password for every login. To allow this for a given user account, first prepare the SSH authorized_keys file:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Generate a public/private key pair on the client (not the server). Be sure to protect the private key with a passphrase and proper file permissions. Then copy the public key from the client to the server. Assuming the client is UNIX-based, your key is named, and you want to get to the user account on, you would do something like this:

ssh -c 'cat >> ~/.ssh/authorized_keys' <

(Many systems now come with an OpenSSH script named ssh-copy-id that can do this for you.)

If you're coming from Windows, be sure that the authorized_keys file entry is in the correct format. It's a single line containing space-separated fields: options (optional), key type (ssh-rsa or ssh-dss), the base64-encoded key, and an optional comment.

Blocking Attacks

We install Fail2ban to block attempted brute-force SSH attacks. We also considered BFD, BlockHosts, DenyHosts, and SSHguard. Only Fail2ban and DenyHosts are included in Debian (as of Lenny/5.0). We went with Fail2ban, because it integrates with Shorewall, and supports more than just SSH attacks. Of the others we looked at, SSHguard was a close second, having similar support as Fail2ban.

Installation is pretty straightforward:

sudo apt-get install fail2ban whois

Configuration was also pretty simple. We mainly just told it to use Shorewall and added one of our own networks (osRiver) to ignore.

sudo sh -c 'cat > /etc/fail2ban/jail.local <<END
banaction = shorewall
ignoreip = $IGNORE
maxretry = 5
sudo /etc/init.d/fail2ban reload


Fail2ban (on Debian) has regexes in the default /etc/fail2ban/filter.d/sshd.conf for AllowUsers and AllowGroups, but not DenyUsers and DenyGroups. We don't need them, but others might.


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.


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.


  • Installation suggested installing ssh-askpass, rssh, molly-guard. Check into whether those might be of use.
build/ssh.txt · Last modified: 2016/02/26 11:17 by Craig Buchek