In this article, we'll talk about useful tricks and commands when working with SSH. Namely:
- How to use two-factor authentication for SSH connections.
- Safe use of "agent forwarding".
- Ending a hung session.
- We leave the terminal open when exiting or disconnecting.
- ( Zoom!).
There are five ways to activate it.
1. We update OpenSSH and use hardware tokens. In February of this year, support for FIDO U2F (Universal Second Factor) tokens was added to OpenSSH. What can I say - that's great, but there is one caveat.
The point is that the update adds new key types to support tokens. However, this feature can only be used when updating the client and server to version 8.2 or later. You can check the current version of the client by using the ssh -V command. As far as the remote server is concerned, it is worth using nc [servername] 22.
In addition, two new key types have been added - ecdsa-sk and ed25519-sk. There are also certificates for them. In order to create key files, you need to insert a token and execute the command
$ ssh-keygen -t ecdsa-sk -f ~ / .ssh / id_ecdsa_sk.
What she does? Creates public and private keys that are bound to the U2F token. The private key on the token is used to decrypt the private key that is stored on disk.
Another possibility is to set a password for key files as a second factor. The fact is that OpenSSH works with another generation option - sk. Thus, key files are stored on a hardware token and are always with you. In order to create a resident key, you need to use the command:
$ ssh-keygen -t ecdsa-sk -O resident -f ~/.ssh/id_ecdsa_sk.Well, in order to transfer the key file to a new machine, you need to insert the media and run the command $ ssh-add -K. Remember - the token must be activated upon connection.
2. We use PIV + PKCS11 and Yubikey. In the event that you need to connect to machines where earlier versions of the SSH server are installed, there is another option. Here is a detailed instruction for U2F + SSH with PIV / PKCS11 . A bit tricky but worth it.
3. The third way is using the yubikey-agent. Here is the SSH agent for the Yubikeys itself , created by Filipo Valsorda.
4. Touch ID and sekey. Another way is to use Sekey- an open source agent. It stores private keys in the secure enclave system for MacOS and allows you to trigger the Touch ID signing feature.
5. Finally, using Single Sign On SSH. Here is the setup instructions . The advantage of Single Sign On SSH is that the user is able to use the security policy of the account provider, including support for multi-factor authentication.
Safe key forwarding (agent forwarding)
What is key forwarding used for? For remote host access to local SSH user agent. The fact is that when the SSH client uses key forwarding (ssh -A is most often activated), then during the connection there are 2 channels. The first is an interactive user session, the second is a key forwarding channel.
The local SSH agent creates an IPC socket that connects through this channel to the remote host. This is quite dangerous, since the root user on the remote host has access to the local SSH agent of the connecting user. Thus, it can be used to access network resources on behalf of this user. And if you work with a standard SSH agent, you won't find out about the problem. But with a U2F key or Sekey, this problem can be removed.
In general, you can forward the key, but it is advisable not to use this method often and for all your connections. It is advisable to use it only when the user is confident in the situation.
Logging out of a hung SSH session
SSH sessions often freeze due to network problems, loss of control of a program being executed, or one of the terminal's escape sequences blocking keyboard input. There are several ways to exit a hung session:
1. Automatically when the network is disconnected. To do this, add to the SSH configuration file, .ssh / config:
ServerAliveInterval 5
ServerAliveCountMax 1
In this case, ssh will check the connection by sending echo requests to the remote host at regular intervals. They are set by the ServerAliveInterval parameter. If there are more unanswered requests than ServerAliveCountMax, SSH closes the connection.
2. Breaking up the session. ssh uses the ~ character as the default escape sequence. The ~ command closes the current connection and returns to the terminal.
Also, the ~? Displays the entire list of commands that can be used in the current session. If you have multiple layouts installed, you will have to press the ~ button twice to send a character.
Leaving the terminal on the remote host open
There are two options for saving the session while switching between networks.
1. Using Mosh or Eternal Terminal
If you need a reliable and non-closing connection, even when switching between networks, then there is a way out - you need to use the Mosh - mobile shell. Mosh refers to a secure shell that uses SSH to initialize a session (handshake). After that, she switches to her own encrypted channel, which is very stable. For example, it can handle various situations, including disconnections, changes in the device's IP address, large lags in data transfer, and so on. This is all thanks to UDP and the sync protocol that Mosh uses.
To work with it, first of all, you need to install it on both the server and the client, opening ports 60000 to 61000 for incoming UDP traffic on your remote host. After that, you just need to type mosh user @ server to connect.
Mosh works at the level of terminal screens and keystrokes, which gives it a lot of advantages over SSH, which transfers a binary data stream from normal I / O between clients and the server. If you need to synchronize only the terminal screen and keystrokes, then the interrupted connection is restored much faster. The same SSH needs to be stored in a buffer and sent everything, but Mosh only needs to save keystrokes, synchronizing the last state of the terminal window with the client.
2. Using tmux. In order to connect and disconnect as needed, while maintaining the same session on the remote host, it is worth using a terminal multiplexer called tmux . In the event that the SSH connection falls off, you need to reconnect and type tmux attach. The user is then returned to the tmux session.
It also offers several additional features, including tabs, panels, the same as in the macOS terminal, plus the ability to work with the terminal with another user. You can get even more with Byobu, a package that adds many convenient functions and keyboard shortcuts. It ships with Ubuntu and can be run on macOS using Homebrew.
Sharing a remote terminal
There are situations when you need to share an SSH session - for example, while solving complex problems with servers. The best way to do this is with tmux. To solve the problem, you need to do the following:
- Make sure tmux is installed on the server in the DMZ (or the location to which you want to connect).
- Both users need to connect to the server via SSH with the same account.
- One of the users must run tmux to create a tmux session.
- The second user runs the tmux attach command.
- Everything is ready!
If you need to fine-tune multi-user sessions, you should use tmate . This is an improved fork of tmux.
Expert advice
We decided to supplement the translation with our own tips - we hope that they will be useful too. Maxim Klochkov , Senior Consultant at the Network Solutions Center of Jet Infosystems and a teacher of the Cybersecurity Profession course at Skillbox, shared his useful experience .
TCP port forwarding
Ssh has two useful options: -L and -R.
The -L parameter organizes an open TCP port on our local computer, when we try to establish a TCP connection to which this connection is transparently forwarded to the ssh tunnel, and then a connection is established from a remote computer.
The -L parameter is followed by an argument in the following form:
ssh -L XXX:server1:YYY login@server2Here server2 is the remote server that we access via ssh, login is the username under which we log into the remote server, XXX is the port number that needs to be organized on the local computer, server1 is the host to which we need to forward the connection from this port , and finally YYY is the port to which this connection should be forwarded.
Let's look at two examples.
Example 1.
- We are on the spb.company1.ru server, and we want to test a web application that accesses the database at central-db.company1.ru
- This database is available only from the moscow.company1.ru server, on port 9999
- We will organize the forwarding of the local port 55555 to the database via an ssh tunnel as follows: ssh -L 55555: central-db.company1.ru: 9999 login@moscow.company1.ru
- After that, we deploy a web application on our local server, and we specify not central-db.company1.ru:9999 as the base, but localhost: 55555 - this connection will be forwarded to the moscow.company1.ru server, and this server will make the connection with a database on the host central-db.company1.ru, port 9999
Example 2.
- We are on the spb.company1.ru server, and we want to show the customer a test website at moscow.company1.ru, port 5000.
- There is no access to this site from the Internet, there is only internal access from the same host where it is deployed, i.e. from moscow.company1.ru
- We organize the forwarding of local port 80 through an ssh tunnel as follows ssh -L 80: localhost: 5000 login@moscow.company1.ru
- If the user now enters the browser using the link spb.company1.ru , then the connection will be forwarded through the ssh tunnel to the moscow.company1.ru server, and this server will already establish a connection to the address localhost: 5000, i.e. to our test web -site.
The -R parameter organizes an open TCP port on the remote server, when an attempt is made to establish a TCP connection, this connection is transparently forwarded to the ssh tunnel, and then a connection is established from the local server.
The -R parameter is followed by an argument in the following form:
ssh -R XXX:server1:YYY login@server2Here server2 is the remote server to which we log in via ssh, login is the username under which we log into the remote server, XXX is the port number that needs to be organized on the remote server, server1 is the host to which we need to forward the connection from the remote server , and finally YYY is the port to which this connection should be forwarded.
Let's look at two examples.
Example 1.
- We are on the moscow.company1.ru server, and from this server a database is available on the central-db.company1.ru server, on port 9999.
- We are deploying a web application on the spb.company1.ru server, and the database is not accessible from this server.
- We organize port forwarding from the spb.company1.ru server to the database as follows: ssh -R 55555: central-db.company1.ru: 9999 login@spb.company1.ru
- After that, we deploy our web application on the spb.company1.ru server, but we specify not central-db.company1.ru:9999 as the base, since this server is not available to us, but localhost: 55555 - this connection will be forwarded to our local machine through an ssh tunnel, and then the local machine will establish a connection to the central-db.company1.ru server, port 9999.
Example 2.
- We are on the moscow.company1.ru server and have a test website deployed on our server, on port 5000.
- This test website is only available locally, connections from the Internet are not allowed, but we want to demonstrate this website to a customer who can use a web browser to access the spb.company1.ru server
- We will organize port forwarding from the spb.company1.ru server as follows: ssh -R 80: localhost: 5000 login@spb.company1.ru
- If now the user enters the browser using the link spb.company1.ru , then the connection will be forwarded through the ssh tunnel to our local server moscow.company1.ru, and a connection will be established from it to localhost: 5000 - that is, to our test web site.
What tricks can you share?
On this topic:
- The article " How to use Bash will perform the task ";
- Practical online course " Linux OS Administration ".