ssh-agent setzt kein SSH_AUTH_SOCK

[Piktogramm]

ssh-agent setzt die Umgebungsvariable $SSH_AUTH_SOCK nicht. Ohne Umgebungsvariable können keine Passwortmanager/Keystores ssh-keys einbinden. Das Ziel ist aber, dass Kepassxc alle ssh-keys verwaltet.

Alle Programme sind aktuell und in den Bugtrackern ist nichts passendes, ich gehe davon aus, dass es mein Gebastel ist.
Es ist ein Manjaro (Gnome), Kernel 6.12 oder 6.13 (ändert nix am Zustand)

Modifikationen von der Manjaro Standardkonfig:
1. chsh auf zsh -> Ein Rückfall auf die Bash nutzt nix
2. .zshrc erweitert. Zum einen um eine Persistente History über verschiedene Tmux sessions und ein Autojoin/start für tmux. Das ist mein Standard, der so auf all meinen Systemen einfach läuft. Ohne Tmux klappt es dennoch nicht.

# Use powerline
USE_POWERLINE="true"
# Has weird character width
# Example:
#    is not a diamond
HAS_WIDECHARS="false"
# Source manjaro-zsh-configuration
if [[ -e /usr/share/zsh/manjaro-zsh-config ]]; then
  source /usr/share/zsh/manjaro-zsh-config
fi
# Use manjaro zsh prompt
if [[ -e /usr/share/zsh/manjaro-zsh-prompt ]]; then
  source /usr/share/zsh/manjaro-zsh-prompt
fi

# Don't add duplicate lines to history and ignore lines starting with space
HISTCONTROL=ignoreboth

# persistent bash_history over multiple sessions (tmux)
#-n read histoy file
#-w write histoy
#-c prevent trashing histoy
#-r reload history buffer
PROMPT_COMMAND="history -n; history -w; history -c; history -r; $PROMPT_COMMAND"

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=10000
HISTFILESIZE=20000

# enable .bash_aliases
if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# Append to ongoing tmux session or start new, tmux fails savely and does not nest itself
if [[ -z "$TMUX" ]]; then
        tmux attach-session -t 0 || tmux new-session -s 0
fi

Der Witz ist, systemd startet den ssh-agent als daemon im userland problemlos:

systemctl --user status ssh-agent.service                                                                                    ✔
● ssh-agent.service - OpenSSH key agent
     Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-02-09 18:18:47 CET; 8min ago
 Invocation: a21286ca0f24435a9a57103ca6168652
       Docs: man:ssh-agent(1)
             man:ssh-add(1)
             man:ssh(1)
   Main PID: 4881 (ssh-agent)
      Tasks: 1 (limit: 18690)
     Memory: 1M (peak: 1.8M)
        CPU: 11ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service
             └─4881 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket

Feb 09 18:18:47 <hostname> systemd[2141]: Started OpenSSH key agent.
Feb 09 18:18:47 <hostname> ssh-agent[4881]: SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket; export SSH_AUTH_SOCK;
Feb 09 18:18:47 <hostname> ssh-agent[4881]: echo Agent pid 4881;

 

[madmax2010]

ssh-agent setzt die Umgebungsvariable $SSH_AUTH_SOCK nicht. Ohne Umgebungsvariable können keine Passwortmanager/Keystores ssh-keys einbinden. Das Ziel ist aber, dass Kepassxc alle ssh-keys verwaltet.

immer, oder nurin tmux sessions?

ist sie da?:
systemctl --user show-environment | grep SSH_AUTH_SOCK
Falls ja, pack dasal in die zshrc:
export SSH_AUTH_SOCK=$(systemctl --user show-environment | grep -oP '(?<=SSH_AUTH_SOCK=).*')

 

[Piktogramm]

So Test nach Wechsel auf die Bash (Bash startet kein tmux) und Neustart.

Die Umgebungsvariable SSH_AUTH_SOCK ist nicht existent.

############

Derzeitiger Hack, aber keine schöne Lösung. In Keepassxc kann der Socket für ssh-agent manuell eingetraten werden. Wenn Systemd den ssh-agent startet, dann ist das Binding des Sockets /var/run/<userid>/ssh-agent.socket.
Ich hätte es aber gern, wenn es ordentlich funktioniert, dass es die Umgebungsvariablen setzt.

Ergänzung (9. Februar 2025)

Was mich arg wundert ist der Teil hier:

Feb 09 18:18:47 &lt;hostname&gt; systemd[2141]: Started OpenSSH key agent.<br>Feb 09 18:18:47 &lt;hostname&gt; ssh-agent[4881]: SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket; export SSH_AUTH_SOCK;<br>Feb 09 18:18:47 &lt;hostname&gt; ssh-agent[4881]: echo Agent pid 4881;

