Secure SSH - How To

English Forums Feedback
1

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.

2

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.

3

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.

4

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.

5

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 :D.

6

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

7

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

8

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.

9

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
10

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.

11

Ha,

Glad I amused you :slight_smile:

If you allow scans of your ports then yes you will be in trouble.

Blocking scans is also easy via a simple snort installation or similar IDS.

In the context of ssh I would still state that moving the port is easy and wise.

12

How do you want to prevent that?

The only thing you can prevent me from scanning you is by disconnecting my machine from the net.

I doubt that snort etc. block regular traffic and scanning a port is regular traffic, if done the correct way, you can not distinguish it from normal requests.

Agreed easy and agreed on wise for some cases (private server perhaps), but it is not a security feature per se, that’s my point.

13

Ok, I can’t stop you scanning, but I can stop you getting useful responses to the scans…

Agreed the use of moving the port number in a security context is mute.

Cheer for the feedback

J

14

Most attacks come from lamer kids using port scanning progs that they download and run.

These progs mostly check all the low (read as default) ports to find something nice like port 22 open, and then launch a password crack attack.

If they don’t find anything in those low ports, they simply move onto the next sucker because it takes far too long to can all 65000 ports.

The logs grow very big very fast, and having 3-4gigs of disk space wasted on logs will choke any system. Even if you have a seperate partition for /var, I wouldn’t expect it to be over 10 gigs!

Changing a port number in a conf file is a cheap, quick, and easy way of avoiding many problems.

I understand that it isn’t a security thing, but is a common sense thing. A bit like NOT wearing a “Gay Rights now” T-Shirt at a skinhead concert!

15

I find ssh-copy-id easier than the scp … incantation

NAME
       ssh-copy-id  -  install  your identity.pub in a remote machine's authorized_keys

SYNOPSIS
       ssh-copy-id -i [identity_file]] [user@]machine

DESCRIPTION
       ssh-copy-id is a script that uses ssh to  log  into  a  remote  machine (presumably  using  a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities)
16

Cool, didn’t know about that. I will check it out.

thanks

17

Another remark, just found something (quite) important missing.

  • The private key will be in ~/.ssh/id_rsa on your box (OK, that was not it).

  • Make sure to restrict access to that key to your user only, so

chmod **600** ~/.ssh/id_rsa

If access is not restricted, you will get this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for '/home/axel/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/axel/.ssh/id_rsa
Permission denied (publickey).
18

On Tue, 2009-11-03 at 22:56 +0000, tuxituk wrote:
> 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.

This does not “secure” it. What it does do is obscures the location
from the “bots” and programs out there that attempt to pound on
ssh using brute force username/password techniques. Your firewall
logs will LOVE you!!
…snip…
> 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…

Sadly, the ssh client historically uses LOWERCASE -p whereas
the scp program uses UPPERCASE -P. Just an fyi…

…snip…
>
> Change the line to:
>
> PermitRootLogin no

Highly recommended. If for whatever reason you have to allow
remote root, specify without-password or (better) if it’s to execute
something specific, use forced-commands-only.

…snip…

The rest about disabling tunneled clear text passwords…
definitely good…

19

On Wed, 2009-11-04 at 07:36 +0000, Akoellh wrote:
> 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.

Hmmm… I’d say reducing your log sizes by literraly GIGABYTES daily
is a good thing… yes??

Don’t feed the bots…

It’s #1 on “best steps” IMHO because, it’s the step that most people
seem to consider “optional”… and it NEEDS to be required for
anything on the Internet.

99% of bot work is done using known info. If you aren’t pingable
and don’t answer to well known ports… they generally move away
and go somewhere else (you look “down” to them). So unless you
like your network interfaces getting pounded on… DON’T FEED THE BOTS!

20

On Thu, 05 Nov 2009 22:05:41 +0000, cjcox wrote:

> Hmmm… I’d say reducing your log sizes by literraly GIGABYTES daily is
> a good thing… yes??

GB? That would seem to indicate a bad logrotate policy to me.

Jim

–
Jim Henderson
openSUSE Forums Moderator