Secure SSH - How To

[tuxituk]

Hi,
Some quick points here for how to secure SSH. what do people think ?

thanks.

How To-

Securing SSH

SSH is normally enabled by default on Linux installations, so it goes without saying that a few simple security measures are required to keep the box free from brute force attacks. These measures are part of the SSH configuration and no additional software is required.

If the machine is to be public facing then as a minimum I always follow these steps:

Change the port the daemon is running on
Remove access to root
Enable certificate public/private key authentication

Change the port

The SSH daemon defaults to port 22. Changing the port the daemon runs on is very easy and is one of the best steps to securing the SSH daemon.

Open the /etc/ssh/sshd_config file using your favourite editor.
Find the line:

#Port 22

Change the number to a number higher than 1024. (These are privileged user ports.)

Port 1322

Note the removal of the # to enable the line.

Save and exit the file.
Restart the daemon (rcsshd restart) on SuSE / Redhat

Now connect to the daemon on the new port to check access:

ssh username@ipaddress -P 1322

note the use of the capitalised P for inserting a new port number..

All client tools from the ssh suite will need to be informed of the port number of the remote sshd daemon.

For example:

scp -P 1322 /home/user/file user@ipaddress/home/user/

would copy file to the remote system using port 1322.

Remove access to root

Open the /etc/ssh/sshd_config file using your favourite editor.
Find the line:

#PermitRootLogin yes

Althought this is commented out, root is allowed by default so do not think root is not allowed!

Change the line to:

PermitRootLogin no

Note the removal of the # from the command. This will activate the command.
Save and exit the file.

Restart the ssh daemon (rcsshd restart) SuSE and Redhat

Enable certificate public/private key authentication

Enabling certificate authentication is a great way of securing a system. This works in conjunction with disabling password authentication.

It is easily configured, but steps need to be taken to secure the certificates.

From the remote system (client) that will be accessing the SSH server, issue the following command:
ssh-keygen -t rsa

The following will be displayed:

user@lintangerine:/etc/ssh> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):

Always always use a passphrase, this can contain spaces be as cryptic as you like. Just make it hard to guess.

Once the passphrase has been entered the following will be displayed:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
37:51:f7:a2:6c:44:77:20:99:79:7f:3e:50:5f:7b:19 user@lintangerine
The key's randomart image is:
+--[ RSA 2048]----+
| +++..|
| o++.E.|
| . ..o.B|
| + o +=|
| S o + ..o|
| . o ..|
| .|
| |
| |
+-----------------+

The public key is copied to the .ssh directory of your user

/home/user/.ssh/id_rsa.pub

Change to the .ssh directory, and copy id_rsa.pub to a file called authorized_keys

cp id_rsa.pub authorized_keys

Now copy this file to the ssh server. (If you have changed the port use the new port!) In this example the SSH daemon is running on port 1567

scp -P 1567 /home/user/.ssh/authorized_keys user@sshserver/home/user/.ssh/authorized_keys

The certificate must be copied to the .ssh directory of the designated user on the remote server. If the .ssh directory does not exist for that user then create it. Allow read/write/execute access to that directory for that user only.
Once the file has copied, you can now test ssh access. You should no longer be prompted for a password but for the certificate passphrase.

Once you are happy that the certificates are working as expected you can disable password authentication in the ssh config file.
Be careful not to lock yourself out from the remote server after making this change!! Make sure the certificate access is definitely working!!
Using your favourite editor open up the ssh config file: (For me that is VI)

vi /etc/ssh/sshd_config
Find the following line :
# Change to no to disable s/key passwords
# ChallengeResponseAuthentication yes

Change the ChallengeResponseAuthentication line to read:

ChallengeResponseAuthentication yes
Save and exit the file.
Restart the ssh daemon from the connected session. This will not disconnect your session.
Now open up a new shh connection to the server, keep you existing session alive in case you need to change the ssh settings again.

If you try and access the remote ssh server with an account that has no certificate enabled you will be given no password prompt just the following message:

Permission denied (publickey).

This is because the server is now expecting certificate based access only.

If you access the remote server with a user that has a valid certificate you will be prompted for the passphrase. On entering the passphrase you will be into the ssh session as normal.

Hopefully this will help you secure your ssh server easily and in a straightforward manner.
It is important to note that the use of certificates does mean that your private key is now your access in to the server. Keep this secure in a directory readable only by the person the key is intended for. It is also worth backing the key up in case of data loss. Again the backups must be stored securely.

[Barry_Nichols]

Hi,

looks good, the only other thing I did was installed 'denyhosts'; however that is only because I kept password authentication, to allow me to log on from anywhere.

Definitely remove root login, as most people that try to get access try root as it is one of the only common account names.

