How do we allow certain set of Private IPs to enter through SSH login(RSA key pair) into Linux Server?
6 Answers
You can limit which hosts can connect by configuring TCP wrappers or filtering network traffic (firewalling) using iptables. If you want to use different authentication methods depending on the client IP address, configure SSH daemon instead (option 3).
Option 1: Filtering with IPTABLES
Iptables rules are evaluated in order, until first match.
For example, to allow traffic from 192.168.0.0/24 network and otherwise drop the traffic (to port 22). The DROP
rule is not required if your iptables default policy is configured to DROP
.
iptables -A INPUT -p tcp --dport 22 --source 192.168.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
You can add more rules before the drop rule to match more networks/hosts. If you have a lot of networks or host addresses, you should use ipset module. There is also iprange module which allows using any arbitrary range of IP addresses.
Iptables are not persistent across reboots. You need to configure some mechanism to restore iptables on boot.
iptables
apply only to IPv4 traffic. Systems which have ssh listening to IPv6 address the necessary configuration can be done with ip6tables
.
Option 2: Using TCP wrappers
Note: this might not be an option on modern distributions, as support for tcpwrappers was removed from OpenSSH 6.7
You can also configure which hosts can connect using TCP wrappers. With TCP wrappers, in addition to IP addresses you can also use hostnames in rules.
By default, deny all hosts.
/etc/hosts.deny
:
sshd : ALL
Then list allowed hosts in hosts.allow. For example to allow network 192.168.0.0/24 and localhost.
/etc/hosts.allow
:
sshd : 192.168.0.0/24
sshd : 127.0.0.1
sshd : [::1]
Option 3: SSH daemon configuration
You can configure ssh daemon in sshd_config to use different authentication method depending on the client address/hostname. If you only want to block other hosts from connecting, you should use iptables or TCP wrappers instead.
First remove default authentication methods:
PasswordAuthentication no
PubkeyAuthentication no
Then add desired authentication methods after a Match Address
in the end of the file. Placing Match
in the end of the file is important, since all the configuration lines after it are placed inside the conditional block until the next Match
line. For example:
Match Address 127.0.0.*
PubkeyAuthentication yes
Other clients are still able to connect, but logins will fail because there is no available authentication methods.
Match arguments and allowed conditional configuration options are documented in sshd_config man page. Match patterns are documented in ssh_config man page.
-
What about adding a ListenAddress directive in /etc/ssh/sshd_config ?– jeromeNov 27, 2017 at 18:54
-
It is possible in specific situations (for example listening to private network address), depending on your network configuration and which hosts you want to allow.– sebasthNov 27, 2017 at 19:17
-
3Additionally, ,sshd_config can set filterings with AlowUsers directive, and also, the authorized_keys can be set with 'from IP or subnet" to filter also.– toniocJun 11, 2018 at 17:38
-
3Note that
sshd
must be linked againstlibwrap
for TCP wrappers to work (see e.g. here) and that support for tcpwrappers/libwrap was dropped from OpenSSH in v.6.7. On many modern systems Option 2 may no longer work. Sep 19, 2020 at 8:10 -
1
Here some additional configuration for SSH daemon to extend previous answer:
Add user filtering with
AllowUsers
option insshd_config
file:AllowUsers [email protected].* [email protected].* otherid1 otherid2
This allows johndoe and admin2 only from
192.168.1.*
addresses and otherid1, otherid2 from anywhere.Restrict a ssh key or ca-based key to a set of addresses in
.ssh/authorized_keys
file of a given user's home directory:from="192.168.1.*,192.168.2.*" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABA...etc...mnMo7n1DD useralias
In this example, the public key for useralias will be effective only from given addresses.
-
6In my case, white listing in sshd was better than using iptables/ufw. The firewall was unable to keep up with traffic. We only needed to lock down ssh, so adding AllowUsers clause to /etc/ssh/sshd_config was a much lighter weight solution. Otherwise, you have to continuously tune your fire wall. You also have to stress/load test the firewall and it's hard to anticipate real network traffic patterns. May 13, 2020 at 16:20
-
3The second approach is awesome because it is minimal, thank you. Small tip for the others, double quotes are mandatory even in case of single, explicit address. Apr 14, 2022 at 19:46
-
1
AllowUsers
also has the benefit of e.g. restricting SSH logins to a certain IP address but allowing SFTP logins from anywhere, in case you have other team members that need to access that...hosts.allow
or firewalls would restrict both. Jun 1, 2022 at 19:55
If you don't mind installing UFW (Uncomplicated FireWall):
sudo ufw allow from 192.168.1.0/24 to any port 22
Edit: As previous mentioned it's a good practice to only authenticate using keys instead of passwords which can be done by editing /etc/ssh/sshd_config
:
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
-
-
-
-
In
/etc/ssh/sshd_config
, setPasswordAuthentication
,ChallengeResponseAuthentication
andUsePAM
tono
.– MahmoudMay 1, 2020 at 15:01 -
1It's best if you update your answer so that future readers can look for a complete answer to the original question. I like to think about StackExchange sites as a searchable encyclopedia. Each question and answer should try to make the encyclopedia better and easy to get more correct information. May 1, 2020 at 15:14
If you're using SSH CA for client authentication, you can specify the source-address
option when signing certificates:
ssh-keygen -s ca_privkey -O source-address=172.16.0.0/16 id_rsa.pub
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The certificate id_rsa-cert.pub
can be used to log in to hosts only from 172.16.0.0/16
addresses (not even 127.0.0.1
unless you specify that as well).
man 1 ssh-keygen
is a good document if you want more details.
Another way you can limit access to sshd on a GNU/Linux system at the socket level with a built-in (assuming init is systemd 235+ and kernel 4.11+) is by utilizing systemd with cgroup/eBPF access lists
Modify the base sshd systemd stanza
sudo systemctl edit sshd
Append the sshd [Service] stanza to your liking
[Service]
#requires systemd 235+ and kernel 4.11+
IPAccounting=yes
IPAddressDeny=any
IPAddressAllow=192.18.1.22
IPAddressAllow=10.161.0.0/16
IPAddressAllow=100.64.0.0/24
reload for immediate effect
sudo systemctl daemon-reload
-
This isn't per-user, so it won't handle the use case where I want to allow SSH and SFTP from everywhere for webuser1, webuser2, but only SSH/SFTP from 1.2.3.4 (office IP) for root (Assuming each user has their own key and password authentication is disabled). Correct me if I misunderstood. Nov 23 at 16:09
It is possible to restrict a specific user to login in only from specific IP addresses and to specify that only public key will be accepted :
Match user myuser
AllowUsers myuser@mynet1 myuser@mynet2
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
-
1(1) This answer is incomplete. What file are you talking about? (I can guess, but answers shouldn’t require guesswork.) (2) It seems to at least overlap a lot with, and maybe even duplicate, a few previous answers. (3) How does it answer the question? How can the OP restrict logins by source IP address? (I guess you mean for
mynet1
andmynet2
to refer to host IP addresses, but, again, answers shouldn’t require guesswork.) (4) What if the OP can’t, or doesn’t want to, list user names? Can they sayAllowUsers @mynet1 @mynet2
orAllowUsers *@mynet1 *@mynet2
? … (Cont’d) Jul 27, 2022 at 19:15 -
1(Cont’d) … (5) What do the user names on the
AllowUsers
line even mean in this context? (6) Will this even do what the question asks for, or will unspecified users still be allowed to connect from anywhere? … … … … … … … … … … … … … … … … … … … … … … … … … … … … Please do not respond in comments; edit your answer to make it clearer and more complete. Jul 27, 2022 at 19:15 -
Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.– Community BotJul 31, 2022 at 16:26
/etc/ssh/sshd_config