How Does SSH Authorization Work?
SSH stands for Secure Shell. More precisely, SSH is a secure network protocol featuring authentication and encryption. It’s used for file transfers, network management, and remote operating system access. The term SSH also refers to a suite of tools used for interacting with this protocol.
Connecting via SSH is essentially like accessing the command line of a remote host. This means any commands entered on your main machine’s terminal will function as if you were directly typing them at the remote host’s keyboard.
Since SSH operates on a client-server model, an SSH daemon must be present on the remote host for the protocol to function. An SSH daemon is software that listens on a specific network port and creates a working environment upon the other host being authenticated.
Correspondingly, an SSH client must be installed on the local machine to connect to the remote host. It interacts with the remote host and transmits the data necessary for authentication.
Linux users can install OpenSSH using this command:
sudo apt-get install ssh
In some OS, OpenSSH components can be installed separately for the client (openssh-client) and the server (openssh-server).
SSH keys provide a simple and secure method for accessing a remote node. This article will guide you through setting up SSH key-based authorization and demonstrate how to resolve some common errors.
SSH stands for Secure Shell. More precisely, SSH is a secure network protocol featuring authentication and encryption. It’s used for file transfers, network management, and remote operating system access. The term SSH also refers to a suite of tools used for interacting with this protocol.
Connecting via SSH is essentially like accessing the command line of a remote host. This means any commands entered on your main machine’s terminal will function as if you were directly typing them at the remote host’s keyboard.
Since SSH operates on a client-server model, an SSH daemon must be present on the remote host for the protocol to function. An SSH daemon is software that listens on a specific network port and creates a working environment upon the other host being authenticated.
Correspondingly, an SSH client must be installed on the local machine to connect to the remote host. It interacts with the remote host and transmits the data necessary for authentication.
Linux users can install OpenSSH using this command:
sudo apt-get install ssh
In some OS, OpenSSH components can be installed separately for the client (openssh-client) and the server (openssh-server).
Key Structure
The term “SSH key” refers to two keys – a public and a private key. Both keys are created and stored on node A, while only the public SSH key is sent to node B, enabling connection from node A to node B.
Keys can be generated using various algorithms supported by the current version of the SSH protocol. For instance, if RSA encryption is used, the files will be named as follows:
- id_rsa – private key,
- id_rsa.pub – public key.
What distinguishes a public key from a private key?
Public and Private SSH Keys
The public key encrypts data when accessing a remote host. Simply put, it’s a set of characters used to encrypt information. It is accessible to everyone. There’s no need to worry if the public key falls into the wrong hands, as possessing only this key offers no advantage to an attacker. The public SSH key is stored on the remote host.
The private SSH key is the key to the encrypted data. It decrypts the messages. It is stored on the device that will connect to the remote node (where the public key is located). Under no circumstances should the private key be given to unauthorized persons, including through messengers or file-sharing services, to prevent leaks of information and personal data. We also recommend immediately setting up a password for the private key to provide additional security.
Imagine that Servercore is the server, and you are the client. You want to connect to us via an SSH key. You have already created a pair of keys and sent us the public key. The interaction will proceed as follows:
- You need to request to connect to us, that is, send a request for a TCP port connection.
- If a TCP connection is established, we will exchange information about our SSH protocol versions. This information helps determine the specific configuration (protocol version and operational algorithms) to use. You can determine the OpenSSH version yourself by using the ssh -V command.
- Once verified, we (the server) will send you (the client) the public key. Now, it’s your decision whether to trust this key or not. If you agree, we will generate a session key together, which will be used to symmetrically encrypt the channel. This key only exists as long as the channel (current session) does.
- Then it would be the time to authenticate you. For this purpose, you send us your public key. We then verify it against our list of registered SSH keys. If a match is found, we generate a random number, encrypt it with the public key, and send it back to you. As the client, you decrypt the message with your private key and send the data back to us. If the returned number matches the original, authentication is successful.
Congratulations! You now have access to the server.
Types of SSH Keys
As you already know, there are two primary types of keys: public and private. Additionally, keys can be categorized by their encryption type.
Entering the command ssh-keygen ? to the terminal will display help information where the -t parameter lists the algorithms available on this system:
~# ssh-keygen ? … [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]
RSA – by default, ssh-keygen uses RSA for the -t parameter because this algorithm offers the best compatibility among all but requires a larger key size for adequate security. The default key length is 3072 bits, but you can manually set it from 1024 to 16384 bits using the “-b” parameter of the “ssh-keygen” command.
Keep in mind that larger keys require more computational power and take up more network traffic. Therefore, if you need enhanced protection and wish to increase the length of your RSA key, consider using elliptic curve-based algorithms instead. In these conditions, such algorithms operate faster.
DSA – a cryptographic algorithm that uses a public key for creating electronic signatures but not for encryption. This means only one node can sign a message while all the others can only verify its validity. The DSA algorithm is based on the computational challenge of solving logarithms over finite fields. Compared to RSA, DSA performs better in generating signatures but takes longer to verify them. Also note that the maximum key length for this type is 1024 bits, Also note that the maximum key length for this type is 1024 bits, which isn’t very hack-proof.
ECDSA – an implementation of a digital signature scheme that utilizes elliptic curves and modular arithmetic. This algorithm performs faster than RSA because it requires much smaller keys for encryption. However, it’s more susceptible to hacking via quantum computing than RSA.
ED25519 – an elliptic-curve signature algorithm that offers better security than both ECDSA and DSA, along with good performance. Its primary advantages include speed. However, this algorithm is only supported in OpenSSH versions 6.5 or later.
ECDSA-SK and ED25519-SK are variations of ECDSA and ED25519 that support hardware authentication. These algorithms were introduced recently in OpenSSH version 8.2. They enable two-factor authentication using devices that support the FIDO/U2F protocol. There are various forms of physical authentication, such as USB tokens or other device types that connect via Bluetooth or NFC.
Storing the Public Key in the Servercore Control Panel.
You can add a public key right when you order a server. All added keys are stored in the “Servers and Hardware → SSH Keys” section.
Creating an SSH Key.
Parameters of the ssh-keygen Utility.
In Linux, creating SSH keys uses the “ssh-keygen” command. Below are the most popular parameters for this command along with their descriptions.
-C comment
Creating a new comment. For instance, one of the well-known commands is to add a comment detailing who created the key, on which machine, and when:
ssh-keygen -C "$(whoami)@$(uname -n)-$(date -I)"
—p
If you include this parameter when using ssh-keygen, you will be prompted to replace the old passphrase with a new one. Entering the command will appear as follows:
ssh-keygen -p
You can also set all the parameters to change the passphrase at once:
ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
—t type
Specifies the type of key being created. To find out which types are available for your version, enter:
ssh-keygen -t ?
-v
Detailed mode, where ssh-keygen will print debugging messages about its progress. Using multiple -v options increases the detail level of the information (up to a maximum of 3).
Generating SSH Keys in Linux.
The process of creating SSH keys on Linux is extremely straightforward. You just need to specify a few parameters, which we will describe next.
We are going to create an RSA key. When entering the ssh-keygen command, you can omit the -t RSA parameter since RSA is the default algorithm.
~# ssh-keygen Generating public/private RSA key pair. Enter file in which to save the key (/root/.ssh/id_rsa):
In the last line, you will be prompted to select the path where the keys will be saved. If you leave the field blank, files named id_rsa.pub and id_rsa will be created.
Enter passphrase (empty for no passphrase):
This line prompts you to create a passphrase. Leaving this field blank means no additional protection will be added.
On the one hand, not entering a passphrase is risky. If the private key falls into malicious hands, they could gain access to your server. On the other hand, entering a passphrase could be inconvenient in future use. You will need to enter the passphrase each time you use an SSH connection with this key. Therefore, whether to use a passphrase or not is up to you.
As previously mentioned, you can set (or replace) the passphrase yourself by entering ssh-keygen -p once the key has been created.
Your identification has been saved in /root/.ssh/id_rsa Your public key has been saved in /root/.ssh/id_rsa.pub The key fingerprint is: SHA256:Uh6CVy4Voz0/70Am8j+hXOLBV21l4rMmiMLG5BTz3cE root@trexclient The key's randomart image is: +---[RSA 3072]----+ | =. . | | .o* . E . o| | . =+*. . + + | | .o=.+. o = | | *o.S.=o . o | | *+=+=o. o | | . +.*...o | | +..o | | ... | +----[SHA256]-----+
The created files are stored in /home/*SystemName*/.ssh/ directory.
Generating SSH Keys in Windows via PuTTY.
If you want to create SSH keys on Windows, PuTTY is the most popular software of choice. You can download it from the official website by clicking here (the current version at the time of writing is PuTTY 0.78). After installing the software, several .exe files will be available to you.
To create SSH keys, open puttygen.exe, select the required key type and set its size. We will use RSA with a length of 3072 bits.
Next, click Generate and move your mouse around in a blank space of the screen until SSH key generation is complete. This is needed to introduce pseudo-randomness into the key creation process.
After generating the key, you can enter a comment and a passphrase.
Next, save both the public and private SSH keys to disk by clicking on the corresponding buttons in the program window. You can choose where to save these keys yourself.
PuTTY saves private keys with a .ppk extension, meaning these keys can only be used with PuTTY software. To save the secret key in a format suitable for OpenSSH, select “Export key in OpenSSH format (new format)” in the Conversion tab and specify where to save the new file (the old format does not preserve all fields when converting from .ppk to OpenSSH, such as comments).
Generating SSH Keys in Windows via OpenSSH.
Windows recently added support for OpenSSH tools. The package has been included in operating systems starting with Windows 10 and Windows Server 2019.
You can install the OpenSSH client using this command in PowerShell:
Add-WindowsCapability -Online -Name OpenSSH.Client
Or through the GUI by navigating to Settings → Apps → Optional Features → Add an optional feature. In the list of components, find OpenSSH Client and click Install.
You can check the component’s status with this command:
Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Client*'
If it responds with “Installed”, the installation was successful.
SSH key generation is performed in Windows just as it is in Linux, using ssh-keygen:
PS C:\Users\Administrator> ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (C:\Users\Administrator/.ssh/id_ed25519): Created directory 'C:\Users\Administrator/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\Administrator/.ssh/id_ed25519. Your public key has been saved in C:\Users\Administrator/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:1qBO0MIgYM+A80G1zZgUzW4QCYHKNuLgwaIR77sY2/U administrator@winservercore The key's randomart image is: +--[ED25519 256]--+ |===+=* | |*.=+oBo | |+= +Bo+ . | |**o oo. o | |Ooo .o S . | |.o. o . | |. .. . | | =.. . | |o o. E | +----[SHA256]-----+
The created keys can be found in the C:\Users\Administrator\.ssh folder unless it was changed during generation.
Copying the Public Key to the Server
In this section, we will explore the common method of copying a public SSH key to a server.
Copying using SSH-Copy-ID
This method is suitable for those whose operating system supports the SSH-Copy-ID command and whose remote server allows keyless SSH access. If this is not the case, consider using the second or third method.
The command syntax is as follows:
-# ssh-copy-id username@remote_host
Pay attention to the last lines of the output:
-# ssh-copy-id root@5.159.102.80 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub" The authenticity of host '5.159.102.80 (5.159.102.80)' can't be established. ED25519 key fingerprint is SHA256:KSvVyjbijk+LQ7n3cEQd94qcyIcTDfaED+jRFzBBPGM. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])?
Our client requests permission to continue connecting to the remote host, as it is encountering it for the first time. Enter “yes“. After a successful connection, the keys will be added, and we will see the corresponding output:
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@5.159.102.80's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'root@5.159.102.80'" and check to make sure that only the key(s) you wanted were added.
To verify that the public key has indeed been copied, locate the “authorized_keys” file on the remote host and examine its contents – this is where the public SSH keys should be stored.
~# cat /root/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCoQ/EcDWqYKTKCLkd3gZcz98+wRSCTNVNmLUUF6HqWsl105sBX6vep4/xe6cc6zcYSCgFgcKGEK8h2QNIzw+DmdH2Ujxn6AaEkaNBS0b4AGMJSYREqCh6tRpTwBF1VVV5usLMQLz9/eh7HVhorCsHB6bdxk+M2sJOHxX1ikynnwc2cRs12uY/mWMfdLi6S1Q76NmgcfR/ICjyxXUcM3FlmUUsyzQJVyq7+pPr5ahodJw0LRKe3hRNPdQIiXOlNXn1tX7oIxcN9wZ5VR4ZwMORwNBZymZA3oS2Kr27cHvvIhwtEC92ouxd3ue1H8mBmexzbwW6S9Qom0pLiEclK4zRrKmmAWLgHV/2I7nzH6n3V+RFGttW3EOTKTI6n48tnKx7RKaM0qBpzqSAxanNaW3NRvrs++NSjb2LnZoLFoSf9YPLB6YrI6cO08vkWbesc/DWHic3BYPPEaj0rekj5dLJip+acdJw0AiG3dzwfw4ppmcv7zuQpanJYntpmLHoQV4E= root@trexclient
As we can see, the client’s public SSH key has been successfully added to the server.
Note: If you are using a non-standard port for SSH connections on the remote host, you must specify additional parameters when entering the ssh-copy-id command:
ssh-copy-id ‘-p *port* username@remote_host’
After making changes, you must restart the SSH services.
sudo service ssh restart (for Ubuntu / Debian / Mint Linux) sudo service sshd restart (for CentOS / RHEL / Fedora Linux)
Copying a Key via SSH
This method is suitable for those whose client machine does not support the SSH-Copy-ID command, but the server allows SSH access.
In such cases, you can use the following command:
cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
where
- cat ~/.ssh/id_rsa.pub – outputs the contents of the id_rsa.pub file,
- ssh username@remote_host – connects to the remote server,
- «mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys» – checks if the /.ssh directory exists and redirects the output of the first command to the authorized_keys file.
To confirm that the public key has been copied, just as in the first method, find the authorized_keys file on the remote host and check its contents.
~# cat /root/.ssh/authorized_keys
After making changes, you must restart the SSH services.
sudo service ssh restart (for Ubuntu / Debian / Mint Linux) sudo service sshd restart (for CentOS / RHEL / Fedora Linux)
Manual Copying by the User
This method should be used by those who lack SSH access to the remote server. You need to locate the file id_rsa.pub (if using Linux) or public (if using Windows) on your client machine, open it and copy all its contents. Using the Linux console, this can be accomplished with the cat command:
cat ~/.ssh/id_rsa.pub
Then, connect to the remote server by any means available to you, where you need to copy the public SSH key. In our case, this would be console access to a cloud (virtual) server via the Servercore control panel.
Go to control panelOnce you find the same authorized_keys file, simply paste what you previously copied from the id_rsa.pub file on your client machine into it. If you generated SSH keys in Windows using PuTTY, you must also copy the public key into the authorized_keys file. Alternatively, you can open a console and use a command to upload the key:
echo *Text* >> ~/.ssh/authorized_keys
where *Text* is the data you copied from id_rsa.pub.
After making changes, you must restart the SSH services.
sudo service ssh restart (for Ubuntu / Debian / Mint Linux) sudo service sshd restart (for CentOS / RHEL / Fedora Linux)
Using SSH Keys
Configuring Server Authentication via SSH keys on a Linux OS
To connect via SSH with keys, enter the command from the client machine where you created the keys:
~# ssh username@remote_host root@trexclient:~# ssh root@5.159.102.80 Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-60-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage * Introducing Expanded Security Maintenance for Applications. Receive updates to over 25,000 software packages with your Ubuntu Pro subscription. Free for personal use. https://ubuntu.com/pro Expanded Security Maintenance for Applications is not enabled. 0 updates can be applied immediately. Enable ESM Apps to receive additional future security updates. See https://ubuntu.com/esm or run: sudo pro status Last login: Sun Mar 5 12:31:34 2023 from 152.89.133.14 root@servercoreserv:~#
If your username on both the local machine and remote host matches, you can shorten the command to:
~# ssh remote_host
Configuring Server Authentication via SSH keys on Windows OS
We previously copied an open SSH key generated with PuTTY to a remote host. Now, proceed with connecting.
To do this, launch putty.exe, input the IP address and port of the remote host, and ensure SSH is selected as the connection type.
Next, follow the path indicated on the screenshot (Connection → SSH → Auth → Credentials):
In the “Private key file for authentication” field, insert the link to the private key you wish to use for this connection and click “Open“.
A window will open where you must enter the username of the remote host’s user. In our case, it is “root”.
Connecting from Windows with OpenSSH is the same as the process of connecting via SSH on a Linux server:
C:\Users\Administrator> ssh hostname@remote_host
If a passphrase was set during SSH key generation, the remote host will request its verification:
Enter passphrase for key 'C:\Users\Administrator/.ssh/id_ed25519':
Executing a Single Command on the Remote Node
If you need to execute just one command, there’s no need to establish a full session; simply input the necessary command following ssh hostname@remote_host.
ssh hostname@remote_host command
Technically, a session is still established, and authentication will occur based on the provided data. The required command is transmitted, and the session is immediately terminated. Visually, it appears as though we’ve merely sent a command to the remote node.
SSH Key Fingerprint
Each pair of SSH keys utilizes a unique cryptographic fingerprint. This can be used to identify keys.
~# ssh-keygen -l Enter file in which the key is (/root/.ssh/id_rsa):
Here, you can leave the field empty if the desired key is automatically selected. If that’s not the case, input the location of the file you’re interested in. This will display an entry similar to this (key length, key fingerprint, user and host for which the key was created, encryption algorithm used):
3072 SHA256:UxyIzKj93YXoldmfyP5K4/uKkHTu9UoG0nK9e93q57g root@trexclient (RSA)
Changing the SSH Port
Changing the default port on which SSH operates can serve as an additional layer of security for your server. Before altering the connection port, open this port in the firewall with the following command:
sudo ufw allow *port*
Let’s now proceed to change the port. Firstly, when on the remote host, you need to open the sshd_config file:
sudo nano /etc/ssh/sshd_confog
Within this file, locate the “Port” line and enter your value, for example, 4312.
Port 4312
Afterwards, you will need to restart the SSH daemon:
sudo service ssh restart (for Ubuntu / Debian / Mint Linux) sudo service sshd restart (for CentOS / RHEL / Fedora Linux)
When connecting to this remote host, you now need to specify the new SSH connection port using the -p parameter:
ssh -p 4312 hostname@remote_host
If you would prefer not to enter -p 4312 every time, you can modify the SSH configuration file on your local machine as follows:
nano ~/.ssh/config Host *alias_name* HostName *remote_host* Port *port* User *username*
Now, when connecting to the remote host using the ssh *AliasName* command, the port will automatically be selected based on the corresponding entry in /config.
Authentication Forwarding
Authentication forwarding involves authenticating on another server through a server you are connected to using a local key. In essence, we connect from node A to node B, and node B uses node A’s data to connect to node C.
On node A, we entered the connect command with the -A option, thereby connecting to host_B.
On node host_B, we entered the following command and connected to node host_C using node A’s credentials.
root@host_B:~# ssh root@*host_C*
Thus, you can connect via SSH to any other device that allows access with your SSH key through an intermediary.
Increased Timeout
The connection timeout may take too long, requiring you to reconnect to the system. To prevent this, configure so that the remote host checks for an active SSH connection by sending echo requests every ServerAliveInterval seconds. If there’s no response after ServerAliveCountMax attempts, the connection will be terminated.
These modifications need to be applied to the /etc/ssh/sshd_config file on your server.
ServerAliveInterval *count* ServerAliveCountMax *count*
Disabling Password Verification
Previously, we set up SSH access using keys, but password-based login remains enabled. To safeguard against potential brute force attacks, disable this authentication type. For this purpose, on the server, open the sshd_config file:
sudo nano /etc/ssh/sshd_config
Find the PasswordAuthentication line within it, change its value from yes to no, and save your changes.
PasswordAuthentication no
To activate these changes, restart the SSH service:
sudo service ssh restart (for Ubuntu / Debian / Mint Linux) sudo service sshd restart (for CentOS / RHEL / Fedora Linux)
Now your server will no longer allow passwords to be used as an authentication option with SSH connections.
Troubleshooting
The server ignores the key
Occasionally, despite being set up correctly, you might be unable to connect to the server using SSH keys. Seeing this output might lead you to believe that the server does not recognize your key:
Permission denied (publickey).
Most likely, the SSH server thinks that some directories have inappropriate permissions. To resolve this issue, modify the access permissions.
Configuring the Remote Host
Only the owner has full access to the .ssh directory; all others should be fully restricted:
chmod rwx------ ~/.ssh
Write and read permissions for the authorized_keys file are exclusive to its owner; all others should be fully restricted:
chmod rw------- ~/.ssh/authorized_keys
Cancel write permissions for groups and other users:
chmod go-w ~/
Setting Up the Local Machine
Only the owner has full access to the .ssh directory; all others should be fully restricted:
chmod rwx------ ~/.ssh
Write and read permissions for the key file are exclusive to its owner; all others should be fully restricted:
chmod rw------- ~/.ssh/*key*
After implementing these policies, the error should be resolved.
Encrypted Home Directory
If your home directory is encrypted, SSH cannot access your authorized_keys file until you authenticate. Consequently, SSH defaults to password-based login. To address this issue, create a directory outside your home directory named /etc/ssh/*username*. This directory should have rwxr-xr-x permissions and be owned by you. Move your authorized_keys file into this directory (it should have rw-r-r- permissions and be owned by you).
Then modify /etc/ssh/sshd_config by adding an entry:
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
Restart the SSH service.
sudo service ssh restart (for Ubuntu / Debian / Mint Linux) sudo service sshd restart (for CentOS / RHEL / Fedora Linux)
Next time you connect via SSH, entering a password won’t be necessary.
Analyzing Connection Logs
If connection errors occur, review the /var/log/auth.log file which details all connection attempts and authentication methods used.
For more detailed connection information, use -v, -vv or -vvv parameters. The more -v keys used (up to three), the more detailed your log will be.
ssh -vvv hostname@remote_host
Visiting Help
For a comprehensive description of commands (including parameters and values), refer to documentation available via the man command, for example:
man ssh man sshd
Conclusion
This text explores creating and authorizing with SSH keys on Linux and Windows platforms while addressing potential errors encountered with this authorization method. Using SSH keys not only streamlines authorization but also enhances your server’s security level.
