Bug#548087: marked as done (openssh-server: if 'PermitRootLogin no' set, PAM should not get auth requests)
Your message dated Wed, 23 Sep 2009 14:44:14 -0700 (PDT)
with message-id <alpine.DEB.1.10.0909231443530.17596@li16-163.members.linode.com>
and subject line Re: Bug#548087: openssh-server: if 'PermitRootLogin no' set, PAM should not get auth requests
has caused the Debian Bug report #548087,
regarding openssh-server: if 'PermitRootLogin no' set, PAM should not get auth requests
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
548087: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548087
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: openssh-server
Version: 1:5.1p1-5
Severity: minor
hedges@li16-163:/etc/ssh$ sudo grep PermitRootLogin sshd_config
PermitRootLogin no
Yet, logwatch report says this:
--------------------- pam_unix Begin ------------------------
cron:
Sessions Opened:
mail: 98 Time(s)
root: 50 Time(s)
Debian-exim: 24 Time(s)
logcheck: 24 Time(s)
sshd:
Authentication Failures:
root (196.201.228.242): 2 Time(s)
It seems like, if PermitRootLogin is set to no, authentication
requests should never be passed to PAM at all once the 'root'
username is sent.
Mark
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.27.4-linode14 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages openssh-server depends on:
ii adduser 3.110 add and remove users and groups
ii debconf [debcon 1.5.24 Debian configuration management sy
ii dpkg 1.14.25 Debian package management system
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libcomerr2 1.41.3-1 common error description library
ii libkrb53 1.6.dfsg.4~beta1-5lenny1 MIT Kerberos runtime libraries
ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f
ii libpam-runtime 1.0.1-5+lenny1 Runtime support for the PAM librar
ii libpam0g 1.0.1-5+lenny1 Pluggable Authentication Modules l
ii libselinux1 2.0.65-5 SELinux shared libraries
ii libssl0.9.8 0.9.8g-15+lenny5 SSL shared libraries
ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii openssh-blackli 0.4.1 list of default blacklisted OpenSS
ii openssh-client 1:5.1p1-5 secure shell client, an rlogin/rsh
ii procps 1:3.2.7-11 /proc file system utilities
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages openssh-server recommends:
pn openssh-blacklist-extra <none> (no description available)
ii xauth 1:1.0.3-2 X authentication utility
Versions of packages openssh-server suggests:
pn molly-guard <none> (no description available)
ii rssh 2.3.2-8 Restricted shell allowing only scp
pn ssh-askpass <none> (no description available)
-- debconf information:
* ssh/vulnerable_host_keys:
ssh/new_config: true
* ssh/use_old_init_script: true
ssh/encrypted_host_key_but_no_keygen:
ssh/disable_cr_auth: false
--- End Message ---
--- Begin Message ---
On Wed, 23 Sep 2009, Russ Allbery wrote:
> Mark Hedges <hedges@scriptdolphin.org> writes:
>
> > It seems like, if PermitRootLogin is set to no, authentication requests
> > should never be passed to PAM at all once the 'root' username is sent.
>
> It turns out that you don't want to do that (or at least that's the
> prevailing security wisdom) because it creates a timing difference that
> the attacker can use to detect the PermitRootLogin setting. ssh
> intentionally runs all attempts through the PAM stack but then always
> rejects them regardless of the outcome of the PAM authentication so that
> the timing is the same as any other login and the attacker can't tell why
> they're failing.
Ah, I get it, sorry to "bug" you. --m--
--- End Message ---
Reply to: