Contact for queries :


  UpComing Live WebEx Workshop Series

Installing and configuring SSH Service in Linux

You know that at some point or another you will need to be able to administer servers remotely, and you wouldn’t want to do this without some sort of security in place, right? SSH can protect the traffic that passes from your computer to a remote computer, making the tunnel secure for administration.

The tunnel that SSH uses for communication is encrypted, unlike protocols such as Telnet that don’t employ any encryption.

SSH is a fairly easy service to set up and is useful in many different ways. Although it is usually installed by default, you also should verify.

Step 1. Verify that the SSH server package is installed:

# rpm -qa | grep ssh

Step 2. If the SSH server package isn’t installed, do the following:

# yum install -y openssh-server

Step 3. Make sure to verify again:

# rpm -qa | grep ssh

Step 4. Ensure that the service is currently running (or start it if it isn’t):

# service sshd status
sshd (pid 678) is running…

Now that the service is running, you should also make sure that the service is set to start when the system boots.

Step 1. Enable the service Ïduring boot:

# chkconfig sshd on

Step 2. Verify that the service is enabled during boot:

# chkconfig –list sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Now let’s move on to configuring the SSH service for use.

Configuring SSH

After the SSH package is installed, you can start the configuration by looking at the  main config file.

The config file, which is located at /etc/ssh/ssh_config, comes with a set of “safe” default settings. Before making any changes, however, you should make a backup copy of the original file in case something happens that you need to revert to a clean config file later and you want to restore the original.

Make a backup of the main config file:

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

By default, Red Hat has the SSH service installed, running, and a firewall rule allowing incoming connections for the service. Because the config file also has a decent set of default options, you could log in at this point and begin doing work on your server.

Let’s look through the config file at some options:

# cat /etc/ssh/sshd_config

Port 22
Protocol 2
SyslogFacility AUTHPRIV
PermitRootLogin yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Let’s discuss some of the options laid out here:

All these options should be self-explanatory, but there are two options that I recommend changing before you use the SSH service:

PermitRootLogin = No
X11Forwarding = No

Changing these two options provides a little extra security on your system. As you learned in Chapter 7, “User Administration,” you should never use the root account locally, so allowing that account to log in remotely is just not a good idea. After you finish making any changes to the SSH service, you need to restart the service for the  hanges to take effect.

Restart the SSH service:

# service sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]

Firewall and SELinux Configuration

When it comes to remote management in Linux, SSH is the standard. Because SSH is installed by default in Red Hat and there is a firewall rule already in place for you to begin remote management, you do not need to create any additional rules.

As is good practice, though, you should verify that the rule is, in fact, in place. Because SSH uses TCP port 22 for remote access, you should query any rule from the/etc/sysconfig/iptables file:

# cat /etc/sysconfig/iptables | grep 22
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT

With the firewall rule already in place, you also need to look at SELinux restrictions on the SSH service.

Step 1. Query the Boolean values associated with SSH:

# getsebool -a | grep ssh
allow_ssh_keysign –> off
sftpd_write_ssh_home –> off
ssh_sysadm_login –> off

You need to change only one of the options here.

Step 2. Enable the required Boolean value:

# setsebool -P allow_ssh_keysign=1

Step 3. Verify that the value has changed:

# getsebool -a | grep ssh
allow_ssh_keysign –> on
sftpd_write_ssh_home –> off
ssh_sysadm_login –> off

At this point, the firewall and SELinux requirements are taken care of for SSH.

SSH doesn’t require too many changes to work out of the box, but as you work your way through the book, you will encounter services that require multiple changes to firewall rules and SELinux.

SSH Security

SSH has many different options when it comes to security. First, let’s look at some host security. The SSH service can make use of the TCP Wrappers service for additional protection when you are setting it up. Suppose you want to allow connections only from the /24 network to the RHEL01 host.

Step 1. Use TCP Wrappers to limit the hosts that can connect to the server:

# echo “sshd: 172.168.1.” >> /etc/hosts.allow
# echo “ALL: ALL” >> /etc/hosts.deny

