On Thu, Apr 17, 2025 at 11:08:08PM -0600, Liam Stitt wrote:
This minor speedbump aside, I have attached the 'bt' output from gdb.
Ugh, I didn't realize your password would show up in the backtrace!
Sorry about that - please change it as soon as possible.
That said, the backtrace is definitely useful, but inconclusive. It
shows that the crash is nominally inside pam_ecryptfs, but the asprintf
call that's crashing looks fine to me, and the backtrace shows that its
arguments are valid. Therefore I think we must be dealing with action
at a distance from some previous memory corruption, which is going to be
a pain to track down. It might be in openssh-server, and the timing
suggests that it probably is; but it might also be in any other PAM
module used in the auth phase.
My next best plan is to try valgrind, which is usually good at spotting
these kinds of memory corruption errors. Setting this up is a little
involved in this case, but not too bad. Here are instructions I've
tested in a container:
* install the valgrind package
* as root, create /usr/local/bin/sshd-session-valgrind with the
following contents:
#! /bin/sh
exec valgrind /usr/lib/openssh/sshd-session "$@"
* sudo chmod +x /usr/local/bin/sshd-session-valgrind
* as root, create /etc/ssh/sshd_config.d/valgrind.conf with the
following contents:
SshdSessionPath /usr/local/bin/sshd-session-valgrind
* sudo systemctl restart ssh.service
Now try logging in again until you hit a crash, and then look in "sudo
journalctl -u ssh.service | less" for the output of valgrind; each
instance of its output will start with a line saying "Memcheck, a memory
error detector", and each line will have "==PID==" in it for some
process ID. I don't think the output is likely to include your password
this time, but it will probably be worth checking it over just in case.
Separately, it might also be helpful for me to have a copy of your
/etc/pam.d/common-auth file, so I can see which other modules are being
run in this phase. My guess is that this probably won't help me, but
it's easy to capture and it stands some chance of letting me reproduce
this locally, which would be a big help.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
