Installed openssh-server on debian stable. As soon as i update the
package to latest version (it is reported for the other version as
i cannot login if the package is not at that version) login becomes impossible with the error

Oct 17 20:11:34 nl-01 sshd[25206]: Accepted password for root from IP port 44676 ssh2
Oct 17 20:11:34 nl-01 sshd[25206]: pam_loginuid(sshd:session): set_loginuid failed
Oct 17 20:11:34 nl-01 sshd[25206]: pam_unix(sshd:session): session opened for user root by (uid=0)
Oct 17 20:11:34 nl-01 sshd[25206]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session
Oct 17 20:11:34 nl-01 sshd[25206]: Received disconnect from IP: 11: disconnected by user

session required pam_loginuid.so

found 726661 1:6.4p1-2
thanks

Hi,

Current version on testing is also affected.

I hit this bug after upgrading a machine. After rebooting it I was unable to login again.

On /var/log/auth.log was the following error:
sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session

The machine is configured with PAM/LDAP.

Downgrading openssh-server to the version on stable (1:6.0p1-4) fixed the problem.

Unfortunately I haven't successfully reproduced this yet ...
failed" is also in the log, as per the first message in this bug report?

Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: Accepted publickey for root from 192.168.0.121 port 37267 ssh2: DSA 1a:f2:16:e1:71:43:62:b6:13:af:91:67:e6:f0:59:8a
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: pam_loginuid(sshd:session): set_loginuid failed
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: pam_unix(sshd:session): session opened for user root by (uid=0)
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: Received disconnect from 192.168.0.121: 11: disconnected by user


Is also worth telling that not only login as root was failing,
but also login as any other normal user via PAM/LDAP:

Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ip121.dynamic.igalia.com  user=clopez
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: Accepted password for clopez from 192.168.0.121 port 37262 ssh2
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_loginuid(sshd:session): set_loginuid failed
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_unix(sshd:session): session opened for user clopez by (uid=0)
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10413]: Received disconnect from 192.168.0.121: 11: disconnected by user


I didn't tried with a local normal (not-root) user,
but I can give it a try if you think is worth.

Hi.

Would you care commenting on how this helps, and what the side effects could be ?

FWIW, I'm experiencing a similar issue inside a docker container running sid, adapted from phusion/baseimage-docker, and even though the workaround helps, I'm concerned of the impact.

Also, maybe #711289 is relevant to this issue, but it's a bit cryptic to me for the moment.

Thanks in advance.

Best regards,

On Mon, Mar 24, 2014 at 11:06 AM, Olivier Berger <olivier.berger@telecom-sudparis.eu> wrote:
correct loginuid associated with them.

The problem is that loginuid once set can't be changed, and any
attempt to do so (eg by pam_loginuid.so writing to
/proc/self/loginuid) will fail.  In sshd's case this can be if you run
(or restart) it from the command line.

Here's the links from my notes last time around:
http://www.linux-pam.org/Linux-PAM-html/sag-pam_loginuid.html
https://www.cendio.com/bugzilla/show_bug.cgi?id=4634
https://bugzilla.redhat.com/show_bug.cgi?id=959418

pam_loginuid.so would try to write to /proc/self/loginuid
unconditionally. If you're not actually trying to switch loginuids,
https://fedorahosted.org/linux-pam/ticket/23 prevents unnecessary
failures in this case by skipping the write if it's already what you
want.

Confirming that this bug is still open: I freshly installed Debian testing
"Jessie" with only SSH Server from tasksel and I was not able to login using
root, although it is possible to do so in Wheezy.
Didn't work. (In fact I reverted all changes to /etc/pam.d/ssh after seeing
that next step was successful)
problem.
This was the helping hint, thank you very much! Additionally, root login must
be enabled. After all, all that should be needed to downgrade and enable:

echo "deb http://ftp.de.debian.org/debian/ wheezy main" >>
/etc/apt/sources.list
apt-get update
apt-get remove openssh-server
apt-get install openssh-server=1:6.0p1-4 openssh-client=1:6.0p1-4
sed -i "s/^PermitRootLogin without-password/PermitRootLogin yes/"
/etc/ssh/sshd_config
/etc/init.d/ssh restart

