White spots in work with SSH
SSH is a very powerful and flexible tool, but, as practice shows, not everyone understands how it works and uses it correctly. The word Secure is included in the SSH abbreviation and is one of the key aspects of the protocol, but it is often security that receives insufficient attention. In this article I want to talk about a few common mistakes when working with SSH, as well as moments that are often forgotten.
There are several ways to authenticate a user:
SSH uses asymmetric encryption, the essence of which lies in the fact that there are two keys: public and private. You can encrypt a message with a public key and decrypt it with a private one. The private key is kept safe, and the public key is accessible to everyone. In addition, you can sign the message with a private key, and check this signature with an open one.
')
The diagram shows that after exchanging public keys, two nodes can communicate securely with each other over an insecure Internet.
In addition, user authentication can be performed using this same key pair.
The user public key must be added to the $ HOME / .ssh / authorized_keys file
There may be several public keys in this file - they will all work.
MITM-attack is a type of attack in cryptography, when an attacker secretly retransmits and, if necessary, changes the connection between two parties, who believe that they directly communicate with each other. It is a method of compromising a communication channel in which a hacker, having connected to a channel between contractors, interferes with the transfer protocol, deleting or distorting information.
One of the main innovations in the second version of the protocol was the built-in protection against MITM attacks.
The essence of the defense lies in the fact that each side must make sure that on the other side is exactly the one who is expected, and not the attacker.
For MITM protection on the client side (i.e., to determine that you are connecting to your server), the StrictHostKeyChecking parameter and the known_hosts file are responsible.
Public keys of servers are stored in files:
$ HOME / .ssh / known_hosts - user file,
/ etc / ssh / ssh_known_hosts - system file.
Each entry in known_hosts is a string containing fields and using a space as a separator:
This is where the "identification" server
Values can be the following:
What it gives us:
If everything is clear with the second item, then what about the first one?
Here you can select at least three options:
Using public key visualization
If the public key has changed
The message about the change of key can occur for several reasons:
From my practice, 1 and 2 options in the amount tend to 100%, but paragraph 3 can not be excluded, too.
Here is an example of life hacking that combines web and ssh approaches.
At first glance, this is not very safe, however, this information can be obtained using the command
However, in the first version, we additionally verify the authenticity of the received key using HTTPS.
In critical CI / CD combination use
during initialization together with
will reliably protect against MITM attacks.
You can often find this picture:
For each server on the client generated their key pairs, and in $ HOME / .ssh / creates a complete mess.
On the one hand, it is safer than using one pair of client keys — if one key is compromised, only one system becomes compromised, and not all that the user worked with.
However, as practice shows, users are guided by this last, often they simply follow all the instructions step by step:
Sometimes I observed a situation where some keys were rubbed off by others without any thought in my head.
Let me remind you: if you pursue paranoid security, it is enough to have one pair of keys, but at the same time it must be properly protected.
Regard your private SSH-key as the key to the apartment where the money is. I did not see a more careless attitude to SSH keys. If users are more or less aware of the seriousness of saving passwords, then units think about the fact that no one should be given access to a private key.
What can be distinguished here:
You can change or add a password using the command
But often there is a situation when you need to go to the server with your key and already use it there. There are three solutions to this problem:
From my practice, users in 90% of cases choose the first two options, and, as we have said, there is nothing more terrible than compromising a key.
I recommend using the third method.
SSH-agent stores secret keys and, when necessary, uses them. A program (for example, ssh), when it needs to use a secret key, does not do it itself, but refers to the ssh-agent 's, which, in turn, already uses only the data about the secret keys known to it. Thus, the secret keys are not disclosed to anyone, even programs owned by the user.
The ssh-agent command creates a socket file named /tmp/ssh-XXXXXXXX/agent.ppid, through which the interaction with the agent is performed. All child agent processes using the environment variables SSH_AUTH_SOCK (in which the name of the socket file is stored) and SSH_AGENT_PID (in which the agent process identifier is stored) provide information on how to communicate with it.
The agent provides information in a form suitable for use by the command interpreter.
When specifying the -c option, the agent uses the C Shell syntax. By default (and when explicitly specifying the -s option), the Bourne Shell syntax is used. These variables should be set in the current shell, so usually the ssh-agent call is combined with the eval command.
The agent works until it is explicitly terminated by a signal or a call.
The list of secret keys known to the agent can be viewed with the same ssh-add command with the -l command line key. The team will report and fingerprint for each key.
An example of working with ssh-agent can be seen below.
In addition, the agent solves another problem: if you encrypt a private key, then when you access it, you will not be asked for a password each time. If you use an agent, then the password will need to be entered only when adding a key to the agent.
Had every time I watched typing a string like
I was given a ruble, I would have lived in Sochi a long time ago.
On the local machine, you can find the file $ HOME / .ssh / config
Accordingly, you can register most of the parameters for the host in this file and not enter it every time.
1. When using key authentication, do not forget that there is still a password, and no matter how you protect your private key, an attacker can pick up your qwerty password and log in without needing to steal the key
There are several solutions:
PasswordAuthentication no in / etc / ssh / sshd_config
2. You can also disable the use of ssh v1
Protocol 2 in / etc / ssh / sshd_config
3. And be sure to close access to SSH for unreliable sources on the firewall
4. Previously, I would advise you to change the port from the standard 22 to another, but watching how many attempts to log in on non-standard ports happen can I say unequivocally: this is not a protection against hacking.
5. If you are already considering the selection of a password, then it will not be superfluous to configure fail2ban in order to limit attempts at selecting a password.
6. The protocol and libraries periodically find problems and vulnerabilities, the poem here works a universal approach - watch for software updates and try to regularly install at least security patches.
7. ssh-agent is safer than just copying files, however, it can also be hacked, for example, the root user on the server. Therefore, it is recommended to include forvarding only when necessary.
Read the documentation, everything is written in it, however it may sound.
SSH is a very secure protocol, but often the human factor is the main source of problems - watch for security.
Used materials
Security with SSH keys
SSH key management with agent
There are several ways to authenticate a user:
- By password - the standard mechanism, but not the most reliable, I will not focus on it
- Key by key is the most reliable authentication method, but it is provided that it is used correctly.
- By IP address - compatibility mode. I cite just for reference, I doubt that someone will use it in a sober mind.
Asymmetric encryption
SSH uses asymmetric encryption, the essence of which lies in the fact that there are two keys: public and private. You can encrypt a message with a public key and decrypt it with a private one. The private key is kept safe, and the public key is accessible to everyone. In addition, you can sign the message with a private key, and check this signature with an open one.
')
The diagram shows that after exchanging public keys, two nodes can communicate securely with each other over an insecure Internet.
In addition, user authentication can be performed using this same key pair.
The user public key must be added to the $ HOME / .ssh / authorized_keys file
There may be several public keys in this file - they will all work.
MITM Attack Protection
MITM-attack is a type of attack in cryptography, when an attacker secretly retransmits and, if necessary, changes the connection between two parties, who believe that they directly communicate with each other. It is a method of compromising a communication channel in which a hacker, having connected to a channel between contractors, interferes with the transfer protocol, deleting or distorting information.
One of the main innovations in the second version of the protocol was the built-in protection against MITM attacks.
The essence of the defense lies in the fact that each side must make sure that on the other side is exactly the one who is expected, and not the attacker.
For MITM protection on the client side (i.e., to determine that you are connecting to your server), the StrictHostKeyChecking parameter and the known_hosts file are responsible.
Public keys of servers are stored in files:
$ HOME / .ssh / known_hosts - user file,
/ etc / ssh / ssh_known_hosts - system file.
Each entry in known_hosts is a string containing fields and using a space as a separator:
- one or more server names or comma-separated IP addresses
- key type
- public key
- any additional comments
This is where the "identification" server
StrictHostKeyChecking=no|ask|yes Values can be the following:
- no - the connection will occur in any case, the maximum we will receive a warning that the connection is unsafe. You can often find in all sorts of automatic scripts such as autotests and auto-warmups, here lies the main problem - if the script runs fine, then the user (administrator) will not notice something was wrong, and infection / compromise will occur.
- ask - ask for a new connection (default value), if the record is not already in known_hosts, and, in case of agreement with the connection, a new record is added
- yes - always perform the scan, the safest option, which I strongly recommend using in automated systems. Connection is made only if there is an entry in known_hosts
What it gives us:
- During the first connection, we can determine if the attacker presented the server
- Ensuring that subsequent connections to the server will not replace the respectable server by the attacker
If everything is clear with the second item, then what about the first one?
Here you can select at least three options:
- Trust the occasion and agree to add a new server key
- Add a VisualHostKey = key flag, while the client displays a visual representation of the server's public key, this representation is unique and will make it easier to remember the key
- A flash drive or open source: this is an option for paranoids, however, if the compromise of the system can cost tens of thousands of dollars, it is not superfluous.
Using public key visualization
If the public key has changed
The message about the change of key can occur for several reasons:
- Server address changed
- The server key has changed, for example, when reinstalling the system
- MITM attack
From my practice, 1 and 2 options in the amount tend to 100%, but paragraph 3 can not be excluded, too.
Here is an example of life hacking that combines web and ssh approaches.
curl https://server.com/ssh_fingerprint | tee -a ~/.ssh/known_hosts
At first glance, this is not very safe, however, this information can be obtained using the command
ssh-keyscan example.com
However, in the first version, we additionally verify the authenticity of the received key using HTTPS.
In critical CI / CD combination use
ssh-keyscan example.com >> ~/.ssh/known_hosts
during initialization together with
StrictHostKeyChecking=yes
will reliably protect against MITM attacks.
Many keys
You can often find this picture:
For each server on the client generated their key pairs, and in $ HOME / .ssh / creates a complete mess.
On the one hand, it is safer than using one pair of client keys — if one key is compromised, only one system becomes compromised, and not all that the user worked with.
However, as practice shows, users are guided by this last, often they simply follow all the instructions step by step:
ssh-keygen ... ...
Sometimes I observed a situation where some keys were rubbed off by others without any thought in my head.
Let me remind you: if you pursue paranoid security, it is enough to have one pair of keys, but at the same time it must be properly protected.
Speaking of key protection
Regard your private SSH-key as the key to the apartment where the money is. I did not see a more careless attitude to SSH keys. If users are more or less aware of the seriousness of saving passwords, then units think about the fact that no one should be given access to a private key.
What can be distinguished here:
- Keep the key in a safe place, ideally it is encrypted storage.
- Not to give anyone access to the key, a compromised key compromises all systems where access is allowed on it
- Encrypting a private key increases security because If you lose the key, you also need to get a password to decrypt it, or spend time and computing power on hacking it.
- Do not forget to install the correct permissions on the key file 400, by the way, this is a common mistake when the client refuses to use the key
You can change or add a password using the command
ssh-keygen -p
Ssh-agent
But often there is a situation when you need to go to the server with your key and already use it there. There are three solutions to this problem:
- Copy your private key to the server
- Generate a new key pair and set it as an access option.
- Use ssh-agent
From my practice, users in 90% of cases choose the first two options, and, as we have said, there is nothing more terrible than compromising a key.
I recommend using the third method.
SSH-agent stores secret keys and, when necessary, uses them. A program (for example, ssh), when it needs to use a secret key, does not do it itself, but refers to the ssh-agent 's, which, in turn, already uses only the data about the secret keys known to it. Thus, the secret keys are not disclosed to anyone, even programs owned by the user.
The ssh-agent command creates a socket file named /tmp/ssh-XXXXXXXX/agent.ppid, through which the interaction with the agent is performed. All child agent processes using the environment variables SSH_AUTH_SOCK (in which the name of the socket file is stored) and SSH_AGENT_PID (in which the agent process identifier is stored) provide information on how to communicate with it.
The agent provides information in a form suitable for use by the command interpreter.
SSH_AUTH_SOCK=/tmp/ssh-XXt4pHNr/agent.5087; export SSH_AUTH_SOCK; SSH_AGENT_PID=5088; export SSH_AGENT_PID; echo Agent pid 5088;
When specifying the -c option, the agent uses the C Shell syntax. By default (and when explicitly specifying the -s option), the Bourne Shell syntax is used. These variables should be set in the current shell, so usually the ssh-agent call is combined with the eval command.
$ eval `ssh-agent` Agent pid 5088
The agent works until it is explicitly terminated by a signal or a call.
$ ssh-agent -k
The list of secret keys known to the agent can be viewed with the same ssh-add command with the -l command line key. The team will report and fingerprint for each key.
$ ssh-add -l 1024 46:88:64:82:a7:f9:aa:ea:3b:21:9e:aa:75:be:35:80 /home/user/.ssh/id_rsa (RSA)
An example of working with ssh-agent can be seen below.
In addition, the agent solves another problem: if you encrypt a private key, then when you access it, you will not be asked for a password each time. If you use an agent, then the password will need to be entered only when adding a key to the agent.
Local config
Had every time I watched typing a string like
ssh -p 2022 user@server.com -o StrictHostKeyChecking=yes -i ~/.ssh/server.pem
I was given a ruble, I would have lived in Sochi a long time ago.
On the local machine, you can find the file $ HOME / .ssh / config
Host server User root HostName 192.168.0.3 IdentityFile ~/.ssh/server.pem Host example.com User admin IdentityFile ~/.ssh/production.pem
Accordingly, you can register most of the parameters for the host in this file and not enter it every time.
How else can security be improved?
1. When using key authentication, do not forget that there is still a password, and no matter how you protect your private key, an attacker can pick up your qwerty password and log in without needing to steal the key
There are several solutions:
- Set a very complex password that will be difficult to pick up and store it in a protected place. This will allow you to have an alternative way to log in.
- Delete the password completely, but then there may be problems with sudo and other things.
- To prohibit password authentication on the server, in fact, as a rule, this is forbidden for the root user. It remains to ban for all users.
PasswordAuthentication no in / etc / ssh / sshd_config
2. You can also disable the use of ssh v1
Protocol 2 in / etc / ssh / sshd_config
3. And be sure to close access to SSH for unreliable sources on the firewall
4. Previously, I would advise you to change the port from the standard 22 to another, but watching how many attempts to log in on non-standard ports happen can I say unequivocally: this is not a protection against hacking.
5. If you are already considering the selection of a password, then it will not be superfluous to configure fail2ban in order to limit attempts at selecting a password.
6. The protocol and libraries periodically find problems and vulnerabilities, the poem here works a universal approach - watch for software updates and try to regularly install at least security patches.
7. ssh-agent is safer than just copying files, however, it can also be hacked, for example, the root user on the server. Therefore, it is recommended to include forvarding only when necessary.
findings
Read the documentation, everything is written in it, however it may sound.
SSH is a very secure protocol, but often the human factor is the main source of problems - watch for security.
Used materials
Security with SSH keys
SSH key management with agent
Source: https://habr.com/ru/post/358800/
All Articles