Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

My Favourites

Slackware

Calendar

November 2014
M T W T F S S
« Oct    
 12
3456789
10111213141516
17181920212223
24252627282930

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

Meta

Securing remote root access

If you ever ran a SSH server on the Internet, you will probably have noticed the massive amount of ssh break-in attempts.

There are a few easy ways to get rid of the attacks and at the same time prevent your root account from being compromised.

  1. move the SSH listen port from TCP port 22 to a non-standard port
  2. disallow connections with the older and easily cracked “Protocol 1″
  3. disallow remote root logins

These countermeasures are easily taken by editing the ssh daemon’s configuration file “/etc/ssh/sshd_config“. below, I will show you the lines to lookup and the changed line which needs to take its place:

  • Move the ssh listen port from 22 to 12345. This will get rid of most break-in attempts right away because these only target the well-known port 22:

#Port 22
Port 12345

  • Disallow the use of the old “Protocol 1″

#Protocol 2,1
Protocol 2

  • Disallow the root user to logon directly

#PermitRootLogin yes
PermitRootLogin no

After these changes have been made, you will have to restart the SSH server:

# /etc/rc.d/rc.sshd restart

When you disable root logon through SSH, the only possibility to become root on this computer remotely is to logon as a normal user first, and then use “su” or “sudo” to become root.

This has negative implications if you are used to make remote backups from your server and connect to it as root… because that is the only way to be able to access and read every file in the filesystem.

When you need remote root access but still want to disable password logins for root, there is a further change you have to make to one of the lines I showed you earlier. What I will show you next is how to prevent password logins for root while still allowing entrance using a SSH key. You can protect this SSH key with a passphrase so that it is impossible for someone who steals this key to force his way in as root – he will have the SSH key in his possession, but will not know the passphrase to unlock it!

In order for this to work, the SSH server must allow Public Key Authentication for Protocol2. In Slackware this is the default anyway:

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Now, let’s allow root to use a SSH key for loggin in. Change the following line in “/etc/ssh/sshd_config“:

PermitRootLogin no

to

PermitRootLogin without-password

and then restart the SSH daemon again (see above).

Finally, you will have to generate a SSH key that can be used for remote logins and copy the public keyfile to your SSH server.

ssh-keygen -t rsa

You will have to answer a few questions: under which name should the new keyfile be stored, and what passphrase should be used to protect the keyfile.

Once you have generated this keyfile, copy the public key (which is the keyfile but with the “.pub” extension) to your SSH server and on that server, as user root, append it to root’s “.ssh/authorized_keys” file like this (I am using an example public key filename “your_new_sshkey.pub”):

cat your_new_sshkey.pub >> /root/.ssh/authorized_keys

In case the “authorized_keys” file did not yet exist, you will have to secure other people’s access to the file or else remote logon will still not work:

chmod 600 /root/.ssh/authorized_keys
chmod 700 /root/.ssh

Once this has been done you should now be able to logon to your SSH server as root remotely:

ssh -p 12345 -i ${HOME}/.ssh/your_new_sshkey root@remoteserver

If you want ssh to use this SSH key automatically so that all you need to type is “ssh root@remoteserver“, you should add a few lines to your “~/.ssh/config” file. Perhaps that file does not yet exist in which case you can just create it. Mind the indents, they are required:

Host remoteserver
User root
Port 12345
IdentityFile /home/your_user/.ssh/your_new_sshkey

Good luck with this!

Eric

PS: if you copy your new public key to the server before you have made any of the changes I suggested, then some of the above steps can be combined into one. The following command on your workstation will copy the public key to the SSH server, and add it to root’s “authorized_keys” file, securing that file’s access attributes if needed, all in one go:

ssh-copy-id -i ${HOME}/.ssh/your_new_sshkey root@remoteserver

Comments

Comment from Willy Sudiarto Raharjo
Posted: February 28, 2010 at 18:01

Maybe #MaxAuthTries 6 <– should be uncommented also to prevent brute-forcing

Comment from Cédric
Posted: February 28, 2010 at 19:08

These brute force attacks looks really dumb, I guess the success rate should be really low. By the way, thank you for these hints!

Comment from XGizzmo
Posted: February 28, 2010 at 23:57

Fail2ban is also nice to cut down on the noise and can be configured to help protect other services such as mail, httpd, and dns. Every little bit helps.

Comment from alienbob
Posted: March 1, 2010 at 00:00

Nice security-minded additions, Willy & XGizzmo.

Cheers, Eric

Comment from redtricycle
Posted: March 1, 2010 at 03:29

Great tips! Changing the default port definitely cuts down on a lot of noise from the brute-forcers.

I’ll have to disable Protocol 1 — wasn’t aware it was insecure

Comment from Ellendhel
Posted: March 1, 2010 at 18:05

“copy the public key (…) to your SSH server (…) like this : cat”

It’s seems better to use ‘ssh-copy-id’ : it will copy the file and fix proper permissions on it.

And for stopping brute-force SSH connexions attemps, It’s also possible to use iptables rules with the ‘recent’ module)

Comment from alienbob
Posted: March 1, 2010 at 21:08

Ellendhel:

> It’s seems better to use ’ssh-copy-id’
You apparently did not read all the way down to the bottom.
You can no longer use ssh-copy-id once you have disabled password logon for root. Therefore I noted – if you want to use ssh-copy-id then do so before you start the excercise.

Eric

Comment from escaflown
Posted: March 2, 2010 at 02:12

Thanks for the tips, Eric. Also for those who use Eric’s firewall generator, if you change the ssh listen port in sshd_config, don’t forget to also change the –destination-port for the rule related to ssh in your rc.firewall. I have to admit that I failed in the trap many times :)

Comment from Ellendhel
Posted: March 2, 2010 at 10:10

> You apparently did not read all the way down to the bottom.

Ooops. I apologize!

Comment from eternauta2001
Posted: April 30, 2010 at 23:55

I have a silly question. If I need access from the same machine ssh to multiple servers, can I use the same public key? Or I should generate another pair for each server?

Comment from alienbob
Posted: May 1, 2010 at 12:25

You can use the same public key for as many remote machines as you wish.
The IdentityFile in your “~/.ssh/config” is the private key belonging to that public key, it can be the same for multiple remote hosts.

Eric

Write a comment