Hope these steps help saving time the next one googling for "debian jessie
enable root ssh" to workaround this bug ;)

Thank you Paul, indeed it helped me, as I too ran into this issue in a
fresh Jessie install. I didn't have to downgrade OpenSSH, however, just
edit PermitRootLogin as you did.

I found after the fact that this change is documented in openssh-
server/README.Debian.gz, under the "PermitRootLogin" header. It was
confusing enough to find that the sshd configuration was the issue, when
/var/log/auth.log suggested pam_unix was at fault:

    Apr 25 17:36:55 linux-image sshd[1573]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2  user=root
    Apr 25 17:36:57 linux-image sshd[1573]: Failed password for root from 10.0.2.2 port 35103 ssh2
    Apr 25 17:37:01 linux-image sshd[1573]: Failed password for root from 10.0.2.2 port 35103 ssh2
    Apr 25 17:37:05 linux-image sshd[1573]: Failed password for root from 10.0.2.2 port 35103 ssh2
    Apr 25 17:37:05 linux-image sshd[1573]: Connection closed by 10.0.2.2 [preauth]
    Apr 25 17:37:05 linux-image sshd[1573]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2  user=root

Anyway, the change comes from Debian bug #298138, which lay dormant for
over nine years before being wrapped up this past March.

Am 25.04.2014 23:50, schrieb Daniel Richard G.:

Hi Daniel,

thank you very much for finding the solution to my issue!
Would be indeed nice if the installer would ask if root access should be
enabled or not.

Best regards,
Paul

All,

So am I right to conclude that this bug actually concerns the change that
changes PermitRootLogin to without-password?

I think changing this default makes sense from a security perspective as it
provides the best compromise between securing a default install versus the
desire to log in as root directly.

However, I recognise that there are people that are using password-based root
login who may be surprised by this change. The proper solution therefore may
be to add a NEWS.Debian entry so everyone is informed about this change, and a
release notes item at that. If those are added, this bug could be closed.

Colin, what do you think?


Cheers,
Thijs

I believe that's the real issue, yes.

I won't argue that, but I don't see anything in openssh-server's package
scripts addressing the case of a system with a root user + password but
no regular user (i.e. root is the only login available). That's a valid
outcome of debian-installer, and a typical scenario for me when creating
a Linux VM image, and is how I ended up posting here.

Is there anything that can be done about the unhelpful auth.log
messages? Package documentation is good, and the permit-root-login
debconf question also helps there, but a user who is trying to diagnose
the issue via syslog could use better hints as to what's going on.

Am Samstag, 27. September 2014, 10:06:39 schrieb Daniel Richard G.:

[...]

I didn't complain about PermitRootLogin (although this seems to be the bug's
cause), my issue is that I am *not able to login as root*. Even notes in
NEWS.Debian wouldn't let me login as root. If not changing would mean that it
is still needed to patch the system.
Digging down to manuals/config files is quite uncomfortable.

IMHO it remains best practice of the installer to ask for enable/disable as
usual (with default to "no", but I KNOW HOW TO ANSWER....).
I would be really happy to still have the choice from the installer (this does
not reduce security of a default installation).

I think there are two separate issues here, both with the symptom
"can't log in over ssh as root"; if the maintainer agrees with my
analysis, this bug should probably be cloned.

First one (suggested title: "pam_loginuid(sshd:session): set_loginuid failed"):
sysvinit as pid 1, and has been restarted in the context of the sysadmin's
login session, either by the upgrade itself or by explicit sysadmin action.
This means sshd already has a loginuid set, so its child processes are not
allowed to set a different loginuid for the ssh login session.

systemd as pid 1 would be unaffected by this, because it always starts
services as a direct child of pid 1, never a child of the login session
that requested the service start; Upstart as pid 1 would probably
be unaffected for the same reason.

