Re: disabled account accepting publickey authentication

From: Brian Whitehead (brian@whiteheadconsulting.com)
Date: 01/07/03 

From: brian@whiteheadconsulting.com (Brian Whitehead)
Date: 7 Jan 2003 11:04:05 -0800

Todd Knarr <tknarr@silverglass.org> wrote in message news:<ZbvS9.97216$oy5.5046963@news2.west.cox.net>...
> In comp.security.ssh <655aab98.0301062120.484edbe0@posting.google.com> Brian Whitehead <brian@whiteheadconsulting.com> wrote:
> > Second, this is a poor implementation on the part of the distributions
> > that are expecting you to use this listfile module, but don't set it
> > up in the PAM configuration by default. BTW, RedHat by default
>
> What _other_ way would they do it? A system-wide deny file would be a bad
> choice for places that want to allow access _only_ via SSH (if you added
> someone to the deny file to block their using standard login mechanisms,
> you'd lock them out of SSH too.

Agreed.

> Service-specific deny files would be a
> problem for admins trying to lock someone out completely.

My point exactly. This is what you would have to do with using
pam_listfile for every service. There really needs to be a compromise
between the two so sysadmins don't have to edit several files just to
lock someone out of a system.

>The solution seems
> obvious to me: let the admin configure things the way they need them to work
> by (on RedHat) editing the PAM configuration (which is covered in the user's
> manual last time I looked, maybe not the exact steps needed for this task
> but if you're adminning a Unix system you're expected to be able to add
> "authentication is handled through PAM" and "PAM documentation is located
> _here_ on the system" and come up with "I need to read the documentation to
> learn exactly what to do" (it took me about 5 minutes to figure out how to
> do something similar the first time I sat down with a RedHat system, it
> can't be rocket science)).
>

No it's not rocket science. In fact Redhat is probably the easiest
system in world to admin, but if it's not documented how would someone
know about it. I only by chanced happened on the fact that ssh
ignores the fact that an account is disabled. If other admins don't
know about it, that means that all someone would have to do is setup
publickey authentication on a server before their fired and unless the
admin is reading the log files and seeing that someone is logging in
with that account via publickey, that person will never be locked out.
 I totally agree that a sysadmin should be able configure a system the
way they need, but if there are multiple ways to authenticate with a
service, then there are multiple ways that those need to be disabled.
Therefore, these should be documented so that the sysadmin knows.
Again, what do sysadmins do on unices that don't support PAM?

> > Finally, this is not at all documented either via OpenSSH, PAM, etc..
> > So, who's to say that this is an expected 'feature'. Generally, when
>
> Well, if something doesn't use the password mechanism, why _should_ you
> expect it to check bits of the password mechanism?
>
> I suspect it's partly a bad choice of description. "Lock out a user" in
> moduser terms doesn't mean to lock the user out of the system, just to set
> their password to something that can never match anything they type. Their
> cron jobs will still run, because those don't go through password
> checking. rsh from a host listed in the .rhosts or hosts.equiv file will
> still get them in, because it doesn't go through password checking. ssh
> using public-key authentication should be expected to continue to work too,
> because it likewise doesn't go through password checking.

Again, agreed. But again, if there is another way to authenticate
then the system should also provide another method of disabling that
method, either by preconfiguring PAM or by simply documenting it in
the README or man pages. By your own example cron has provided the
cron.allow/deny files and rsh has the files you mentioned above. This
type of method would be fine if it was provided with the system or
documented, although again this means editing yet another file to lock
someone out. I'm not trying to beat a dead horse, I just want people
to understand this is a tremendous risk if others don't know about it.

Relevant Pages

  • Re: Transaction problem (delete / select)
    ... It is not a bug. ... lock or a page lock during the delete. ... you are expecting SQL Server to look at data that will all be ...
    (microsoft.public.sqlserver.server)
  • Re: disabled account accepting publickey authentication
    ... > that are expecting you to use this listfile module, ... > up in the PAM configuration by default. ... A system-wide deny file would be a bad ... problem for admins trying to lock someone out completely. ...
    (comp.security.ssh)
  • Re: Dont be too happy, yet.
    ... don't be too critical when he screws up, and don't be too happy when ... I haven't seen anyone suggest that he's a lock yet. ... last night's game can't be taken as conclusive evidence of his arrival, ... That was expecting too much. ...
    (alt.sports.basketball.nba.la-lakers)
  • Re: singleton ienumerable, need to add more...
    ... the lock should probably be around the .Copycode; ... folders while an admin pushes the "update" button, ... correctly, i.e. if you have the read lock, it prevents the admin lock ... I must admin I wasn't entire clear about your dotted parent suggestion ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Permissions (seperate area?)
    ... lock the sys admin out and encrypt the data? ... need an area that only this one guy can control and no one else. ... You can't permanetly lock out the admins. ... the admin can not examine or alter it. ...
    (microsoft.public.windows.server.sbs)