Secure Shell is a basic and important service which runs on your server. Even if you prefer accessing your server with RDP/Control Panel I still recommend leaving SSH (secured) on the server as backup.

I personally prefer to do everything over SSH, its secured (encrypted connection), low resources consumption and it  has less dependency on other applications on the system.

So after I convinced you to leave the SSH service running, it’s time to get it *truly* secured. Just a reminder, everything you see here was tested on CentOS 5.5, it maybe different if you’re using a different flavor of Linux.

Table of contents:

  1. Accessing your server for the first time.
  2. Creating an account for daily-use.
  3. Limiting ‘su’ to ‘wheel’ group.
  4. *Right* configuration of sshd.
  5. Using private keys.
  6. Firewalling and Port-knocking.

1. Accessing your server for the first time.

Connect to your server,

ssh -2 -l root -p 22 example.server.net

When you first connect to the server, it will display you a warning (for example):

The authenticity of host ‘[example.server.net]:22 ([127.0.0.1]:22)’ can’t be established.

RSA key fingerprint is 6f:83:07:88:46:8a:ec:61:11:63:64:e6:4a:5d:26:ed.

Are you sure you want to continue connecting (yes/no)?

This is the identity of your sshd server, it will help you to authenticate that no one along the way tempered with the data passes between you and the server (MITM Attack). The fingerprint will be stored on your computer for future references.

Now that you have access to the server, it’s time to get it secured. First of all, avoid using root directly, make a new, non-privileged account (in this example I will use my personal name).

2. Creating an account for daily-use.

adduser -c “My daily-use account” -d /home/itzhak -G wheel -m -s /bin/bash itzhak

passwd itzhak

Make sure your new made account is member in the ‘wheel’ group, as we will limit ‘su-ing’ to that group only later on. Even though I recommend accessing the server with private keys only, You still should have a password for your account and not lock it (passwd -l), it may also serve you on other basis, like FTPd (not recommended).

Test the new made account and the ability to ‘su’ to root.

ssh itzhak@example.server.net

su – root

3. Limiting ‘su’ to ‘wheel’ group.

Make sure you’re member in the ‘wheel’ group.

id

uid=500(itzhak) gid=500(itzhak) groups=10(wheel),500(itzhak) context=user_u:system_r:unconfined_t

Edit the file ‘/etc/pam.d/su’ and remove the comment from:

auth           required        pam_wheel.so use_uid

* Not recommended, you can also strict the binary ‘/bin/su’ to the owner “root:wheel”.

chown root:wheel /bin/su

chmod 4750 /bin/su

4. *Right* configuration of sshd.

Binding, Port and Protocol, if you have a server with several IP addresses, ‘sshd’ shouldn’t listen on them all, limit it to one IP addess. Port issue, some people will advise you to change the port ‘sshd’ is listening on, I personally don’t believe in it, do whatever you find right for you. Protocol, allow only protocol version 2, ssh1 is prone to MITM attacks!

ListenAddress 127.0.0.1

Port 22

Protocol 2

Don’t permit ‘root’ to directly access the server (as the user name ‘root’ is being used in brute force attacks). Lower the grace time and the maximum times a user can enter a wrong password before getting disconnected and check the user’s directory permission before login.

PermitRootLogin no

LoginGraceTime 45

MaxAuthTries 1

StrictModes yes

Never allowed empty passwords! And specify the users/group allowed accessing the server from sshd.

PermitEmptyPasswords no

AllowUsers itzhak

AllowGroups wheel

* If using both ‘allowusers’ and ‘allowgroups’ both need to match! meaning, if I have another account, ‘daniel’ which is a member in the ‘wheel’ group, he will still be unable to connect as he isn’t listed in the ‘allowusers’.

* More (useful) options can be found in the manual ‘man sshd_config’.

5. Using private keys.

Create the pair.

ssh-keygen -t rsa -b 4096

When you asked to enter passphrase you can enter an empty one – I wouldn’t recommend on doing so, as it will weaken the strength of your private key (anyone who got access to it would be able to use it).

Now you have a pair of keys (id_rsa is your private key, keep it safe! and id_rsa.pub is your public key which you will put on the server in your home directory.

Copy the public key to your server.

ssh itzhak@example.server.net “mkdir ~/.ssh”

ssh itzhak@example.server.net “chmod 700 ~/.ssh”

scp ~/.ssh/id_rsa.pub itzhak@example.server.net:/home/itzhak/.ssh/authorized_keys

Now, after you stored the public key, it’s time to make sshd recognize it.

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

Test it. If you protected your key with passphrase, it should ask you for it, if not, it will just log you into the server. I recommend disabling password drive authentication (it will protect you from brute-forcing) – remember, if you lose the private key, you won’t be able to access the server!

PasswordAuthentication no

6. Firewalling and Port-knocking.

- TODO -