Second issue, which I think is separate (possible title: "forbidding root
password login by default is awkward for systems with only root user"):
[...]

I'm not sure that this second issue is release-critical, or even a bug,
although I agree it's annoying for virtual machines. It's certainly
a reasonable feature request.

openssh-server already has a debconf question for this, but it's only
used in upgrades, not new installations.

I don't think the installer should ask this at normal priority, because
the more questions the installer asks, the less user-friendly it is;
but it might make sense to default to "PermitRootLogin yes" if no non-system
uids exist, or ask at a low priority for the "expert" installer mode,
or at least make it pre-seedable.

    S

Control: clone 726661 -2
Control: retitle 726661 login fails with pam_loginuid(sshd:session): set_loginuid failed
Control: retitle -2 forbidding root password login by default is awkward with only root user
Control: found 726661 1:6.2p2-2
Control: notfound -2 1:6.2p2-6
Control: notfound -2 1:6.4p1-2
Control: found -2 1:6.6p1-1

Nobody seems to have disagreed with my analysis, so I'm doing that, an an
attempt to clarify what's going on. I've set the "found" and "notfound"
versions according to the changelog, which says pam_loginuid was enabled
in version 1:6.2p2-2 but PermitRootLogin was only changed in 1:6.6p1-1.

OpenSSH maintainers, please feel free to re-merge these bugs if you think
I'm wrong.

Anyone else, please reply to #726661 if discussing pam_loginuid or
the new clone (bug number to be determined) if discussing PermitRootLogin.

Thanks,
    S

Control: retitle 769388 'PermitRootLogin without-password' in new installations breaks some use cases

Bug#769388 is the new cloned bug, discussing PermitRootLogin.

Summarizing, the situation here is:

* Debian 7 (wheezy) and older had "PermitRootLogin yes" by default.

* New installations of Debian 8 (jessie)'s openssh-server have
 "PermitRootLogin without-password" by default. This means root can log in
  with a public key or similar mechanism, but root cannot log in with a
  password. This is a deliberate change to improve security by avoiding
  brute-force attacks on root's password, requested in
  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138>;
  after all, the root account always exists with that username,
  and allows accessing any user account's data, so it's a very attractive
  target for brute-force attacks.

* Upgrading openssh-server from Debian 7's version to Debian 8's version
  uses debconf to ask whether to update the configuration, as far as
  I can see.

* However, new installations of Debian 8 do not ask which configuration
  to use; they use the new one (PermitRootLogin without-password)
  unconditionally.

Concrete effects reported in this bug:

* People who were used to the old configuration find the behaviour of new
  installations of jessie confusing. A NEWS.Debian entry would not help here,
  because new installations don't show NEWS.Debian; an entry in the
  jessie release notes would be more appropriate.

* Daniel Richard G. reports that this breaks his process for installing
  Linux VM images, in which the image ends up with only a root user,
  so there is no less-privileged user who can su to root.

I understand the request to have debian-installer ask which configuration
to use, and I have some sympathy for that; I've been doing a bit of
installer testing in disposable VMs recently, and it's annoying to have to
log in once at the (emulated) console to switch to "PermitRootLogin yes".
However, I do think maintainers are right to err on the side of asking the
minimum feasible number of questions in the installer.

Another possibility would be to use a low-priority question that is
only shown in the "expert" installer, but can be pre-seeded.

It is already possible to put something like this on the kernel command line
when booting the installer, which might be useful:

    preseed/late_command="in-target sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config"

If you are producing VM images that are designed to be cloned repeatedly,
to make those VM images secure and correct, you already need a
post-processing step to do things like deleting the ssh host key,
setting a new unique systemd/D-Bus machine ID and so on; it seems
sensible to extend that post-processing step for jessie to enable
root login with a password, or to enable SSH public-key
authentication for root by putting a specific key in
/root/.ssh/authorized_keys.

Regards,
    S

Hi,

Thanks for the summary.

CC'ing debian-boot as I suspect the "easiest" solution will involve
documentation this in the installation-guide.

Please also keep in mind that such questions need to be translated.

I am not certain on the policy for d-i for having pre-seedable
configuration without an "expert" question.  If this is not an issue for
d-i, I suppose it could be added solely in the openssh-server-udeb package.

If we are going down this route, then let us have it documented in the
installation-guide.  If needed be, we can add a reference from the
release notes to the relevant part of the installation guide (or maybe
just a remark about it).
  Though note that the release-notes only handles upgrades between the
(soon-to-be) previous and the (soon-to-be) current release, so I firmly
believe it should be documented in the installation-guide to ensure it
is a stand-alone document.

Assuming no objections to this, let us have this reassigned to the
installation-guide package.

Simon McVittie also wrote:

For reference, it is also documented in the release-notes (including how
to preseed the question).

~Niels

Isn't this also a documentation issue?  A section could be added to
the release notes on how to preseed a user for this type of
installation use case?

Anyway, I think both problems can be solved with more information in
the release notes, so maybe reassign there?

Best wishes,
Mike

Control: reassign 769388 release-notes
Control: severity 769388 normal

Yes, I think so. #726661 is a technical issue, not a documentation issue
like #769388, but they were initially treated as a single bug because
the symptom described in the original title ("Does not permit login as
root") could be caused by either.

Makes sense to me.

    S

Control: tags 769388 moreinfo

Hi,

I am a bit confused as to why you reassigned this to release-notes, when
the remaining issue seems to be related to the debian-installer (which
has its own documentation package called "installation-guide").

For the record, the /upgrade/ variant of this issue /is already/
documented in the release notes (and has been so for at least 2 weeks).

Did you mean to reassign this to the installation-guide?

Thanks,
~Niels

Niels Thykier <niels@thykier.net> (2015-01-16):

Preseedable configuration is way lighter than (expert or not) questions,
since it's only about an extra key/value to handle in scripts, and
there's no need for translations. We have many of those, and we could
support an extra one without too much hassle.

At first glance, having this question asked in expert mode wouldn't seem
too crazy. I'm a bit worried about the timing though; this should have
been noticed and worked on way earlier (this change happened in March).

Nice try. :) That udeb is here to provide ssh support during the
installation process, it doesn't quite control what's happening in the
system getting installed.
something specific to be preseeded, and document it when it's done.

By the way: You wrote about the need for translations above, that applies to
the installation guide as well.

Mraw,
KiBi.

Ok, sounds good. :)

