Account Links: Cart | Your Account | Logout

Skip to content

Red Hat Knowledgebase

Red Hat Knowledgebase Search:

Updated Within the Last:

New Solutions within the last day New Solutions within the last week New Solutions within the last month

Browse by topics:


Click to View a Topic
Red Hat Enterprise Linux > Security > Issue <<  43 of 218 >>

Solution Tools:


Email a Solution Postcard Printer version Submit a comment on this answer Update notifications Request an answer Back

Article Reference

Article ID: 4145
Last update: 09-27-07
Issue:
How can I secure the SSH daemon?
Resolution:

In recent months, system administrators have noticed that attackers have been attempting to login with common usernames and passwords over SSH. In the system logs, similar entries to the following for many common usernames (such as "admin", "guest", "test", and "root") may be seen:

 
Oct 28 11:11:08 hostname sshd[13412]: Illegal user admin from 172.16.59.10
Oct 28 11:11:12 hostname sshd[13412]: Failed password for illegal 
  user admin from 172.16.59.10 port 33762 ssh2
     

Repeated attempts may be indicative of an attacker trying to guess the password to a particular account, especially the root account, by "brute force". A brute force attack is one where the password is repeatedly guessed until the correct one is found.

The most simple way to secure the SSH daemon is to deny access to it completely, via tcpwrappers. This, however, would only be useful if there is no need to remotely log in to the system or one can only log in from a few known hosts.

tcpwrappers are configured through the files /etc/hosts.allow and /etc/hosts.deny. To completely deny access to the SSH daemon, add the following text to /etc/hosts.deny:

 
sshd: ALL
      

This will completely disable access to the SSH daemon. If there are a few hosts that should be allowed to connect, add the following text to /etc/hosts.allow:

 
sshd: 192.168.0.1, trusted.example.com
     

This would allow connections from the IP address 192.168.0.1 and the hostname trusted.example.com, while disallowing any other connections.

There are other steps that can be taken if restricting access is not possible. The most highly recommended action, especially as a defense against brute force attacks, would be to prevent root from logging in directly via SSH. Note that this would not stop any users who logged in with their normal user name and then used the su command to gain root privileges.

To do so, bind SSHD to a specific port other than the default. It is recommended to change it to any random 4 or 5 digit numbers as attackers will assume that port 22 will be used for the ssh protocol.

Find this line in /etc/sshd/sshd_config:

#Port 22

Change it to the following:

Port 1101

Port 1101 is an example. Please use a random port.

Now, edit /etc/sshd/sshd_config and change the line which reads:

 
#PermitRootLogin yes
      

to the following:

 
PermitRootLogin no
     

Further security can be gained by requiring that all logins use public/private key pairs to log in, instead of a password. Note that this requires that every user set up a public/private key pair prior to the changes being made to the configuration file. It will also prevent newly created users from logging in via SSH if a public/private key pair is not created and given to them by the system administrator. In other words, this approach would not scale well beyond a small handful of users.

If it is needed to require public key authentication, edit /etc/ssh/sshd_config and change the line which reads:

 
#PasswordAuthentication yes
     

to the following:

 
PasswordAuthentication no
     

The system will now be more secure against brute force attacks. Additionally, the steps above can be combined for even greater levels of security - for example, only allowing users to login from certain hosts and requiring them to use public/private keypair authentication as well. It is still important, however, to stress to both users (and the system administrator) that strong passwords are extremely important.


How well did this entry answer your question?


good wrong incomplete out of date
Red Hat Enterprise Linux > Security > Issue <<   43  of  218  >>