PAM 1.4 / Pambase 20200721 issue

[gangely]

Platform: ARMv7 ODROID-HC1 and -HC2 (image ArchLinuxARM-odroid-xu3)

Problem with remote ssh login: sporadic ssh logins with an sshd going 100% CPU and never letting
you log in.

Already reported 2020-08-22 20:51:23 by abaumann on:
ArchLinux32 BBS: https://bbs.archlinux32.org/viewtopic.p ... 7335#p7335

Solved by downgrading:

pam 1.3.1-2
pambase 20190105.1-2

cracklib-2.9.7-2 was re-installed as dependence of pam 1.3.1-2

Update: the same problem has been reported in the post 'OpenSSH 8.3p1-3 Failed to create session: Input/output error' https://archlinuxarm.org/forum/viewtopic.php?f=15&t=14722

[karog]

I had the exact same problem on an odroid N2 (aarch64), odroid XU4 (armv7), RPi Zero W (armv6), and Pogoplug E02 (armv5) on Aug 19 with the same downgrade fixing the problem for now. I have added pam and pambase to the ignore list until this is fixed.

In addition to the ssh hangs with sshd processes taking 100% cpu, I also run netatalk on the N2 for Mac Time Machine which failed (on login credentials) with the newer pam and pambase when two different Macs tried to badckup. Also solved with the downgrade.

ETA: I failed to note before that the ssh hang did not occur every time but rather I would estimate about half the times I tried ssh. Perhaps there is some kind of race condition.

[maniac]

having the same issue with pam-1.4 and pambase-20200721 (running on cubox-i),
for rsync and borgbackup (socket forwarding via ssh) the sshd process is taking 100%CPU forever.
following errors observed in journal:
pam_systemd(sshd:session): Failed to create session: Input/output error


solved by downgrade: pacman -U ./pam-1.3.1-2-armv7h.pkg.tar.xz ./pambase-20190105.1-2-any.pkg.tar.xz

[keithspg]

Arrgh. This is really annoying. I have no backups, so had to copy/paste from the git commits and build for armv6/armv7/aarch64.
Keith

[sdrik]

No need to downgrade pam and pambase.
The issue is caused by the new pam_systemd_home.so stuff (especially the "-account [success=1 default=ignore] pam_systemd_home.so" line in /etc/pam.d/system-auth).
You can either enable systemd-homed.service or disable pam_systemd_home.so related stuff in /etc/pam.d/system-auth:
$this->bbcode_second_pass_code('', '
#%PAM-1.0

auth required pam_faillock.so preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
auth [success=1 default=ignore] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
auth optional pam_permit.so
auth required pam_env.so
auth required pam_faillock.so authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

account required pam_unix.so
account optional pam_permit.so
account required pam_time.so

password required pam_unix.so try_first_pass nullok shadow
password optional pam_permit.so

session required pam_limits.so
session required pam_unix.so
session optional pam_permit.so
')

[NeilMunday]

Thanks for the info.

For me enabling systemd-homed.service didn't resolve the issue. However, removing pam_systemd_home.so from /etc/pam.d/system-auth seems to have done the trick.

[keithspg]

Thanks for this clarification. I will try this tonight. This 'bug' is extremely challenging and does not seem to affect the 64 bit installs for whatever reason (x86_64, aarch64) but makes logging into armv6/7 almost impossible. A recent update makes the downgrading of pam/pambase cause all passwords to be invalid resulting in no login on my armv7h image.

[keithspg]

The pacman -Syu puts this as /etc/pam/system-auth:
$this->bbcode_second_pass_code('', '#%PAM-1.0

auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
auth       [success=2 default=ignore]  pam_unix.so          try_first_pass nullok
-auth      [success=1 default=ignore]  pam_systemd_home.so
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow
password   optional                    pam_permit.so

session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_permit.so')

I still get non-instantaneous logins. Start putty put in the username then it asks for password and hangs. Then I launch another putty window and try another login and it logs in instantly then the first window finally logs in. Strange.

(Edit) No, it still takes a long time to log in. Previously it would hang indefinitely. Now it hangs for a while then lets me in. Something is not yet quite right.