Der Socket samt bind auf /run/user/1000/ssh-agent.socket funktioniert ja. Zum einen frisst das Keepassxc und wenn ich manuell SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket setze und ein export SSH_AUTH_SOCK ausführe bekomme ich die Umgebungsvariable auch gesetzt.

Nur ist diese Umgebungsvariable nicht für den User sondern immer nur eine für die gerade aktive Instanz der Shell.
Also Variable in einem Panel von Tmux setzen geht, aber schon das nächste Panel weiß nichts davon. Ebenso wie alle anderen Instanzen des User die Variable nicht sehen.

 

[oicfar]

Das

Feb 09 18:18:47 &lt;hostname&gt; ssh-agent[4881]: SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket; export SSH_AUTH_SOCK;

bedeutet das nicht, dass die Variable automatisch in der aktuellen Shell gesetzt wird.

Versuche mit

export SSH_AUTH_SOCK=/run/user/$(id -u)/ssh-agent.socket

in der .zshrc.

 

[Piktogramm]

bedeutet das nicht, dass die Variable automatisch in der aktuellen Shell gesetzt wird.

Naja der Teil export SSH_AUTH_SOCK; sollte die Umgebungsvariable für den betroffenen User setzen. Aber irgendwie setzt mit export $foo wirklich nur Variablen für nur eine Instanz einer Shell. Egal ob Tmux, Bash oder zsh.
Egal wie, das ist ultra nervig und keepassxc ist nur der Fall wo es zu allererst auffällt. :/

Ergänzung (9. Februar 2025)

Eine Variable für eine Shell zu setzen würde ja nur bedeuten foo=bar zu schrieben. Das wäre dann eine Variable in der betroffenen Instanz der Shell. Das export sollte das dann zur Umgebungsvariable "erheben".

Und der Hack das in die .zshrc zu packen bringt recht wenig, keepassxc startet nicht aus der Shell. Zudem das Systemd target für ssh-agent ja eigentlich auch nichts anderes macht als bedingt ssh-agent im Userland zu starten und dann den Pfad für den Socket als Umgebungsvariable bereitzustellen.

Edit: Ok ich bin doof, Umgebungsvariablen gelten für Kinder der Shell und nicht für alle Prozesse. Ich konnte sehr alt werden, ohne dass genau zu begreifen -.-

 

[konkretor]

pack das mal in deine .zshrc rein

export SSH_AUTH_SOCK=$(systemctl --user show-environment | grep SSH_AUTH_SOCK | cut -d= -f2)

sonst schau mal hier rein https://wiki.archlinux.org/title/SSH_keys#Start_ssh-agent_with_systemd_user ob du da was findest.

 

[Piktogramm]

@konkretor
So wie es die Wiki in diesem Absatz beschreibt ist es ja der Standard unter Arch/Manjaro und genau das funktioniert nicht.

Ergänzung (9. Februar 2025)

https://wiki.archlinux.org/title/GNOME/Keyring#Disabling

Ok, gnome Keyring hat wohl einen eigenen wrapper für ssh-agent und gcr-ssh-agent.service sowie .socket überschreiben die Umgebungsvariable.

Das Problem ist, service und socket vom gcr waren sowieso nicht aktiv -.-

 

[Uridium]

Das (user) unit file ist zu niedrig in der Hierarchie (scope). Deine Programme werden nicht davon "geforked". Es gibt quasi keinen vorgeschriebenen Ort für (User-)Variablen. Du musst sie einfach höher ansetzen, z.B. beim Start von x.org (xinitrc, xprofile, etc) oder noch höher in der /etc/environment. Das ist an sich nur ein kosmetisches Konzept, damit die Umgebungsvariablen nicht alles zumüllen. Bei x.org musst Du x neu starten, bei /etc/environment wahrscheinlich den Rechner neu starten (PAM - Pluggable Authentication Module).

 

[Piktogramm]

@Uridium
Der Export der Umgebungsvariable steht jetzt in der ~/.config/environment.d/ssh-agent.conf
Was hässlich redundant ist, weil der Export eigentlich Teil vom ssh-agent,service ist.
Das in die /etc/environment zu hauen wäre unglücklich. Den SSH-Agent für jeden Nutzer einzeln zu starten ist sinnvoll, dass global abzufackeln eher nicht .

Und von der Hierarchie her, ssh-agent.service hat "Wantedby=default.target" gesetzt, wobei default.target ein symlink auf "graphical.target" ist. Wenn ich da nicht (wieder) etwas falsch verstanden habe, müsste das also ausgeführt weden, bevor das DE gestartet wird?!

Zudem ist der ssh-agent.service die Standardlösung vom ssh-agent. Mein Problem müsste VIEL häufiger auftreten, ich sehe aber nur Probleme Anderer Gnomenutzer·innen :/