En corto
| |
| |
Y en tu ~/.bashrc o ~/.zshrc:
| |
Cierra sesión y vuelve a entrar. Ahora todas tus shells comparten un solo agente con un socket estable, y no arrancas un ssh-agent nuevo por cada terminal.
El patrón clásico (eval "$(ssh-agent)" en el .bashrc) levanta un agente por shell, deja procesos huérfanos y pierde las llaves entre terminales. Dejar que systemd posea el agente resuelve las tres cosas: un proceso, un socket, un ciclo de vida.
Requisitos
openssh (trae ssh-agent y ssh-add) y una sesión de systemd de usuario (cualquier distro moderna con logind). Verifica:
| |
Si $XDG_RUNTIME_DIR está vacío no tienes una sesión de usuario real (por ejemplo entraste con su); entra por SSH o en consola como tu usuario.
1. Crea el servicio de usuario
Un servicio --user vive en ~/.config/systemd/user/ y corre con tu cuenta, sin root:
| |
%tse expande al runtime dir del usuario ($XDG_RUNTIME_DIR, típicamente/run/user/<uid>), así que el socket queda en/run/user/<uid>/ssh-agent.socket.-afija esa ruta de socket (en vez de una aleatoria en/tmp), que es lo que luego exportamos.-Ddeja el agente en primer plano; es lo correcto paraType=simple.
Si prefieres que aplique a todos los usuarios de la máquina, pon el archivo en
/etc/systemd/user/ssh-agent.service(requiere root). Para tu cuenta,~/.config/systemd/user/es lo más limpio. Elige una ubicación, no las dos.
2. Exporta el socket y carga la llave al entrar
Agrega esto a tu ~/.bashrc o ~/.zshrc:
| |
- El
exporttiene que ir antes delssh-add, o el cliente no sabrá con qué agente hablar. ssh-add -lsale con código 1 si el agente no tiene llaves y 2 si no puede conectarse al socket; elif !cubre ambos casos y (re)carga.-t 1dhace que la llave expire en un día. Quita el-tsi quieres que dure hasta que reinicies el agente.
3. Habilita y verifica
| |
Abre una terminal nueva (o source ~/.bashrc) y comprueba que la llave esté cargada:
| |
Qué mueve cada pieza
| Pieza | Qué hace |
|---|---|
ssh-agent.service (--user) | Mantiene un agente vivo, dueño de systemd |
-a %t/ssh-agent.socket | Socket en una ruta fija y predecible |
SSH_AUTH_SOCK en el rc | Apunta cada shell a ese socket |
ssh-add -t 1d id_ed25519 | Carga la llave al entrar, con caducidad opcional |
Trampas
- Usa el nombre real de tu llave. Muchas guías dicen
id_rsa; las llaves modernas sonid_ed25519. Si el archivo no existe,ssh-addfalla en silencio dentro delif. - Lingering: por defecto el servicio de usuario muere cuando cierras la última sesión. Si necesitas que el agente siga vivo sin login activo (cron, un runner de CI en la máquina), habilita el lingering:
loginctl enable-linger $USER. - El socket debe coincidir. El
-a %t/ssh-agent.socketde la unit y elSSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"del rc apuntan al mismo archivo. Si cambias uno, cambia el otro. &>/dev/nulles de bash/zsh. En un/bin/shestricto (dash) usa>/dev/null 2>&1.- Passphrase: si tu llave tiene passphrase, el
ssh-adddel login te la pedirá una vez por caducidad. Con-t 1d, una vez al día. - No mezcles agentes. Si algún profile hacía
eval "$(ssh-agent)", quítalo; si no, tendrás dos agentes y unSSH_AUTH_SOCKque baila entre ellos.
Ver también
- Hilo original en Server Fault: https://serverfault.com/questions/672346/straight-forward-way-to-run-ssh-agent-and-ssh-add-on-login-via-ssh
- Gist de referencia (magnetikonline): https://gist.github.com/magnetikonline/b6255da90606fe9c5c25d3333c98c90d