Linux ssh command (secure shell) [Basic Guide]

The OpenSSH package offers a secure remote access service to Linux computers with an encrypted end-to-end connection using the ssh command on Linux.

It uses the SSH (secure shell) protocol to allow file transfer and secure shell.

It was created to replace connection servers that traffic data without encryption, such as telnet, rsh, and rlogin. The free open source version can be obtained at http://www.openssh.org or installed directly as a package in most distributions.

OpenSSH is portable to several systems such as Linux, Solaris, FreeBSD, NetBSD, AIX, IRIX, HP-UX and OpenBSD.

The installation of OpenSSH is simple and can be done through packages such as apt-get on Debian or yum on Redhat.

OpenSSH encryption uses the concept of a pair of public and private keys.

Cryptography Algorithms

OpenSSH supports several signing algorithms for authentication keys that can be divided into two groups depending on the mathematical properties they explore:

• DSA and RSA, which depend on the practical difficulty of factoring the product of two large prime numbers;
• ECDSA and Ed25519, which depend on the discrete logarithm problem of the elliptic curve.

Elliptic Curve Cryptography (ECC) algorithms are a more recent addition to public key cryptography systems. One of its main advantages is the ability to provide the same level of security with smaller keys, which makes operations less computationally intensive (i.e., faster key creation, encryption and decryption as well).

OpenSSH 2 client configuration

For each user, ssh also creates its own key pairs, which reside in the “.ssh” subdirectory of the user’s HOME directory. At any time, the user can create their key pairs with the ssh-keygen command:

