You are not logged in.
Hi everyone
I use keychain for loading SSH keys, and as the ArchWiki writes:
Because Keychain reuses the same ssh-agent process on successive logins, you should not have to enter your passphrase the next time you log in or open a new terminal. You will only be prompted for your passphrase once each time the machine is rebooted.
This was the case right until last reboot, after I've done my every-friday-system-upgrade. Since than I have to enter passwords for SSH keys every time I login.
What changed?
Last edited by Lenry (2020-10-27 13:01:43)
Offline
I would start by exploring the content of pacman.log related to your latest update
Offline
I would start by exploring the content of pacman.log related to your latest update
I don't see anything relevant in todays' log
[2020-10-16T08:29:20+0200] [PACMAN] Running 'pacman --color=always --sync --refresh'
[2020-10-16T08:29:20+0200] [PACMAN] synchronizing package lists
[2020-10-16T08:29:27+0200] [PACMAN] Running 'pacman --color=always --sync --sysupgrade'
[2020-10-16T08:29:27+0200] [PACMAN] starting full system upgrade
[2020-10-16T08:29:28+0200] [ALPM] transaction started
[2020-10-16T08:29:28+0200] [ALPM] upgraded libcap-ng (0.7.11-2 -> 0.8-1)
[2020-10-16T08:29:28+0200] [ALPM] upgraded lua (5.4.0-2 -> 5.4.1-1)
[2020-10-16T08:29:28+0200] [ALPM] transaction completed
[2020-10-16T08:29:28+0200] [ALPM] running '30-systemd-update.hook'...
[2020-10-16T08:29:40+0200] [PACMAN] Running 'pacman --color=always --upgrade /home/lenry/.cache/pikaur/pkg/slack-desktop-4.10.3-1-x86_6>
[2020-10-16T08:29:40+0200] [ALPM] transaction started
[2020-10-16T08:29:40+0200] [ALPM] upgraded slack-desktop (4.10.0-1 -> 4.10.3-1)
[2020-10-16T08:29:40+0200] [ALPM] transaction completed
[2020-10-16T08:29:40+0200] [ALPM] running '30-systemd-update.hook'...
[2020-10-16T08:29:40+0200] [ALPM] running 'update-desktop-database.hook'...
[2020-10-16T16:18:59+0200] [PACMAN] Running 'pacman --color=always --sync --refresh'
[2020-10-16T16:18:59+0200] [PACMAN] synchronizing package lists
[2020-10-16T16:19:02+0200] [PACMAN] Running 'pacman --color=always --sync --sysupgrade'
[2020-10-16T16:19:02+0200] [PACMAN] starting full system upgrade
[2020-10-16T16:19:04+0200] [ALPM] transaction started
[2020-10-16T16:19:04+0200] [ALPM] upgraded binutils (2.35-2 -> 2.35.1-1)
[2020-10-16T16:19:04+0200] [ALPM] upgraded libmm-glib (1.14.2-1 -> 1.14.6-1)
[2020-10-16T16:19:05+0200] [ALPM] upgraded libmspub (0.1.4-7 -> 0.1.4-8)
[2020-10-16T16:19:05+0200] [ALPM] upgraded modemmanager (1.14.2-1 -> 1.14.6-1)
[2020-10-16T16:19:05+0200] [ALPM] upgraded nodejs (14.13.1-1 -> 14.14.0-1)
[2020-10-16T16:19:05+0200] [ALPM] upgraded python-patiencediff (0.2.0-1 -> 0.2.1-1)
[2020-10-16T16:19:05+0200] [ALPM] upgraded soundtouch (2.1.2-2 -> 2.2-1)
[2020-10-16T16:19:05+0200] [ALPM] transaction completed
[2020-10-16T16:19:05+0200] [ALPM] running '30-systemd-daemon-reload.hook'...
[2020-10-16T16:19:05+0200] [ALPM] running '30-systemd-udev-reload.hook'...
[2020-10-16T16:19:05+0200] [ALPM] running '30-systemd-update.hook'...
[2020-10-16T16:19:05+0200] [ALPM] running 'dbus-reload.hook'...
[2020-10-16T16:19:05+0200] [ALPM] running 'gtk-update-icon-cache.hook'...
[2020-10-16T16:19:05+0200] [ALPM] running 'texinfo-install.hook'...
[2020-10-16T17:36:26+0200] [PACMAN] Running 'pacman --color=always --sync --refresh'
[2020-10-16T17:36:26+0200] [PACMAN] synchronizing package lists
[2020-10-16T17:36:28+0200] [PACMAN] Running 'pacman --color=always --sync --sysupgrade'
[2020-10-16T17:36:28+0200] [PACMAN] starting full system upgrade
... or in the last 3 days (since the last reboot, when it still worked as it should)
Offline
Why are you running pacman -Sy followed by pacman -Su. This is not a problem, if you do this right after another, but it can lead to a partial upgrade, if you forget the second sysupgrade command. Also you don't have to run two commands if you just run pacman -Syu instead.
Offline
Why are you running pacman -Sy followed by pacman -Su.
I don't. I use pikaur, pikaur -Syu, to be exact, I guess it's just how it does the upgrading.
Last edited by Lenry (2020-10-16 22:02:12)
Offline
Check journalctl for errors. The ssh-agent probably crashes.
sys2064
Offline
How are you running keychain?
Could be related to the recent openssh update...
Eenie meenie, chili beanie, the spirits are about to speak -- Bullwinkle J. Moose
It's a big club...and you ain't in it -- George Carlin
Registered Linux user #149839
perl -e 'print$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10); '
Offline
The problem is not limited to keychain.
I have been using:
Exec=ssh-agent /usr/bin/startplasma-x11
in:
/usr/share/xsessions/plasma.desktop
It's worked fine up until the last few days, but now when a new terminal window is opened, and I try to ssh, it asks for the certificate password again.
I've worked around the problem, using the systemd user solution in the SSH Keys Wiki.
I note that on my main machine, I was unable to use .pam_environment to set the environmental variable SSH_AUTH_SOCK. This likely has to do with my use of the Gnome keyring in conjunction with kwallet. I tried the Gnome work-arounds suggested in the wiki, but it's not a standard arrangement, and they failed.
In any case, I resolved it by exporting SSH_AUTH_SOCK in my .bash_profile instead of .pam_environment. Then the user systemd service works. My other machines work just fine with .pam_environment. Their kwallet set ups are normal.
Last edited by luser (2020-10-23 01:42:13)
luser: an epithet applied by Windows users to linux users
Offline
I don’t replicate this issue...
Tho I wonder, do anyone with the issue load the keychain files on the interactive shells?
Like:
[ -f "${KEYCHAINDIR:-$XDG_RUNTIME_DIR/keychain}/${HOST:-$(uname -n)}-sh-gpg" ] && . "${KEYCHAINDIR:-$XDG_RUNTIME_DIR/keychain}/${HOST:-$(uname -n)}-sh-gpg"
[ -f "${KEYCHAINDIR:-$XDG_RUNTIME_DIR/keychain}/${HOST:-$(uname -n)}-sh" ] && . "${KEYCHAINDIR:-$XDG_RUNTIME_DIR/keychain}/${HOST:-$(uname -n)}-sh"
?
Note: my shell init is quite nonstandard, in case there’s confusion about anything in the code tags.
It may be that the ssh agent relevant variables are “lost” and unreachable in the interactive shells, thus failing to talk to the agent.
I have noted that ssh-agent spawns the agent files in a “random” directory in tmp, quite unconfigurable, since I wanted it to live inside the user runtime...
*not random, but not static
Offline
I noticed it's not just SSH, a screen session won't stay running if I detach from it then log out.
Offline
The problem was systemd
systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout.
I had to edit /etc/systemd/logind.conf and change
KillUserProcesses=yes
to
KillUserProcesses=no
in order to use it as it was before.
Last edited by Lenry (2020-10-27 13:05:57)
Offline
@lenry
Interesting conclusion, but it doesn't seem to explain why I was having trouble using ssh-agent as a wrapper. My logind.conf file has a modified date of August 7, 2020, but it still has the commented out default of "no" for the value of KillUserProcesses. In any case, starting ssh-agent with systemd user works perfectly so far, and I expect to continue using that method.
luser: an epithet applied by Windows users to linux users
Offline