How to Secure Raspberry Pi SSH server
By default, an SSH server is active on a Linux distribution for Raspberry Pi, such as Raspbian. This allows you to log in to Raspberry Pi over the network with an SSH client, without having to sit directly on Raspberry Pi with the keyboard and screen.
This remote access is relatively secure by default. If you only operate your Raspberry Pi as a client on the network and occasionally, you do not have to worry about the security of the SSH server. It looks quite different if Raspberry Pi runs permanently as a gateway or server and can be reached directly from the Internet, for example, via VPN, IPv6 or otherwise. At the latest then one should worry about the safe operation of Raspberry Pi. For example, how to secure the SSH server on Raspberry Pi.
Note: In a home network with no port forwarding to the server, there is no real security problem with root access. It only gets risky if IPv6 is switched on. Then security comes and goes with a well-configured firewall on the network access router.
Task
- Assess the following security issues for overall system.
- Implement suitable measures for this.
Preliminary note on the following security issues and measures
- There is always a certain amount of paranoia in all solutions in IT security. The reason is, you never know what the attacker can do, what tools he uses, and what unknown security holes the system has.
- Basically, it is permissible to question the meaningfulness and usefulness of all solutions.
- Any restriction of the SSH login also involves a loss of comfort. This can go so far that you have to laboriously “fight” in an emergency access.
- There is no firm way to make a system “safe”. If it existed, it would be preset everywhere.
- The following parts of this manual or the individual solutions do not build on each other. The order is not necessarily based on “important” and “urgent”. All measures make a system safer. Some of them more or less effective. The more hurdles a login has, the more secure.
- The described solutions assume that the Linux distribution Raspbian is used and that the user can gain root rights via “sudo”. In principle, the solutions also work with other distributions.
Overview: Security issues and possible actions
- Safety of the overall system
- Server operating
- Remote Access
- Basic settings
- Lock or unlock SSH access for a specific user
- Create a special user for SSH access
- Share SSH access for a specific user group
- Restrict authorization for “sudo”
- Default port
- Change default port
- Attackers in the local network
- IP Binding
- Lock users in case of multiple authentication errors
- Turn off password access
Safety overall system
One has to differentiate between the security of the entire system and the security of the SSH server. Before we turn around the settings of the SSH server, the consideration of the entire system is necessary. Hardening an SSH server is pointless if the overall system has security holes and flaws. For example, standard users and passwords. Security weaknesses of the overall system can remove any security measures at SSH.
Safety must always be seen as an overall concept. Regardless of what security measures are useful for SSH, you must always consider the security of the entire system. Basically you should start there.
Preparation: Backup SSH configuration file
Before we start, we will create a copy of the SSH configuration file. If anything goes wrong, we can always return to the original configuration.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup
Security Issue: Remote Access
In general, remote access over the network is always a problem. It allows access to a system without physical proximity. In principle, this is comfortable if you can come to systems remotely. Under certain circumstances, the distance is too far to get to the system in a timely manner. Access to important systems is usually limited in terms of organization and space. Sometimes physical access is possible only with great effort. But if the remote access has vulnerabilities, then an attacker can easily access the system remotely.
Remote access may be a security issue, especially SSH access over the Internet is not a good idea.
Remote access via SSH is convenient. No question. But is he really necessary? Or, in other words, the convenience of remote access is worth sacrificing a high level of security. As a rule, this question will be answered lightly with “yes”, although under strict interpretation of safety regulations a “no” would be correct.
Without the analysis of hazards and associated risks, this question is not easily answered. Therefore once again the question: Is a really remote access necessary? Would access via screen and keyboard on site not be enough?
Solution: Shut down SSH server (temporarily)
Is remote access via SSH necessary at all? If the answer is no, then you can dramatically increase the security of Raspberry Pi in one go. By shutting down AND possibly uninstalling the SSH server. Because then you can not get on it from the outside. The attacker is forced to come to the machine locally, which significantly increases the effort of an attack. As a rule, the access of unauthorized persons can be organizationally excluded.
sudo insserv -r ssh
sudo apt-get remove ssh
More secure is only when the server is no longer connected to the network. But this is not intended for a server.
If you do not want to forego the convenience of remote access, but you do not need to be constantly available, you can temporarily turn it on and off. For example, the SSH server remains installed and securely configured. But only temporarily turned on for remote access. For example, by key switch, which must be operated on site. Or by entering the command on-site via screen and keyboard.
sudo service ssh start
sudo service ssh stop
Security issue: Root access via SSH
It can be said that if an attacker first comes to where he can log in with “root”, then it is actually already too late. In principle, then you have already done something wrong before and has a real security problem.
And for this reason, if previous security measures do not work, then it is a hurdle for the attacker, if access via “root” is not possible.
By default, Raspbian does not have a password set for the user “root” in the Linux distribution and therefore typically no login via SSH is possible. However, somebody could set a password for “root”. Then the access for the user “root” should not be possible via SSH.
Solution: Basic settings
There are a few basic settings in the SSH configuration file that should be set by default. For security you should check that.
sudo nano /etc/ssh/sshd_config
The following setting specifies the SSH protocol to version 2. Version 1 is considered outdated and insecure and exists only for compatibility reasons.
Protocol 2
Each system has default users for whom no password is set. These users should not be able to access via SSH. The following setting does not allow access for users who do not have a password.
PermitEmptyPasswords no
By majority opinion, root access via SSH should be impossible. The administrator should always log in as a normal user and only then, if necessary, procure the rights of “root”.
PermitRootLogin no
In order for the change to be reflected in this file, the file must be saved and then the service or Raspberry Pi restarted.
sudo service ssh restart
Being connected to Raspberry Pi via SSH does not affect the connection. That is, the SSH connection is not terminated.
Note: For all other settings, we assume that they are made in the file “/ etc / ssh / sshd_config” and that after restarting the settings, a restart of the SSH server is necessary.
Solution: Lock or unlock SSH access for a specific user
If you want to exclude a certain user from using the SSH server, then you can lock it directly with his username.
DisallowUsers {USERNAME}
A better idea is to limit SSH access to only one user. For example on “pi”.
In the configuration file you enter the following:
AllowUsers pi
With this setting, all other users are no longer able to log in via SSH.
Solution: Create a special user for SSH access
It’s a good idea to restrict SSH access to a specific user. You can even go one step further and create a user for SSH access only. After that, only this user can log in via SSH.
First we create a new user:
sudo adduser sshuser
and follow the instructions.
Then you have to enter this user in the configuration file.
sudo nano /etc/ssh/sshd_config
Here you enter the following line:
AllowUsers sshuser
This limits SSH access to the user “sshuser”. By default, this user is able to obtain root privileges via sudo.
Solution: Share SSH access for a specific user group
The solution to limiting SSH access to a specific user is certainly a good solution. But what if you want to add more users later. Then every time a reboot or restart is necessary. You really want to avoid this with a server. Therefore, this is solved once via the Linux user control. Here you create a user group “ssh” or similar. Assigns the appropriate users to this group and releases this user group in the SSH server configuration.
First, we create a new user group named “ssh”.
sudo groupadd -r ssh
Then we assign the user “pi” to the user group “ssh”.
sudo gpasswd -a pi ssh
Then we enter the permission for the group “ssh” in the file “/etc/ssh/sshd_config”.
AllowGroups ssh
At this point you have to make sure to remove the permission of individual users with “AllowUsers”, so that the permission really only works on the assignment of the users to the user group “ssh”.
Then you can at any time without Reboot users give the permission to access via SSH on Raspberry Pi and remove again.
Share:
sudo gpasswd -a {USER} ssh
Remove:
sudo gpasswd -d {USER} ssh
Solution: Restrict permission for “sudo”
Strictly speaking, restricting SSH access to a user who is allowed to run “sudo” without a password from “root” is not really secure. With a Raspbian it is the case that the standard user “pi” can get root rights via “sudo” at any time. And that without entering the root password. One should think about whether it makes sense to put a stop to this constellation. It is safer if the attacker needs two passwords. Once the user and then the password of “root”.
Security problem: standard port
When an attacker wants to access a host via SSH, he uses standard port 22. He uses automatic programs to scan the Internet for potential destinations listening on port 22. For example, if someone finds a destination that responds, they try to log in using standard usernames and passwords. Or he tries a brute-force attack right away. At some point he may find the right password.
So it would be better if the SSH server does not listen to the standard port 22, but to another port between 1024 and 65535.
The change of the standard port is not a real security measure, but only a hiding or disguising, which falls under the term “Security by Obscuritiy”. The only thing preventing the SSH server from being bothersome with silly attackers and systematically searching programs. For even failing authentication attempts bind resources in the form of computing power and storage space.
In general, this type of attacker does not check all ports, whether there is an SSH server listening somewhere. Most go over to the next target.
Changing the default port will at most prevent inoffensive script kiddies from attempting further attacks. Someone who really wants to gain access does not stop you.
Changing the default port is always accompanied by a loss of comfort. This may be greater than the security gain. Remote access is still possible. But only on a different port. As an administrator you must always fight with the restriction, because you have to specify the different port number when addressing explicitly.
In practice, a different port number is always a nuisance. There are good reasons for standard ports. You should not change that if there is not really a reason for it. The comfort loss does not always weigh the safety gain.
The only thing that really brings it, less load on the system and fewer entries in the log files.
Solution: Change the standard port
To change the default port, an entry in the SSH configuration file must be changed.
sudo nano /etc/ssh/sshd_config
Here you look for the following line:
Port 22
The number “22” is the port number that you change to any other port number between 1024 and 65,535. The important thing is that you remember the port number, because you have to specify in the future when establishing a connection.
Port 10101
After saving and closing, a restart of the SSH server or Raspberry Pi is necessary.
From then on, the port number must be specified when connecting to, because the SSH client starts from the standard port number.
ssh [email protected] -p 10101
Note: Changing the default port does not prevent attacks. It only reduces traffic from bots who want to log in automatically. If the SSH server does not respond on port 22, attackers usually just move on. An attacker who means serious, but will not be deterred by it just to check all ports for accessibility. He will quickly find out on which port the SSH server is listening if one is active.
Security Issue: Attackers on local network
If the attacker somehow made it into the local network, then you really have a problem. Because then all hosts are in danger, to which one cannot connect directly from the Internet.
Solution: IP binding
There are several ways to protect yourself against attackers from your own network. One of them, if you want to work with username and password authentication, is to allow the connection only from a specific IP address.
ListenAddress 192.168.1.5
ListenAddress fe80 :: 5
All you have to do is make sure that the attacker can not figure out which addresses it is, otherwise it will try to install a client on the local network that has these addresses.
Solution: Lock user on multiple failed authentications
If an IP address has initiated multiple failed connections within a certain time, it smells strongly of an attack. Maybe even automated by a bot, who should guess the password through automated testing. The best solution would be a public-key solution. Only I do not want to or can not always implement that.
Alternatively, it would be possible to block the attacker in case of repeated incorrect authentications.
MaxStartups 10:30:60
This setting consists of three numbers separated by a colon (start: rate: full).
“start” is the number of connections that failed because of a bad authentication. Then the connections are rejected with a probability of “rate” in percent. From a number of “failed” authentications every further connection attempt is rejected.
Which values make sense? With “start” one has to ask the question, how many login attempts a human user does well, until he realizes that he does not know the right password. This means less an attacker, but rather a normal user who has forgotten the password or is no longer safe and maybe after several failed attempts but the system administrator calls. Let’s say 10 times. That’s a good value.
“Rate” is about limiting connectivity after multiple failed logins. An immediate complete block is difficult to implement because you have to pick it up anyway after a while. Instead of setting a timer here, it works here with a high probability of disconnections. With a probability of 30% only about every third connection attempt works. For a human user certainly acceptable, if he still remembers the password at some point. An annoying affair for an attacker. For a bot an additional time delay in the automated password rate.
“Full” is about completely eliminating connectivity. Especially interesting for bots who want to guess passwords automatically. After “60” failed login attempts, the bot would be excluded. Certainly an acceptable value that can be set even lower.
For example, if you “start” after 2 unsuccessful attempts to log off the connection attempts, then you should choose “rate” higher.
In addition, it is necessary to give a human user, even with complicated passwords, the possibility of entering his password several times without restriction. Otherwise the acceptance of such a security measure will decrease.
Secure Secure Shell
A good source to further secure the Secure Shell:
Leave a Reply