I have two users on my ssh-server machine, user_A and user_B. user_B is permitted to log in with private key only for security reasons, because he needs to log in from remote. All this works. My problem: How do I prevent user_A to login likewise from remote with username/password, because he only needs to login from the local network? According to the man page of sshd, CIDR-notation is allowed.

What I have done:
#605433 suggests AllowUsers [email protected], so I adapted to AllowUsers [email protected]/24

#740700 suggests:

   AllowGroups PrivateSubnetSshUsers

My version looks like

   AllowUsers user_A

Against my expectations, user_A can still log in from in both cases. I had done some systemctl restart sshd before retrying.

What do I overlook here?


3 Answers 3


First, there is error in your Match statement as it should be Match address and not just Match Your version gives an error message when trying to restart sshd. Didn't you get one?

Second, you should Match on user name, not on address. The following should work:

Match user user_A
   AllowUsers [email protected]/24

BTW. From my tests, AllowUsers [email protected]/24 alone (ie. not in Match block) also works (so you must have done something wrong when testing it), but it restricts all other users except user_A from login at all (and user_A can login only from the specified network). If it is within a Match block as above, then user_A can login only from specified network, and all other users can login from any IP address.

  • I had checked sshd restarting in auth.log. No error messages. Now it looks like Match user user_A AllowUsers [email protected]/24 After sshd restart (checked!) user_A can still log in. The does not exist here. Aug 30 16:09:08 Myhost sshd[22781]: Accepted password for user_A from port 36776 ssh2
    – udippel
    Commented Aug 30, 2023 at 14:31
  • I have tested my answer on my server and it works. Do you have any other AllowUsers or AllowGroups directives in your sshd configuration that may conflict with this? And what is your sshd version?
    – raj
    Commented Aug 30, 2023 at 15:25

I am utmost embarrassed. Of course.the case is solved, like raj had correctly indicated. My fault, and therefore embarrassment, was to always edit ssh_config, and not sshd_config. My apologies, and thanks again for your help!


According to the manual (https://www.man7.org/linux/man-pages/man5/sshd_config.5.html), it should work like this:

# Only user_B is allowed to login
AllowUsers user_B

# Only the group PrivateSubnetSshUsers is allowed to login from the network
Match Address
        AllowGroups PrivateSubnetSshUsers 

# user_B is not allowed to login with password
Match User user_B
        PasswordAuthentication no

With the first option you lock out all users except of the user_B. The second option allows a login if you connect from the given network and are member of the group PrivateSubnetSshUsers. The third option force user_B to use keys.

It is not super straight forward, but it should do the job.

  • This is something logically different from what the OP requested. In your example, only the group PrivateSubnetSshUsers is allowed to login from, so noone else is allowed to login from this network - but the group PrivateSubnetSshUsers is allowed to login also from outside that network. The OP wants the group to be able to login only from the specified network and from nowhere else.
    – raj
    Commented Aug 30, 2023 at 11:55
  • Yes, raj, that's not my problem, since I had created user_B without password from the start, so that I didn't have to do the second part of the answer above. My problem is about user_A who can still log in from seemingly anywhere; contrary to what I read from said cited manual.
    – udippel
    Commented Aug 30, 2023 at 13:50
  • OK, I edited the config. Now just user_B can login, but just without password. If you are coming from the internal network also the users from the group PrivateSubnetSshUsers are allowed to login. Hopefully I understand everything right :)
    – ulrich17
    Commented Aug 30, 2023 at 14:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .