# Limiting who can log in via SSH from an outside network

## randalla

Is it possible to limit who can log into a server via SSH that is from an outside network? For example, I want to allow access to specific users on the system when they are outside our internal network. However, users on the internal network I want to allow in regardless.

The system has a "dumb terminal" type of software on it that we use internally all day, but there are a few external employees and agents that also need to use it. I already have some configuration done to SSH to lock down what users can do (such as disabling portforwarding, etc).

Is what I want to do even possible?

Adam.

----------

## krinn

not really understood what you are trying to do 

allow internal to access sshd, but limiting who from external will access it, can be done with

in /etc/hosts.allow SSHD LOCAL "networkip" (as LOCAL 192.168.0.*) will allow anyone from that local network

and /etc/hosts.deny SSHD: ALL except ipyouwishtoaccessit (as SSHD: ALL except 99.99.99.99, assuming 99.99.99.99 is an allowed ip)

or allowing anyone from internal network but limiting from external:

setup internal account with key but still allow password login but don't give the keyfile to external users = internal will log without password while external still need one

or allowing anyone from internal network but some from external but passwordless

same as previous, just disable password login, and gave keyfile to your external users = anyone can only log if they have the correct keyfile and without any password

----------

## wthrowe

From the sshd_config(5) man page, it looks like the AllowUsers directive can take user@host patterns to restrict login from particular hosts.  I haven't tried it, but maybe something like

```
AllowUsers trusteduser1 trusteduser2 *@192.168.*
```

----------

## randalla

 *wthrowe wrote:*   

> From the sshd_config(5) man page, it looks like the AllowUsers directive can take user@host patterns to restrict login from particular hosts.  I haven't tried it, but maybe something like
> 
> ```
> AllowUsers trusteduser1 trusteduser2 *@192.168.*
> ```
> ...

 

Oh, neat. I hadn't seen that. I was investigating modifying /etc/pam.d/sshd to do something like that. I'll have to see if it's possible to do that with the AllowGroup parameter as well, as that's really where I want to have the access.

Thanks a bunch,

Adam.

----------

## randalla

 *krinn wrote:*   

> not really understood what you are trying to do 
> 
> allow internal to access sshd, but limiting who from external will access it, can be done with
> 
> in /etc/hosts.allow SSHD LOCAL "networkip" (as LOCAL 192.168.0.*) will allow anyone from that local network
> ...

 

I thought I was pretty clear what I wanted to do. I only want certain users to have access to the box from outside the local network, and don't want to restrict anyone on the internal network. What I didn't specify was that I don't want to have to micromanage IPs for users that may be on roaming networks (DHCP, etc). I've used the hosts.allow/hosts.deny trick to truly lock down boxen in the past via SSH, but I can't expect that the users on the outside network would be smart enough to let me know when their IP changes (when they wouldn't know themselves).

So, having SSH, or PAM manage just the specific users is a far better solution in my setup.

----------

## Hu

Perhaps the Match directive would be useful.  You could set certain options based on the source address of the connection.  Unfortunately, AllowUsers is not among them.  One approach that would probably provide most of the desired security would be to configure the server so that external access can only be done via ssh key, but internal access can be by key or by password, at the preference of the client application.  See man sshd_config for details about the Match directive, including a list of what keywords it can guard.

If your authorized external users insist on using a password, you could use the Match block in such a way that they are allowed to do password authentication, but any of the other accounts are restricted to using only keys, so that attackers cannot brute force the accounts of users who ought to be internal only.

----------

