Bambooblog404

1. Secure Ssh Server Settings
2. Secure Ssh Client

SSH. We know it. We love it. We must use it.

The SSH protocol uses encryption to secure the connection between a client and a server. All user authentication, commands, output, and file transfers are encrypted to protect against attacks in. SSH Server SSH is a protocol for securely exchanging data between two computers over an untrusted network. SSH protects the privacy and integrity of the transferred identities, data, and files. It runs in most computers and in practically every server.

I'm going to take you through eight steps to better help you secure the SSH service on your network. I think we all appreciate the importance of SSH. It allows us to connect to and from Linux devices, Unix servers, network appliances, and sometimes even Windows boxes. I'm not going to try to sell you on how often SSH is used or how important it is. I'm going to provide a solid checklist you can use to ensure SSH services in your environment are locked down.

More Linux resources

1. Backup the config file

First, back up the configuration file before making major changes. This is a common bit of advice, but it's a real one. It's easy, takes only a moment, and protects you in case of a mistake when editing the file. And who hasn't made a mistake in Vim?

See, that's not so bad.

Challenge - Do you consistently back up configuration files before making major edits?

2. Set a banner message

Admittedly, this is as much about legal requirements as anything else, but again, this setting only takes a moment. You can actually provide some pretty good information in banner messages, too. First, we'll write the banner message in the /etc/issue.net file by using Vim. Then we'll open the sshd_config file and tell it to use the content of issue.net as the banner.

[ You might also like: SSH password automation in Linux with sshpass ]

Obviously, you'll want to come up with something specific to your organization. Remove any information that's already in the issue.net file.

Next, tell SSH to use the banner message. Open the sshd_config file in Vim, and find the line that reads Banner. You do remember that you can use the forward-slash character in Vim's Command mode to keyword-search a file, right? For example, /banner

Find the line that reads # no default banner path, and then uncomment the next line (it says Banner).

Save your changes in Vim with :wq and then restart the SSH service:

Note: I'm not going to remind you to restart SSH from this point forward. Any time you make a change to the configuration file, you must restart the service.

Challenge - Is the banner message consistent across all the SSH devices on your network?

3. Prevent empty passwords

This seems like a no-brainer, but empty passwords are clearly a bad idea. You may have other utilities, such as Pluggable Authentication Modules (PAM), regulating your regular passwords, but it's also a good idea to make sure SSH enforces responsible security settings, too.

Open the /etc/ssh/sshd_config file in Vim, and then find the line that reads PermitEmptyPasswords. Uncomment it, and replace the yes value with no.

That's it.

4. Prevent the root user from crossing the network via SSH

The idea here is pretty straightforward. Send standard user credentials across the network instead of root credentials. Once you've established your SSH connection using a standard user account, use su or sudo to elevate your privileges.

Open the SSH configuration file, and then uncomment the PermitRootLogin line. Edit the setting from yes to no.

Challenge - your organization has embraced sudo, right?

5. Whitelist specific user accounts

If you're already preventing the use of the root user account across SSH, why not go a step further and explicitly state which users can connect to the server? Perhaps you have a regular non-root admin account you use or one that's already configured with sudo privileges.

