Primero claves, después contraseñas
La mejor contraseña SSH es la que ya no necesitas. Con una clave, el servidor comprueba una firma y ningún secreto cruza la red, así que quien copie lo que escribes o un servidor falso no consigue nada útil. Crea una clave e instálala en el servidor:
ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10Después pruébala y desactiva el acceso con contraseña en el servidor, como se explica en cómo desactivar el acceso SSH con contraseña. La configuración completa de la clave está en cómo generar una clave SSH Ed25519.
Las contraseñas siguen existiendo por motivos reales: equipos que solo aceptan contraseña, cuentas que no controlas, sudo en el servidor y el primer acceso antes de instalar una clave. Esas son las que hay que guardar bien.
Por qué sshpass -p es mala idea
sshpass escribe una contraseña en ssh por ti. Su forma más común es también la más débil:
sshpass -p 'S3cret!' ssh deploy@203.0.113.10La contraseña forma parte de la línea de comandos. Mientras se ejecuta, cualquier usuario de la máquina puede leerla con ps, y queda guardada en el historial de la shell. Su propio manual dice que -p es la opción menos segura. Las otras dos formas son mejores:
sshpass -f ~/.ssh/web.pass ssh deploy@203.0.113.10
SSHPASS='S3cret!' sshpass -e ssh deploy@203.0.113.10-f lee la primera línea de un archivo, que solo tú debes poder leer (chmod 600). -e lee la variable SSHPASS, que sigue siendo visible para los procesos que se ejecutan con tu usuario. Dos trampas más: sshpass no sabe responder a la pregunta sobre la clave del host, así que en un servidor nuevo falla con el código de salida 6, y mucha gente añade entonces StrictHostKeyChecking=no, que quita la protección contra un servidor falso. Acepta la clave del host una vez a mano.
Guardar contraseñas en el llavero del sistema
En vez de un archivo, deja que el sistema operativo guarde la contraseña. En Mac, guárdala en el llavero de inicio de sesión. Con -w al final y sin valor, el comando pide la contraseña, así que nunca aparece en la línea de comandos:
security add-generic-password -a deploy -s ssh-web -wLéela solo para el comando que la necesita:
SSHPASS="$(security find-generic-password -a deploy -s ssh-web -w)" sshpass -e ssh deploy@webEn escritorios Linux, secret-tool hace lo mismo con el llavero de GNOME o KWallet:
secret-tool store --label='ssh web' service ssh host web user deploy
secret-tool lookup service ssh host web user deployEl llavero se desbloquea al iniciar sesión y guarda la contraseña cifrada en el disco. Cualquier programa que se ejecute con tu usuario puede pedirla igualmente, y por eso la primera respuesta sigue siendo una clave.
Guardar igual las frases de paso de las claves
Una clave debería tener frase de paso, y el llavero puede recordarla para que la escribas una sola vez. En Mac:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519Host *
UseKeychain yes
AddKeysToAgent yesLos detalles, incluido qué pasa tras un reinicio, están en cómo usar ssh-agent con el Llavero de macOS. En Linux, ssh-agent o el llavero del escritorio hacen el mismo papel.
Qué debe hacer un gestor de contraseñas SSH
Un gestor de contraseñas general guarda el secreto. Para SSH importan algunas cosas más:
- Cifrado en tu dispositivo, con una contraseña o el desbloqueo del sistema para abrirlo. Si sincroniza, el servidor solo debe ver datos cifrados. La guía de la bóveda cifrada de extremo a extremo enumera las preguntas que hay que hacer.
- Un acceso para muchos servidores. Un usuario con su contraseña o clave, guardado una vez y vinculado a cada servidor, para que un cambio se haga en un solo sitio.
- Claves y contraseñas juntas, para que un servidor que pasa a clave conserve la misma entrada.
- Escribir solo cuando se pide. La contraseña va al prompt que la pide, no al portapapeles ni a un archivo.
Un gestor de claves SSH con bóveda cifrada reúne estos puntos en un solo lugar, junto a los propios servidores.
Errores que evitar
- Contraseñas en scripts o en un repositorio. Acaban en copias de seguridad, logs y clones de otras personas.
- Contraseñas en el historial de la shell. En bash, define
HISTCONTROL=ignorespacey empieza el comando con un espacio para dejarlo fuera. En zsh, usasetopt HIST_IGNORE_SPACE. - Una sola contraseña de root compartida en un equipo. Da a cada persona una cuenta y una clave, y usa
sudo. - La misma contraseña en todas partes. Una sola filtración abre entonces cada servidor.
- Contraseñas en el portapapeles. Los gestores de portapapeles y los portapapeles sincronizados guardan una copia.
Preguntas
¿Es seguro guardar contraseñas SSH en un gestor de contraseñas?
Sí, si el gestor cifra sus datos en tu dispositivo y pide una contraseña o el desbloqueo del sistema para abrirse. Es mucho más seguro que un archivo de texto, un script o una nota. Una clave sigue siendo mejor que cualquier contraseña guardada.
¿Por qué sshpass -p no es seguro?
La contraseña forma parte de la línea de comandos, así que cualquiera en la máquina puede verla con ps mientras se ejecuta, y acaba en el historial de la shell. sshpass -e o -f evitan las dos cosas.
¿Puedo poner una contraseña SSH en ~/.ssh/config?
No. OpenSSH no tiene opción de contraseña en su archivo de configuración, a propósito. El archivo puede apuntar a una clave con IdentityFile, y la frase de paso de la clave puede estar en el llavero del sistema.
¿Debo usar la misma contraseña en varios servidores?
No. Un servidor comprometido abre entonces todos los demás. Si tienes que usar contraseñas, usa una distinta por servidor y guárdalas en un gestor.
Fuentes
- sshpass(1), manual de Debian
- security(1), manual de macOS
- secret-tool(1), libsecret
- ssh_config(5), manual de OpenBSD
- ssh-keygen(1), manual de OpenBSD