Tip

Linux sshd customization for the safest remote server access

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

Requires Free Membership to View

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

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.