In the past I’ve published some info to enhance the security of your ssh server such as 3 easy steps to strengthen your ssh server or how to use SSH for more secure browsing in public networks, today we’ll take a look at the PAM modules of GNU/Linux and in particular the module ssh and at some options that we can activate to strengthen our ssh server.
PAM (Pluggable authentication modules) are a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independent of the underlying authentication scheme.
if you have the Openssh server installed you probably already have the PAM module up and running, this is true for sure on Debian/Ubuntu/Mint and Red Hat/Centos, the configuration file is located in /etc/pam.d/sshd and usually you don’t have to do anything, but today we’ll see how to achieve this goal:
We have our SSH server that we’ll call server A
We want the username Tom to be able to connect only from the machine B to our server A
We want the username Mary to be able to connect only from the machine B and C to our server A
With the configuration of sshd you can enable or disable single users or groups from connecting to your ssh server, but you have no control over the IP that can connect.
With Iptables you can open the ssh port (22 by default) only from certain IP but you don’t have any control on the username.
The solution to this problem is enabling an option that is usually commented out in the file /etc/pam.d/sshd:
#account required pam_access.so |
So just remove the # to uncomment this and enable a more complex access matrix to be configured in the file /etc/security/access.conf
This file contains a table of permissions.
When someone logs in, the table is scanned for the first entry that matches the (user, host) combination, or, in case of non-networked logins, the first entry that matches the (user, tty) combination. The permissions field of that table entry determines whether the login will be accepted or refused.
Format of the login access control table is three fields separated by a “:” character:
permission : users : origins
The first field should be a “+” (access granted) or “-” (access denied) character.
The second field should be a list of one or more login names, group names, or ALL (always matches). A pattern of the form user@host is
matched when the login name matches the “user” part, and when the “host” part matches the local machine name.
The third field should be a list of one or more tty names (for non-networked logins), host names, domain names (begin with “.”), host addresses, internet network numbers (end with “.”), ALL (always matches), NONE (matches no tty on non-networked logins) or LOCAL (matches any string that does not contain a “.” character).
The EXCEPT operator makes it possible to write very compact rules.
Some examples:
1) Enable user root to connect only from network 192.168.201.
+ : root : 192.168.201.0/24 - : root : ALL |
You could also write these 2 lines as:
- : root : ALL EXCEPT 192.168.201.0/24 |
2) Disallow logins to all but the accounts that are in the group wheel:
-:ALL EXCEPT (wheel) : ALL |
Please note the string (wheel) that indicates a group, you could also write it without the parenthesis, but if you have an username with name wheel that will be used instead of the group.
3) Some accounts are not allowed to login from anywhere:
-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL |
4) User “root” should be able to have access from domain .linuxaria.com and not from all the others:
- : root : ALL EXCEPT .linuxaria.com |
So now, back to our starting problem:
We have our SSH server that we’ll call server A
We want the username tom to be able to connect only from the machine B (10.100.1.1) to our server A
We want the username mary to be able to connect only from the machine B (10.100.1.1) and C (192.168.0.1) to our server A
So on our server A we’ll have this /etc/security/access.conf configuration
+: tom mary : 10.100.1.1 +: mary : 192.168.0.1 - : tom mary : ALL |
Not so hard after all to get a complex matrix of security for our ssh server and achieve complex results.
Popular Posts:
- None Found
