OpenSSH (6.0)
Jump to navigation
Jump to search
My first step to setting up most Internet servers is to shut down every listening service except for sshd.
The second step is to lock down sshd.
Preparation
- You will want a public-private keypair. I currently use 4096-bit keys and require them for my users, but may move to 8192-bits. This may seem excessive, but the resources involved are trivial. Regardless, you should have this beforehand. See Generating an RSA Key Pair for instructions.
- Shut every listening service down, save for ssh if you are talking over it.
- Make sure your chosen administrative/wheel user is has your public key in their ~/.ssh/authorized_keys
- Make sure the address you are binding ssh to is bound in /etc/network/interfaces
- If you don't have some sort of remote kvm access to your server, chances are you will want to make a watchdog script relatively soon.
#!/bin/sh
run=`ps x | grep "/usr/sbin/sshd" | grep -v grep | cut -c1-5 | paste -s -`
if [ "$run" ];
then
continue
else
/etc/init.d/ssh start
fi
And add:
2,22,42 * * * * root /root/watchdog.ssh.sh
to a file in /etc/cron.d/ (I use /etc/cron.d/watchdog for my watchdog crons).
If you are one of those people who insists on using ifconfig, and your server has a lot of ips assigned, this step may be mandatory if interfaces take their sweet time getting up.
/etc/ssh/sshd_config
- Choose a non-standard port. I recommend using the same number for all of your servers. This is less for security, per se, but rather to help keep log clutter down as brute force attacks pollute your auth logs. If you use the same number often enough, you will eventually memorize it.
- Listen to only a single IP address. If you have true IPv6 connectivity, consider only talking only through IPv6.
- PermitRootLogin no
- PubkeyAuthentication yes
- PasswordAuthentication no
- Leaving this on until you copy your key over is generally fine. Unless you are horrible at picking passwords.
- X11Forwarding no
- None of my servers run X. If yours does (and you want it to), go ahead.
- UsePAM no
- Just vanilla ssh, please.
- If you are going to have other people signing in, you may want to give them chrooted sftp access only. You can do this by placing blocks at the end of this file, a la
Match User accountname
ChrootDirectory /home/accountname
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
To keep them from snooping, or somehow making a mess.
Testing
After
/etc/init.d/ssh start
if using IPMI, or
/etc/init.d/ssh restart
if not, be sure to try to sign in (again) over ssh and make sure you can successfully connect.
While I have yet to make this mistake personally (and have IPMI to fall back on now), I have seen stories from people who have messed this up.