In the SSH configuration file, add the following line (it's not in there by default):

I'd put it near the PermitRootLogin no setting.

By the way, you can actually filter with all of the following settings: AllowUsers, DenyUsers, AllowGroups, DenyGroups. I wrote them in that order on purpose—that's the order in which they are processed. You can discover more information on the man page for sshd_config.

Challenge - be careful about exactly who is authorized.

Note: You can limit connections via iptables, too.

6. No more port 22

Another common change is to configure SSH to listen on a different port than the standard 22/tcp that we've all memorized. There's already an entry in the sshd_config file.

You can comment out the default port setting and add another line, as I've done below:

I suspect many folks use 2222 as the replacement port number, so you may want to standardize on something a little more unique.

You must remember to append the new non-standard port number to your SSH connection attempts from this point on. For example:

Challenge - do you have the same non-standard port number configured for all your SSH destinations? Consistency will make your life much easier.

7. Time's up!

The next tip deals with timing out connections. The ClientAliveInterval manages idle SSH connections. The server sends a message to the client and expects a response. The ClientAliveInterval is the space of time between the messages. The ClientAliveCountMax defines how many times the server will do this before deciding the client isn't really there anymore. At that point, the connection is dropped.

Here is an example configuration that checks every 60 seconds and will do so three times:

Edit these values to something that makes sense for your environment.

Note: If you're using SSH to tunnel for other connections, you may need to ensure that the interval is long enough to properly support whatever other applications are using it.

There's a ServerAliveInterval value that you can configure on the client-side, too. This allows clients to drop connections to non-responsive SSH servers.

8. Here's the key

One of the most common security settings for SSH these days is key-based authentication. Through the years that I've taught Linux, this authentication method has become more and more common. In fact, I wouldn't attempt a Red Hat admin exam without feeling confident in this process. Fortunately, it's not difficult.

Let's do a quick review. Key-based authentication uses asymmetric cryptography. That means there are two keys, different but mathematically related to each other. One is private and never sent across the network. The other is public and may be transferred across the network. Because the keys are related, they can be used to confirm identities—identities such as SSH authentication attempts.

You'll need to generate the key pair on the local SSH client computer and then transfer the public key across the network to the destination SSH server. In other words, the keys will identify you on your admin workstation. Once this configuration is in place, you are no longer challenged for a password when you establish an SSH connection.

The process only requires a few steps.

First, generate the key pair:

The keys are stored in your home directory in a hidden directory named .ssh, and the default key names are id_rsa (private key) and id_rsa.pub (public key).

Next, send the user1 public key across the network to the destination SSH server located at 10.1.0.42:

Finally, test the connection:

Notice that you are not challenged for a password.

Since you have now embraced key-based authentication, you can edit the sshd_config file to prevent any logins based on passwords. Once you configure this setting, only key-based authentication will be accepted.

Edit these two lines in the file:

[ Want to learn more about security? Check out the IT security and compliance checklist. ]

Wrap up

I have listed several common but effective SSH configurations to help you better secure your environment. Remember, with security, no one setting is likely to protect your devices. The goal is layers of security, the combination of which helps to mitigate security threats. I strongly suggest that you carefully organize your keys if you implement key-based authentication. You might also consider using a centralized /etc/ssh/sshd_config file to maintain consistent security configurations on your SSH servers. Don't forget to restart SSH any time you change the configuration file.

Well we might as well call this month our SSH month since we are full throttle on SSH! Following our “Reverse SSH Port Forwarding” and “How to Configure SSH Tunnel on Putty”, we thought it would be good to look at securing Open SSH, since security is RDM’s number one priority!

When talking about remote access standard, Open SSH has become the norm. It has made other protocols such as Telnet unnecessary since SSH encrypts your connection and passwords are no longer sent in plain text.

Still, using the default installation for SSH can have its own downfalls when it comes to security. When running an SSH server, there are a few easy steps that will considerably increase the installation’s level of security.

Here is our top 10 list for how to secure your Open SSH:

1. Strong Usernames and Passwords

If you have SSH running and exposed to the outside world you will probably notice some log attempts made by hackers that are trying to guess your username and password. A hacker will usually try to scan for port 22 (default port) to discover machines running SSH; they will then try a heavy-handed attack against it. A strong password will help win the fight against an attack! Use RDM Password Generator to generate strong and random passwords and use our list of Forbidden Passwords to prevent anyone from using 123456 or other such nonsense.

2. Configure Idle Timeout Interval

To avoid having an unattended SSH session, you can set an Idle timeout interval. Open your /etc/ssh/sshd_config file and add the following line:

The idle timeout interval you are setting is in seconds (360 secs = 6 minutes). Once the interval has passed, the idle user will be automatically logged out.

3. Disable Empty Passwords

You need to prevent remote logins from accounts with empty passwords for added security. Open your /etc/ssh/sshd_config file and update the following line:

4. Limit Users’ SSH Access

To provide another layer of security, you should limit your SSH logins to only certain users who need remote access. This way, you will minimize the impact of having a user with a weak password.

Open your /etc/ssh/sshd_config file to add an ‘AllowUsers’ line, followed by the list of usernames, and separate them with a space:

Then restart your SSHD service by entering one of the following commands:

5. Disable Root Logins

One of the most dangerous security holes you can have in your system is to allow direct logging in to root through SSH. By doing so, any hackers attempting brute force on your root password could hypothetically access your system; and if you think about it, root can do a lot more damage on a machine than a standard user can do.

To disable your Root Logins, you’ll need to edit the SSHD configuration file. All your SSH server settings are stored in the /etc/ssh/sshd_config file. Open that file while logging on as root and find the section in the file containing #PermitRootLogin in it.

The # symbol (comment) tells the server to ignore anything after it on the same line. Remove the # for the changes to take effect.

Then restart your SSHD service by entering one of the following commands:

You are now safe from brute force root login. If you then need to access root, simply log in as a normal user and use the su command.

6. Only Use SSH Protocol 2

SSH has two protocols that it can use. Protocol 1 is older and is less secure. Protocol 2 is what you should be using to harden your security. If you are looking for your server to become PCI compliant, then you must disable protocol 1.

Open your /etc/ssh/sshd_config file and look for the following line:

Remove the 1, then uncomment it (remove the #). The final line should look like this:

Then restart your SSHD service by entering one of the following commands to apply the changes:

7. Use Another Port

One of the main benefits of changing the port and using a non-standard port is to avoid being seen by casual scans. The vast majority of hackers looking for any open SSH servers will look for port 22, since by default, SSH listens for incoming connections on that port. If it’s harder to scan for your SSH server, then your chances of being attacked are reduced.

You can choose any unused port as long as it’s not used by another service. A lot of people might choose to use 222 or 2222 as their port since it’s pretty easy to remember, but for that very reason, hackers scanning port 22 will likely also be trying ports 222 and 2222. Try and select a port number that is not already used, follow this link for a list of port numbers and their known services.

To change your port, open your /etc/ssh/sshd_config file and add the following lines:

Then restart your SSHD service by entering one of the following commands to apply the changes:

Don’t forget to make the changes to port forwarding in your router and any necessary firewall rules. You will also need to advise your client of any port changes so they know which port to connect to since SSH will no longer be listening for connections on the standard port.

8. Allow Only Specific Clients

If you want your server to be reachable from only a specific IP address on port 22, then you should consider filtering connections at your firewall by adding a firewall rule on your router or update your iptables like this:

With that rule, you are opening the SSH port only to YourIP.

If it is essential for you to open the SSH port globally, then iptables can still help prevent heavy-handed attacks by logging and blocking repeated attempts to login from the same IP address.

The following rule records the IP address of each new attempt to access port 22:

The following rule verifies if that IP address has tried to connect three times or more within the last 90 seconds. If it hasn’t, then the packet is accepted (this rule would need a default policy of DROP on the input chain).

Filtering at the firewall is a tremendously useful method of securing access to your SSH server.

9. Enable Two-Factor Authentication

Your SSH servers should be secured with Two-Factor Authentication configured on it. It is one of the main protections you can add to your SSH servers to protect them from unauthorized access since each user login must tie back to a configured 2FA user. Even if a hacker manages to get a hold of your password or breaks into your SSH server, they will still get blocked by the 2FA. Follow this link to learn more about securing SSH with two factor authentication using Google Authenticator.

10. Use Public/Private Keys for Authentication

Public/Private Keys authentication is certainly more secure and a much better solution than password authentication. Each key is a large number with different mathematical properties. The Private Key is stored on the computer you login from, while the public key is stored on the .ssh/authorized_keys file on each computer you want to login to.

This is particularly important if the computer is visible on the Internet. Using encrypted keys for authentication is useful as you won’t need to enter a password anymore. Once the public/private key-pair authentication has been configured on the server, you can completely disable password authentication; this means that no one without an authorized key will be able to gain access. Even the most inventive hackers won’t be able to interfere or sneak onto a session, and no more cracking password attempts.

Here’s how to create a public/private key pair and install them for use on your SSH server:

Start by generating your key-pair, a public key and a private key. The public key will be placed on the server and you will login with your private key (this needs to be performed on each client machine from which you connect):

This will create two files in your (hidden) ~/.ssh directory called: id_rsa and id_rsa.pub The first: id_rsa is your private key and the other: id_rsa.pub is your public key.

You will then be asked for a passphrase, which is your password to unlock a given public key each time you connect. It is your choice to add a passphrase protective encryption to your key when you create it. If you prefer not to use one, simply press Enter when asked for the passphrase when creating your key pair. Be aware that if you do not passphrase protect your key, anyone gaining access to your local machine will automatically have SSH access to the remote server.

Secure Ssh Server Settings

Copy the public key (id_rsa.pub) to the server (the remoteuser should never be root; select the default non-root user as remoteuser):

Then login with SSH and copy the public key to the right place:

Then delete the public key from the server, otherwise the SSH client won’t allow you to login to the server:

And finally, set file permissions on the server:

If StrictModes is set to yes in your etc/ssh/sshd_config file, then the above permissions are required.

When logging in to the server, you will be prompted for the key passphrase (depending on your configuration).

Once you have verified that you can successfully login using your public/private key, you can then completely disable password authentication. Open your /etc/ssh/sshd_config file and add the following lines:

And there you go! Our top 10 steps to harden your SSH installation! We truly hope this will help you with the sudden rise in SSH brute force attacks. Securing SSH is more important now than ever!

Secure Ssh Client