Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: PAM and SSH (add new options?) |
|---|---|
| Date: | Tue, 21 Mar 2006 12:40:55 -0500 |
Ron Wheeler wrote:I would like to allow ssh access from 1) anyone on the 192.168.1.0/24 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.
-- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Why am I sending the publickey?, Zembower, Kevin |
|---|---|
| Next by Date: | Re: PAM and SSH (add new options?), Ron Wheeler |
| Previous by Thread: | Re: PAM and SSH, Darren Tucker |
| Next by Thread: | Re: PAM and SSH (add new options?), Ron Wheeler |
| Indexes: | [Date] [Thread] [Top] [All Lists] |