This allows all clients within the /24 subnet to connect into the SSH server (provided they have a valid user account), and it disallows any other host outside this subnet.

Although TCP Wrappers is a good starting point for host-based security, you should also change a few of the options in the config file to really improve the security of your SSH server.

You should take into account the default port that the SSH service will use, the IP address that the server listens on, and the protocol  version.

Step 2. Change the options just discussed to improve security:

Protocol 2
Port 2222

When you change these options, the default port isn’t known to everyone, and only the internal network adapter listens for connections. Be careful not to lock yourself out from the external network, though.
Let’s switch focus for a second and look at user-based security. Although this type of security is not in the config file by default, you can also limit the users or groups that you’d like to connect to your SSH server.

The SSH service processes these options in the following order:

DenyUsers  AllowUsers  DenyGroups  AllowGroups

Step 3. Add the following to your config file to allow only specific users to connect:

AllowUsers user01,user02

Now only the two users who have been listed are allowed to connect to the SSH server. Although security for SSH is great, make sure that you have documented your security somewhere because hardened systems tend to lead to connection issues if not planned out properly. You need to be able to review what security mechanisms you have in place when troubleshooting.

Troubleshooting SSH

When it comes to troubleshooting SSH, the service tends to either work or not work. A key part of working with SSH is also being able to troubleshoot it.

The first place to always look with SSH is in the log file located at /var/log/secure. This file should provide you with any information as to why you can’t connect to a remote machine.

If you run into errors about the remote host refusing the connection, the problem is most likely something blocking your connection.

This could be due to the service not running, firewall rules being incorrect, or extra security measures such as TCP Wrappers. Another common error that occurs often when testing is the remote key of the server changing.

If the key changes on the remote host, you get a big warning message:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
If this is the case, you can open the ~/.ssh/known_hosts file to edit or delete the line containing the key that has changed.

Important Note: The known_hosts file contains ONE key PER line!

The reason I’m warning you here is that not all displays are long enough to display the full length of the key, so they wrap it, giving the illusion of a multiline key. It would not be a good thing to try to delete the four- or five-line key from this file in the nano text editor because you would actually just end up erasing everything below it.

Important Questions about SSH Service

1. What is SSH used for?

Ans. SSH is used for secure remote management of Linux systems

2. Should you allow remote root access? Why or why not?

Ans. You should never allow remote root access. Should your root account become compromised and you use the same password, someone could gain access to all your systems. You also don’t want the most powerful user of your system (with no accountability) logging in and making changes.

3. What happens if a host changes its IP address and the keys don’t match?

Ans. A large warning message appears indicating that the key doesn’t match the host you are connecting to. You have to remove the key/host pair from the known_hosts file to proceed.

4. Which version of SSH should you use?

Ans. Version 2 is the latest and most secure version of SSH.

5. SSH can run only on TCP port 22. True or False?

Ans. False. Through its main config file, SSH can be configured to run on any port you’d like (provided that port is available).

6. TCP Wrappers can be used with SSH. True or False?

Ans. True. SSH does support TCP Wrappers.

7. What is the benefit of using public/private key authentication?

Ans. Public/private key authentication provides an additional layer of security because you need the correct key instead of just knowing someone’s password. Passwords combined with public/private keys take the security one additional step.

November 14, 2015

0 responses on "Installing and configuring SSH Service in Linux"

Leave a Message

Your email address will not be published. Required fields are marked *


IGURKUL I.T. Training Hub offering various Career Certification courses in Computer Networking, Unix, Linux, Cloud Computing and DevOps Technologies. With its rich experience in IT training service sector, iGURKUL has been able to set Industry best practices in IT Training for the past five years.

In Past five years, more than 5000 professionals have been trained by iGURKUL for System administration, Cloud Computing and DevOps Skill set through our Online Training portal And , each day , more than 10000 working professionals from all over the globe visiting our knowledge base for the best practices and Knowledge learning.

copyright protected - 2011 © igurkul I.T. solutions. All rights reserved.