$ ssh-keygen 
Generating public/private rsa key pair. 
Enter file in which to save the key (/home/uiraribeiro/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Your identification has been saved in /home/uiraribeiro/.ssh/id_rsa. 
Your public key has been saved in /home/uiraribeiro/.ssh/id_rsa.pub. 
The key fingerprint is: 
SHA 256:7 p177xnruy0hdcrdubdcqg uiraribeiro @Notebook -Do-Uira 
The key's randomart image is: 
+--- [RSA 2048] ----+ 
| E==O=+=O.. |

| =+ =o.=.oo|
| = +o oo |
+—- [SHA256] —–+

The ssh-keygen can create the following key pairs with different encryption algorithms:

• DSA private key: ~/.ssh/id_dda (DSA); DSA public key: ~/.ssh/id_dsa.pub (DSA);
• ECDSA private key: ~/.ssh/id_ecdda (ECDSA);
• ECDSA public key: ~/.ssh/id_ecdsa.pub (ECDSA); Private Key Ed25519: ~/.ssh/id_ecdsa.pub (ECDSA);
• Private Key Ed25519: ~/.ssh/id_ecdsa.pub (ECDSA);
• Private Key Ed25519: ~/.ssh/id_ecdsa.pub (ECDSA); Private Key Ed25519: ~/.ssh/id_ecdsa.pub (ECDSA) ed25519 (Ed25519);
• Ed25519 public key: ~/.ssh/id_ed 25519.pub (Ed25519);
• RSA private key: ~/.ssh/id_rsa (RSA);
• RSA public key: ~/.ssh/id_rsa.pub (RSA)

Passwordless authentication

The user may wish to copy their public key to the HOME directory of the user they use to connect to the remote machine in the file ~/.ssh/authorized_keys. Thus, it will no longer need to provide the password for a remote connection with that particular host and user.

/etc/ssh_config file

The ssh client maintains a /etc/ssh/ssh_config file for the SSH client settings. Among them, the following stand out:

Protocol 2 # allows only SSH2 to be used 
Port 22 # changes the port SSH standard of 22 for another

ForwardX11Trusted in # does not allow remote login via X11

Remote connection using SSH

When a connection to an SSH server is made, there is an exchange of public keys between the ssh client and the sshd server.

So when the server wants to send something to the client, it uses the client’s public key to encrypt the data for the client. Only the customer’s private key is able to decrypt what was encrypted with their public key.

The same happens when the client wants to send something to the server. It uses the server’s public key to encrypt something for it. In this way, only the server’s private key is able to read its content.

To connect to a host using ssh, the command follows the pattern:

$ ssh username @enderecodohost

And to connect to the X11 protocol, the “-X” or “-Y” option is used:

$ ssh -X [email protected]

SSH automatically exchanges the local user’s public keys with the remote user’s keys, transparently.

It is also possible to remotely execute a command on the destination host using ssh:

$ ssh [email protected] svn /var/www/html

In this example, ssh will authenticate, and execute the command “svn /var/www/html” on the remote server.

SSH allows you to specify a connection port when port 22 is not the remote server’s default port:

$ ssh -p 2222 [email protected]

The “-p” option allows you to specify the port.

ssh_know_hosts

The /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts file is consulted when the access method used is based on RSA authentication. This file contains a machine’s public keys for the connection to be successful.

Once a connection is established for the first time, ssh writes a server hash to the file ~/.ssh/know_hosts. In the next connections, this hash is compared with that received by the server and from the know_hosts file.

If for any reason the server is changed, the comparison will fail, the SSH will not connect and will issue an alert, stating that the server is possibly another machine and not the known one.

When the server needs to be changed, the ssh client must remove the line corresponding to the server in the ~/.ssh/know_hosts file.

OpenSSH Server

The service that provides remote connection using SSH from the OpenSSH package is sshd. This service is generally run through the Systemd service manager.

At the time of installing the OpenSSH Server, a public key and a private key will be created for your host. In version 2 of SSH, the following files are created:

/etc/ssh/ssh_host_rsa_key (RSA private key) /etc/ssh/ssh_host_rsa_key.pub (RSA public key)
/etc/ssh/ssh_host_dsa_key (DSA
private key) /etc/ssh/ssh_host_dsa_key.pub (DSA public key) /etc/ssh/ssh_host_dsa_key.pub (DSA public key)
/etc/ssh/ssh_host_dsa_key.pub (DSA public key) /etc/ssh/ssh_host_dsa_key.pub (DSA public key)
/etc/ssh/ssh_host_dsa_key.pub (DSA public key)
/etc/ssh/ssh_host_host_ecdsa_key (ECDSA private key) /etc/ssh/ssh_host_ecdsa_ key.pub (ECDSA public key)

/etc/ssh/ssh_host_ed25519_key (Ed25519 private key)
/etc/ssh/ssh_host_ed25519_key.pub (Ed25519 public key)

These keys should not be changed, as they are your host’s encryption keys. If any of these keys are changed, the machines you connected will no longer accept a connection from you, as they will understand that someone is impersonating you.

sshd_config

The main configuration file for sshd is /etc/ssh/sshd_config. It is important that this file is allowed to be read and written only for the super user, as it contains sensitive information, such as allowing root access or just a list of users.

The sshd_config file is very rich in configuration possibilities.

The following information is relevant when configuring sshd:

Protocol 2 # allows only SSH2 to be used 
Port 4999 & nbsp; # changes the default SSH port from 22 to another 
ForwardX11 in # does not 
allow remote login via X11 PermitRootLogin in # does not allow root to enter remotely

MaxAuthtries 2 # defines the maximum number of error attempts
AllowUsers tom Jerry # defines which logins are allowed via ssh

Generally, for security reasons, it is not common to allow root to access SSH directly, so the administrator must log in with another account with normal privileges and the commands that require the superuser to use Sudo.

Enable sshd

To start the SSH server service:

$ systemctl start sshd

To enable the service on the operating system load:

$ systemctl enable sshd

ssh-agent and ssh-add

The ssh-agent and ssh-add applications can be used to control the ssh connection, so that the user does not have to enter their authentication password on the destination machine at each connection.

The target machine must have a copy of the user’s public key in the target user’s home/.ssh folder on the destination machine:

# scp /root/.ssh2/hostkeys/key.pub root @server: /root/.ssh

The “scp” command makes a secure copy of the public key created with the ssh-keygen to the “/root/.ssh” directory of the target machine.

Once this is done, the “ssh-agent” command shows which environmental variables need to be created and what is the PID of the SSH agent process that will control the connection:

# ssh-agent SSH_AUTH_SOCK = /tmp/SSH-LQMURR398/agent.398; export SSH_AUTH_SOCK; SSH_AGENT_PID=399; export SSH_AGENT_PID;

Copy and paste the text that the ssh-agent showed into the shell:

# SSH_AUTH_SOCK = /TMP/SSH-LQMURR398/Agent.398; export SSH_AUTH_SOCK; # SSH_AGENT_PID=399; export SSH_AGENT_PID;

After that, it is necessary to run “ssh-add” and enter the “passphrase” that was entered when creating the keys:

# ssh-add Enter passphrase:

This way, when you are going to make a secure connection with the “machinadestino”, ssh will not ask for your password.

# ssh root @maquinadestino

Another way to do this is to copy the content of the client machine’s public key id_rsa.pub to the server machine’s ~/.ssh/authorized_keys file. Thus, when the client needs to log in to the server machine, a password will not be required.

ssh-copy-id

The ssh-copy-id program can be used to copy the public key to the remote machine securely and quickly. It copies the user’s public key to the remote server at ~/.ssh.authorized_keys.

$ ssh-copy-id uiraribeiro @10 .211.55.73 
/usr/bin/ssh-copy-id: INFO: Source of key (s) to be installed:
/home/uiraribeiro/.ssh/id_rsa.pub 
uiraribeiro @10 .211.55.73's password: 
Number of key (s) added: 1 
Now try logging into the machine, with: “ssh 'uiraribeiro @10 .211.55.73'” 
and check to make sure that only the key (s) you were wanted added. 

Personally, I don’t like to use this login method without asking for a password. Once your machine is vulnerable, all machines where you regularly use ssh access via keys will also be compromised.

Making SSHD Safer

Change the SSH port

One of the tricks to make SSH more secure is to change the default connection port of the ssh service.

This can be done by changing the /etc/ssh/sshd_config file, changing the “Port” directive. Generally this line will be commented with “#”. It is necessary to uncomment and change port 22 to another port above 1024:

Port 2323

Don’t allow login with Root

It is also interesting to disable root superuser access to SSH, thus allowing only ordinary users to log in remotely.

This can be done by changing the /etc/ssh/sshd_config file in the “PermitRootLogin” directive, which should be uncommented and with a value equal to “no”:

PermitRootLogin no

After any change in the sshd_config file, it is necessary to restart the ssh service:

# systemctl restart sshd

Using Tcpwrapper

An old technique in Linux to limit access to a particular service is the use of tcpwrapper.

The tcpwrapper works like a gatekeeper that intercepts a connection and verifies that a particular service can be accessed by a client. In this way, it is possible to limit the IP addresses of customers that could access a particular service.

Linux programs that make use of tcpwrapper use the libwrap.so library.

To determine if a program makes use of tcpwrapper, you can consult which libraries it uses with the ldd program:

$ ldd /usr/sbin/sshd | grep wrap libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0

In this case, it can be seen that the sshd program uses the libwrap library and is therefore able to limit which hosts can access the secure shell.

To limit which client hosts can access which service, tcpwrapper consults the /etc/hosts.allow and /etc/hosts.deny files to find out which IP addresses can access which service.

hosts.allow and hosts.deny

The /etc/hosts.allow and /etc/hosts.deny files are used to define access rules for the services offered by the computer.

The contents of the hosts.allow and hosts.deny files follow the following format:

service_name: ip_address

There is logic and an established order:

When a connection is established, tcpwrapper first reads the contents of the /etc/hosts.allow file. If there is a rule for this connection, it doesn’t check the hosts.deny file.

$ cat /etc/hosts.allow sshd: 10.10.100.1

If no rule is found on hosts.allow, it reads /etc/hosts.deny for a rule. If anything matching is found on hosts.deny, it terminates the connection. If nothing matching is found, it releases access.

If you want only connections explicitly released in the hosts.allow file to be allowed, denying any other undeclared client, the “ALL:ALL” rule can be placed in the /etc/hosts.deny file so that only connections explicitly defined by rules in hosts.allow are accepted.

Another possible combination in hosts.deny is to deny everything per service with the “sshth:all” rule. Some distributions replace the word “all” with “paranoid”.

The IP addresses declared in the hosts.allow and hosts.deny files can be in both the IPv4 and IPv6 versions. More than one address must be separated by commas:

sshd: 192.168.0.10, 192.168.0.15

You can also declare a machine address:

sshd: uira.certificacaolinux.com.br

It is also possible to release via subnet:

sshd: 192.168.0.0/255.255.255.0

The tcpwrapper also accepts a partial combination if the line ends with a “.”

:

sshd: 192.168.0. 

In this case, all addresses starting with “192.168.0″ will be included.

Restricting which clients can connect to a particular service is a task today delegated to the use of a good Firewall. However, tcpwrappers offers an additional layer of security, since if the firewall fails, there is also the tcpwrapper to guarantee some extra protection.

Learn much more about Linux in our online course. You can register here. If you already have an account, or want to create one, just log in or create your user here.

Did you like it?

Share

Uirá Endy Ribeiro

Uirá Endy Ribeiro is a Software Developer and Cloud Computing Architect with a 23-year career. He has master's degrees in computer science and fifteen IT certifications and is the author of 11 books recognized in the IT world market. He is also Director at Universidade Salgado de Oliveira and Director of the Linux Professional Institute - LPI Director's Board.