I have figured how to do this with PAM using listfile but would like to
have a PAM module that returned success if the users is on one of the
private LAN IP ranges(10.x.x.x, 192,168.x.x or the other one which no
one uses).
auth required pam_privatenet.so sense=allow

A more general IP check would also be useful. Success if the user is on
one of the ip ranges listed in a file.
(auth required pam_iplist.so sense=allow file=/etc/ssh/allowedips)

I think that a version of listfile that does this has been written but
does not seem to be in the main PAM stream of development so perhaps a
new listIP PAM module could be created.

I then use the PAM 'jump' action to get what I want from /etc/pam.d/sshd

auth [success=1] pam_listfile.so sense=allow file=/etc/ssh/allowedusers
auth required pam_privatenet.so sense=allow --or-- auth required
pam_iplist.so sense=allow file=/etc/ssh/allowedips
auth required pam_stack.so service=system-auth
auth required pam_nologin.so

In the session section, I set up the menus for the users based on their
usernames. Having it all in one place will make it easier to maintain.

For my part, I would prefer to have 1 place to control access (PAM)
rather than 2 but not everyone is using PAM quite so intensively. I was
not either but am now a bit enthused about what can be done.


Garance A Drosihn wrote:
> At 8:04 AM +1100 3/17/06, Darren Tucker wrote:
>> Ron Wheeler wrote:
>>> I would like to allow ssh access from
>>> 1) anyone on the network
>>> or
>>> 2) anyone on a list of users.

>> An alternative to using pam_listfile (assuming you're using
>> OpenSSH):
>> Put your chosen few users into a group, say, "sshusers" then
>> put the following in sshd_config:
>> AllowGroups sshusers
>> AllowUsers *@192.168.1.*

> That won't work quite the way you want it to. Each category
> is handled as a separate filter, and an incoming connection
> must pass all of those filters to be allowed.
> Here at RPI I have added a new option to openssh called
> UsersLimitedTo
> If it would make the option more attractive for including in the
> distributed version, I'd obviously be happy to change that name.
> This category expects to see any number of userid@hostpattern
> entries. *IFF* a userid matched by any entry in this list, then
> the incoming connection must match one of the hostname-patterns
> that were specified for that userid. If the userid for the
> incoming connection is not matched by any entry in this list,
> then the connection will be allowed by this filter. (It may
> still be blocked by other filters, of course...).
> So let's say you have a userid 'apache', which the whole world
> knows that you have (due to some information-leak which can not
> be avoided). And let's say the same machine has some userids
> which must be able to login from anywhere in the world. You
> would add:
> UsersLimitedTo apache@192.168.1.*
> This option has worked fine in my limited-deployment (it is
> only installed on a few of our public remote-access machines).
> What I haven't done yet is implement a matching option of:
> GroupsLimitedTo
> which would be exactly what would be wanted for the example
> which started this thread.
> The update I have right now is for an older release of OpenSSH,
> but I have been meaning to regenerate it for the latest release,
> along with some other updates that I believe would be good to
> make. This week is probably going to be too busy for me to
> get anything done on that, but once I have some time I would
> be very happy to work on it.