3.2.2. Secure Shell

download PDF
Secure Shell (SSH) is a powerful network protocol used to communicate with another system over a secure channel. The transmissions over SSH are encrypted and protected from interception. Cryptographic login can also be utilized to provide a better authentication method over traditional user names and passwords. See Section, “Cryptographic Login”.
SSH is very easy to activate. By starting the sshd daemon, the system begins to accept connections and will allow access to the system when a correct user name and password is provided during the connection process. The standard TCP port for the SSH service is 22. However, this can be changed by modifying the /etc/ssh/sshd_config configuration file and restarting the service. This file also contains other configuration options for SSH.
By default, the sshd service starts automatically at boot time. Run the following command as root to query the status of the daemon:
~]# service sshd status
If you need to restart the sshd service, issue the following command as root:
~]# service sshd restart
Refer to the Services and Daemons chapter of the Red Hat Enterprise Linux 6 Deployment Guide for more information regarding the management of system services.
Secure Shell (SSH) also provides encrypted tunnels between computers but only using a single port. Port forwarding can be done over an SSH tunnel and traffic will be encrypted as it passes through that tunnel, but using port forwarding is not as fluid as a VPN (Section 3.2.1, “Virtual Private Networks”). Cryptographic Login

SSH supports the use of cryptographic keys for logging in to computers. This is much more secure than using only a password. If you combine this method with other authentication methods, it can be considered a multi-factor authentication. See Section, “Multiple Authentication Methods” for more information about using multiple authentication methods.
In order to enable the use of cryptographic keys for authentication, the PubkeyAuthentication configuration directive in the /etc/ssh/sshd_config file needs to be set to yes. Note that this is the default setting. Set the PasswordAuthentication directive to no to disable the possibility of using passwords for logging in.
SSH keys can be generated using the ssh-keygen command. If invoked without additional arguments, it creates a 2048-bit RSA key set. The keys are stored, by default, in the ~/.ssh directory. You can utilize the -b switch to modify the bit-strength of the key. Using 2048-bit keys is normally sufficient. See the Generating Key Pairs chapter of the Red Hat Enterprise Linux 6 Deployment Guide for more detailed information about generating SSH keys.
You should see the two keys in your ~/.ssh directory. If you accepted the defaults when running the ssh-keygen command, then the generated files are named id_rsa and and contain the private and public key respectively. You should always protect the private key from exposure by making it unreadable by anyone else but the file's owner. The public key, however, needs to be transferred to the system you are going to log in to. You can use the ssh-copy-id command to transfer the key to the server:
~]$ ssh-copy-id -i [user@]server
This command will also automatically append the public key to the ~/.ssh/authorized_key file on the server. The sshd daemon will check this file when you attempt to log in to the server.
Similarly to passwords and any other authentication mechanism, you should change your SSH keys regularly. When you do, make sure you remove any unused keys from the authorized_key file.
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.