Linux sshd customization for the safest remote server access

'Secure' is a relative term when talking SSH remote access to servers. Keep your Linux servers under lock and key with these simple sshd tweaks.

Even though it was designed for secure access, SSH has some features that really open the door for intruders. Linux

administrators can make sshd more secure with a few simple changes.

Most Linux servers run a Secure Shell Daemon (sshd) process for remote access via SSH by default. Linux sshd is an easy way to allow remote users and administrators to log in. Remote users open a shell session to your server.

At all times, scripts scan the Internet to determine if servers offer SSH access. In minutes, these scripts can find your server and an intruder can launch a brute force attack against it.

In a brute force attack, an intruder tries to log in as an existing user account on your server. Usually this person doesn't know which user accounts exist. The root user account, however, exists on all Linux servers. If root user access is allowed on your server, the intruder only needs to find its password.

Intruders will also try to guess user accounts -- common names like "jsmith" or departments and functions like "helpdesk" or "finance" are vulnerabilities because they exist at most organizations.

Most automated attacks only check to see if your server offers sshd on default TCP port 22. When your Linux server offers SSH services, it shouldn't listen on port 22 and you should run sshd somewhere else. If you're not offering HTTPS services, port 443 is a good option for sshd.

When sshd runs on port 443, it can be accessed even through many proxy servers. Also, if a port scan program finds that port 443 is open, the intruder will be tempted to launch an HTTPS attack and not an SSH attack. If port 443 is already in use, chose another port.

The second problem with sshd is that root access is allowed by default. To boost security, switch that off: Open the sshd configuration file (typically /etc/ssh/sshd_config) and set the line PermitRootLogin to "no." Even better, include a line "AllowUsers" to select which users can log in via SSH. If a user that needs SSH access to the server has a common name, change it to be harder to guess.

To be really safe, set PasswordAuthentication on the server to "no," so that intruders cannot gain access by guessing at passwords. Valid users will access the server with a public/private key pair. The ssh-keygen command generates a public and a private key. The public key must be copied to the Linux server, usually via ssh-copy-id. Now the user can log in by generating an authentication token that is signed with the private key. If the server verifies the signature with the user's public key, access is granted.

There is a drawback to all this added security. Key pairs for SSH authentication only work for users who have their private key readily available. Think of a user trying to log in from a hotel computer, or if you need to make an administrative change while on vacation. By closing the door on intruders, you could lock yourself and authorized users out as well.

This was first published in May 2014

Dig deeper on Linux servers

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseLinux

SearchServerVirtualization

SearchCloudComputing

Close