You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The none authentication takes a special position among the authentication methods.
9
+
The reason is that this authentication method is used to tell the client which methods are accepted by the server. For this reason, none-Authentication is executed before all other authentication methods.
10
+
11
+
However, it can also be used to give a user access to a system without requiring an explicit login.
12
+
13
+
password authentication
14
+
-----------------------
15
+
16
+
Password authentication is one of the most common login methods. Almost all current operating systems support this method both for local logins and over the network. By default, OpenSSH and many other SSH servers have this type of authentication active.
17
+
18
+
With SSH, within the encrypted channel, the password is transmitted in clear text. If a client connects to a Man in the Middle server, the server is able to read the username and password in clear text. This information can then be used to log in to other servers if the user exists and uses the same password.
19
+
20
+
Another problem is that accounts with weak passwords can be compromised relatively easily through a brute force attack. This happens very often with IoT devices because they often have the same username on many devices and they are protected by a default password or only a weak password is set.
21
+
22
+
.. warning::
23
+
24
+
Password authentication should not be used for these reasons!
25
+
26
+
27
+
Example SSH-MITM session intercepting password authentication:
2021-09-02 09:51:48,629 [INFO] Client connection established with parameters:
35
+
Remote Address: 127.0.0.1
36
+
Port: 22
37
+
Username: testuser
38
+
Password: secret
39
+
Key: None
40
+
Agent: no agent
41
+
42
+
43
+
keyboard-interactive authentication
44
+
-----------------------------------
45
+
46
+
keyboard-interactive is similar to password authentication. The main difference is that the server can send any number of requests to the client, which are necessary for the login process. The server defines both the prompt text and whether the value is visible or not when entered.
47
+
48
+
In many cases keyboard-interactive is used for 2 factor authentication. In the first step a password is requested and then e.g. the input of a time-based token is necessary (TOTP).
49
+
50
+
Unless special tools are used to create cryptographically secured input, all input via keyboard-interactive can be reused during a man in the middle attack to login to another server.
51
+
52
+
53
+
54
+
publickey authentication
55
+
------------------------
56
+
57
+
In contrast to password authentication, where the password is transmitted in plain text, publickey authentication is based on asymmetric encryption. In asymmetric encryption, a key pair consisting of a private part and a public part is created.
58
+
59
+
With SSH, the public key is stored on the server while the private key remains in the possession of the user.
60
+
61
+
With OpenSSH, the private key can be additionally protected by a password in case it is stolen. Starting with OpenSSH 8.2, FIDO2 tokens are supported and can be used for a 2 factor confirmation when using the key.
62
+
63
+
As an alternative to a FIDO2 token, SSH-Askpass can also be used to confirm cryptographic operations. If there is an increased need for security, SSH-Askpass should only be used if the use of a FIDO2 token is not possible.
64
+
65
+
Publickey authentication is only partially suitable for a man-in-the-middle attack. Unlike password authentication, no data is exchanged that can be used for a complete login.
66
+
67
+
Another problem is that the key that should be used for the login is not known. This can lead to FIDO2 and SSH-Askpass protected keys displaying a prompt for an incorrect key to the user.
68
+
69
+
An attacker should use PublicKey authentication only if the client does not accept other authentication methods.
There are several ways in which SSH keys can be managed locally. One of the most common use cases is to store a key in the file system. SSH clients are able to read them from specific directories. For example, an RSA key may be stored as .ssh/id_rsa in the user's home directory.
5
+
6
+
To protect these keys from unauthorized access after theft or loss, it is recommended to store them encrypted. For this purpose it is necessary to enter a password.
7
+
8
+
The SSH Agent can be used to manage these keys. The password input, for decrypting is only necessary once during loading into the SSH Agent. All further cryptographic operations are then performed without the need to enter a password.
9
+
10
+
For the communication between SSH Agent and SSH Client a Unix socket is created and stored in a new subdirectory in /tmp. Because of this design, any user with appropriate privileges, such as the root user, is able to access and use this Unix socket.
11
+
12
+
For this reason, it is important that privileged users are trusted or that their accounts are not compromised.
13
+
14
+
To protect against misuse, a key can be secured with SSH-Askpass or a FIDO2 key. In both cases, user confirmation is required.
15
+
16
+
The big advantage of a FIDO2 key is that the confirmation is done via a separate hardware and cannot be compromised by a malware infected machine. SSH-Askpass is a software solution that can be bypassed by malware or an attacker who controls the victim's desktop.
17
+
18
+
For this reason, the use of a FIDO2 key is recommended over the use of SSH-Askpass.
19
+
20
+
21
+
SSH Agent Forwarding
22
+
--------------------
23
+
24
+
Many SSH clients offer the possibility to pass a local agent to a remote server. The corresponding protocol was defined in draft-ietf-secsh-agent-00. The corresponding draft was already defined in 2001 and almost all SSH clients support it.
25
+
26
+
A passed SSH agent can then be used to login to another server.
27
+
28
+
The advantage is that no sensitive data, such as private SSH keys, need to be stored permanently on the remote servers, but a secure login using Publickey authentication is still possible.
29
+
30
+
In most cases, agent forwarding is only supported for a shell connection. Agent forwarding is theoretically also possible for file transfers using SCP and SFTP, but most programs do not support this feature.
31
+
32
+
OpenSSH has implemented agent forwarding with version 8.4 for the client programs scp and sftp as well, in order to not have to copy these files via the local host for remote to remote file operations.
33
+
34
+
However, SSH Agent Forwarding is associated with a security risk. This is because privileged users can access and abuse the forwarded agent sockets.
35
+
36
+
For this reason, agent forwarding should not be used.
37
+
38
+
However, there are use cases where working without agent forwarding, is more costly. One possibility is working on a development server. From this server, it is often necessary to access a Git server to synchronize changes. Without a forwarded agent, custom keys would have to be created to access the Git server. These, in turn, could be stolen and thus abused if the server were compromised.
39
+
40
+
There is a tutorial on Github (https://docs.github.com/en/developers/overview/using-ssh-agent-forwarding) that describes how to configure OpenSSH to pass an agent through to a remote server.
41
+
42
+
However, it does not address the risk that a leaked agent is a potential security risk. The only warning is that the configuration must only be done for a specific host, otherwise the agent will be passed through to all servers you connect to.
43
+
In order to make it as difficult as possible to misuse the leaked keys, it is necessary to protect them with a FIDO2 token or SSH-Askpass. In the case of a passed-through agent, both solutions have a comparable level of security.
44
+
45
+
Nevertheless, the use of FIDO2 keys is recommended because a vulnerability in the client could eventually leak them. An example of this was the experimental support for roaming in OpenSSH 5.4. This feature should make it possible for a client to resume an unexpectedly terminated connection. Although the OpenSSH server did not support roaming, roaming was enabled in the client by default.
46
+
47
+
The roaming implementation had two vulnerabilities that allowed an attacker to access sensitive information such as private keys under certain circumstances.
48
+
49
+
.. warning::
50
+
51
+
SSH Agent Forwarding should not be used. The reason is that it can prevent a lot of security risks. Agent forwarding often makes it easier to work with multiple servers. However, for most use cases there are ways to accomplish the same tasks without agent forwarding.
52
+
53
+
If agent forwarding is still required, an FIDO2 token should be used. If this is not possible, e.g. because the server does not support the required algorithms, SSH-Askpass can also be used.
0 commit comments