Sadly, we have had tons of issues in Debian, we ought to have discovered
months ago. :-/

Ok, where would something like this go then?  I tried checking out the
d-i source and I am yet to figure out the place where "random"
preseedable/expert questions go.

Is this case basically "shove the debconf selections into the target
system and let the regular .deb packages deal with it"?  If so, it seems
that openssh "mostly" already permits this to be preseeded:


"""
  if dpkg --compare-versions "$2" lt-nl 1:6.6p1-1 && \
     [ "$(get_config_option PermitRootLogin)" = yes ] &&
     db_get openssh-server/permit-root-login && [ "$RET" = true ]; then
        set_config_option PermitRootLogin without-password
  fi
"""

(I suspect it just needs a little fiddling with the --compare-versions)

True - I assumed that the installation-guide was as easy to update on
the website as the release-notes.

I am ready to look into writing a patch for d-i to provide this to be
preseedable.  I am presume it needs to be "documented somewhere" in d-i
(either as an expert question, in the installation-manual or in the
standard preseed-example file).  I do not mind doing it as an expert
question as well assuming we still have time for getting translations.

Thanks,
~Niels

Niels Thykier <niels@thykier.net> (2015-01-27):

...

I've added this issue on my list of things to keep track for RC2. I
should be able to try and deal with sorting out which package to patch,
so that you can concentrate on other release-y things.

Mraw,
KiBi.

Hi,

We are sorry that we were not able to handle your contribution or
suggestion for changes to the release-notes. I am going over old bugs
and I am closing all the items that were suggested for the release-notes
of Debian releases before stretch. On the good side, some even appear to
have been applied, without the bug being closed.

Please don't hesitate to open a new bug if you think your suggestion is
still valuable for the release-notes of buster. If you do that, we'd
appreciate it when you try to summarize the issue properly when the
closed bug was more than a couple of messages.

Paul