Changing the port may reduce the number of 'random' attempts, but it doesn't take a Computer Scientist to find out the port number.

Regards,
Barry.

[mmarif4u]

To add and enhance this a bit more.
Open /etc/ssh/sshd_config file through terminal as discussed in the 1st post.
To add some security measures, add this line at the end of the file.

AllowUsers 1st_username 2nd_username

This way we can prevent direct access by root and assign specific users to access the server.

[Akoellh]

Sorry for having to add one remark of criticism.

Changing the port does _not_ improve security and is certainly _not_ one of the "best steps" but only an additional and optional one.

It only improves "obscurity" and might help keeping the logs clean from automated login attempts which are part of the "background noise" of the Internet today.

Consider also, that changing the port to a non-standard (and if you want to keep the logs "clean"), non "prominent" port (i.e. 8080) might lock you out from connectiing to your SSH server from heavily firewalled places which don't allow connections to such "rare" ports.

In any way, changing the port is worth thinking about, but it is the least important task of the above and not the first one to consider.

[growbag]

I have to disagree slightly there with Alkoehl, changing the port will save you both bandwidth and your hard disk filling up with log files informing you of continuous attack attempts.

I've had a server crash in the past because the disk was full with massive log files. Nobody got in, but by keeping the port # standard, it caused other problems.

And there's nothing more annoying than your internet being slowed down by some a-hole blasting port 22 with continuous login attempts. Plus it will eat into your server's CPU time.

Changing ports is simple, quick, and effective. Just make sure you forward the port you choose in your modem/router and you should be good.

You can go as high as 65534, so there's a massive scope there.

My ssh port is at a very high address and I never see any attempts in my logs, and I have both public key, and password authentication because there's nothing more annoying than being out on the road somewhere (or out of the country) and needing to login to fix something and not having your key on you .

[Akoellh]

Originally Posted by growbag

I've had a server crash in the past because the disk was full with massive log files.

Sorry, but if your HD was filled with log files, then you certainly have another problem than too many login attempts via SSH.

[tuxituk]

Take your point Akoellh, but I have to also disagree....

Imo Leaving any box out in the public domain on a default port is asking for trouble.

Granted finding the new open port is not rocket science and yes if someone wanted to brute force your box they could easily find the new port. However the majority of script attacks will look for port 22, and attack if open. The logs fill up extremely quickly if left with no attention. Moving the port number is a defense against such scripted attacks which will very rarely attempt to find another open port for ssh connections.

Just hang a box out there on port 22 and see how long it takes to get some attention... Based on experience not long.

Hang it out on port xxxx and you will escape for a lot longer. No it is not a substitute for other security measures but then this is an ssh chat.

Many thanks for feedback, much appreciated

Cheers
J

[vodoo]

I do not open port 22 in SuSEfirewall2 for everyone but just for those machines (with fixed IP numbers) I want and need to connect from. Example:

FW_TRUSTED_NETS="nnn.nnn.nnn.nnn,tcp,22 ..."

For all of the bad guys out there the port looks closed.

[Akoellh]

Originally Posted by tuxituk

Imo Leaving any box out in the public domain on a default port is asking for trouble.

Thanks mate, made me laugh very hard indeed.

How many breakins into servers are via SSH compared to breakins via, let's say ..... the web server?

So logically, one should also take the web server off port 80, right?

Standard ports are there for a reason, moving ssh may help you to have smaller logs, which is nice, but anything more -especially mentioned in context with security- is just not true and leads to a false sense of security.

- If your SSH is configured securely, login attempts will fail on any port, large logs are an annoyance, but no security risk.

- If your SSH is configured insecurely, it will be insecure and prone to _successful_ attacks no matter which port it is running on.

Scanning wide ranges of ports on wide ranges of machines is not at all a problem, "professional" attackers use bot nets for that, finding out, that there is an SSH-server running on $PORT is a piece of cake.

 nmap -sV localhost -p 2222

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-04 12:14 CET
Interesting ports on localhost (127.0.0.1):
PORT     STATE SERVICE VERSION
2222/tcp open  ssh     OpenSSH 5.1 (protocol 2.0)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

[Akoellh]

Originally Posted by vodoo

I do not open port 22 in SuSEfirewall2 for everyone but just for those machines (with fixed IP numbers) I want and need to connect from. Example:

FW_TRUSTED_NETS="nnn.nnn.nnn.nnn,tcp,22 ..."

Another possibility would be via "/etc/hosts.allow" (if you can't/don't want to run a packet filter on your server).

If you really want to have "completely clean" logs, you can use port knocking, but as with every other additional software, you are increasing the potential risk of failure (security risk or just "locking out yourself" by coincidence) due to the simple fact, that you increase your code base and the potential of having bugs/security holes in your system.