How to restrict each SSH user to logon from their respected trusted host or IP only.

In my opinion, the best way to do it would be to use OpenVPN, instead. (But you can do a similar thing with ssh.)

Only one host possesses the necessary unique digital certificate that opens the lock. It doesn't matter what IP-address he's coming in from.

IP-address checks ("whitelisting") are, IMHO, never an adequate part of network security.

I can think of several ways, all would be custom work and not standard use of the tools. OpenSSH and the security tools have many advances that I have not yet examined: there may be an answer in the standard tools. I would research that in the man and info pages first, then google for more.

I am not sure about the point, perhaps you could explain a little.

Do you need to only prevent them from getting a shell, or close off things like sftp also?

I take it that the clients are in a limited network, are there already some restrictions there that we might take into account?

That can be done in the keys, specifically the known_hosts authorized_keys file, but only if the users don't have write access to their known_hosts over on the server. You'd have to put the known_hosts authorized_keys files for each user into a special directory. The permissions would then be set so that each user could read their key but not write it. For example, something like /etc/ssh/known_hosts/%u /etc/ssh/authorized_keys/%u might work. See the manual page for sshd_config(5) in the part about AuthorizedKeysFile.

Perhaps the easier way to maintain would be to put in a lot of Match clauses in sshd_config - one per user - allowing specific users in from specific IP addresses, but banning everyone otherwise. You'd need to start with letting in the administrative users first. See sshd_config(5) in the part about Match and ForceCommand or maybe MaxAuthTries.

Edit: managed to write the wrong file name three times

1 members found this post helpful.

Looking at it, MaxAuthTries seems to do the trick. I'd recommend requiring keys as well. Don't lock yourself out.

I don't think that method scales well though.

1 members found this post helpful.

Remember that the keys held by a user are public-keys issued by the server. (The keys can also be cryptographically protected.) But the essential principle behind this security is that each key issued is unique, and accountable to a particular person. If any key is compromised, it can be revoked without affecting other system access.

Nevertheless, in my opinion, the over-arching advantage of VPN over ssh is that the former is transparent to all system users: "connect it and fuhgeddaboudit." Every other piece of software simply perceives that "there is a subnet, and there is a router that gets me there, and that's that." They neither know nor care that the aforesaid connection is secure. They don't have to "do anything special" in order to achieve security. Otherwise, it is very easy to accidentally do something that is not secure, and to not realize it.

Another "plus" is that none of the files relating to this form of security are specific to them. The security applies as a blanket to the entire computer.

You can do the configuration on /etc/host.allow and /etc/host.deny file for IP based restriction to SSH.
SSHD daemon support the tcp_wrapper and can control via /etc/host.allow and /etc/host.deny

Only in version 6.6 and older. In OpenSSH 6.7 and newer, tcpd (tcpwrappers) is not supported. iptables works for restrictions in some general cases, but I think they may not be useful in this particular case.

1 members found this post helpful.

Here ya go

EDIT: Works with 7.2p2 as well, but I have not tested it.

Attached Files

openssh-7.1p1-libwrap.txt (4.1 KB, 31 views)

1 members found this post helpful.

No, I think what he wants is user A form ip address a' only, user B from ip address b' only, etc. That requires fine control that tcp wrappers does not (in my experience) support. Latest versions of OpenSSH, however, do. Maintaining it might be somewhat labor intensive if you have much turnover.

An alternative technique would be to have the server create a reverse secure shell connection to the trusted host that the user can then use to connect.

1 members found this post helpful.

There's a more simpler method. use AllowUsers and AllowGroups - See this thread. OP is requesting simply access or no access by the ip, so match statements aren't needed.

In sshd config file /etc/ssh/sshd_config use this

eg
ranges and wildcards work too

as do multiple specifications

To give all admin access add them to the group admin (or whatever) - whatever being restricted to 192.168.1.10

3 members found this post helpful.

I can now confirm it works on 7.2p2 as well.