Entrar por SSH sin contraseña, y con un alias

Hay una rutina que se repite frecuentemente en mi trabajo donde administro varios servidores: abro una terminal, escribo algo como ssh usuario@{direccion}, espero el prompt, escribo la contraseña, y recién ahí puedo comenzar a trabajar.

Este proceso puede ocurrir varias veces en una jornada y puede resultar tedioso, sobre todo si las contraseñas son largas o seguras.

En este artículo vamos a sacarla de en medio en dos pasos. Primero, que SSH deje de pedir la contraseña. Después, que deje de pedirnos la dirección también, y finalmente que alcance con escribir algo como ssh servidor2 para conectarnos sin más.

La contraseña es el problema, no la solución

Hace algunos años escribí sobre cómo proteger los accesos por SSH, y el razonamiento de entonces sigue siendo vigente: la seguridad de un sistema depende de sus usuarios. Pero hay algo que en ese momento no dije, y es que la repetición constante nos lleva a tener la mala costumbre de escribir claves más simples y eso es un verdadero riesgo para nuestros sistemas:

• Tiende a ser corta porque hay que tipearla.
• Tiende a ser memorable porque hay que recordarla.
• Tiende a repetirse porque nadie recuerda veinte contraseñas distintas.

Un par de claves criptográficas no tiene ninguno de esos problemas. Son 256 bits que nunca se escriben, no se pueden adivinar, y además el secreto nunca viaja: el servidor guarda solo la mitad pública, y cuando nos conectamos nos manda un desafío que solo la mitad privada puede firmar. Si alguien intercepta la conversación, no obtiene nada reutilizable. Si alguien roba la base del servidor, tampoco.

Así que esto no es un atajo para vagos. Es más cómodo y más seguro, que es una simple palabra que solo nosotros sepamos.

Una clave NO es una contraseña

Me averguenza admitir que no fui muy joven cuando aprendí que clave y contraseña no son sinónimos, aunque es comprensible que en español ambos términos se utilicen en forma indistinta. En inglés esto no es así. Password y key (o passkey) son claramente cosas diferentes.

Una sola vez: generar el par de claves

El primer paso consiste en generar la clave

ssh-keygen -t ed25519 -C "mi@email"

El comentario que va en -C es solo una etiqueta para reconocer la clave. Después, cuando tengamos varias conviene poner algo que identifique la máquina donde se generó.

ssh-keygen va a preguntar dónde guardarla. Aceptamos el valor por defecto.

Paso siguiente: una frase de paso (passphrase). Sobre eso volvemos enseguida. Cuando termine, en ~/.ssh/ van a haber aparecido dos archivos:

Una vez por servidor: copiar la clave pública

Ahora llega el momento de copiar esa clave que acabamos de generar en los servidores a los que nos queremos conectar. Para ello simplemente tenemos que ejecutar el siguiente comando:

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@{direccion}

Nos va a pedir la contraseña. Es la última vez. A partir de acá, un ssh usuario@{direccion} validará la sesión y entrará directo al prompt.

Qué hizo ssh-copy-id

Para saber qué hizo ssh-copy-id ejecutamos en en servidor:

ssh usuario@{direccion} 'cat ~/.ssh/authorized_keys'

Ahí está nuestra clave pública, una línea completa. authorized_keys es exactamente lo que su nombre indica: la lista de claves a las que ese usuario les abre la puerta. Cada línea es una clave; una por máquina desde la que entramos.

Lo que ssh-copy-id hizo fue crear el directorio ~/.ssh en el servidor si no existía, agregar nuestra línea al final de ese archivo, y dejar los permisos como SSH los exige: 700 para el directorio y 600 para el archivo.

El alias: dejar de escribir la dirección

Ya entramos sin contraseña. Sin embargo, seguimos escribiendo usuario@{direccion}, y si el servidor escucha en otro puerto, también el -p. Todo eso se puede declarar una vez en ~/.ssh/config:

Host servidor2
    HostName {direccion}
    User usuario
    IdentityFile ~/.ssh/id_ed25519

Y con eso alcanza:

ssh servidor2

Si el archivo no existe, lo creamos. Conviene que tenga permisos 600 también, por la misma razón de siempre: SSH lo ignorará.

El nombre después de Host es arbitrario: es el que nosotros queremos usar. Puede haber tantos bloques como servidores, y hay un puñado de opciones que se usan de verdad:

Sobre la última hay que decir algo. ForwardAgent es muy cómodo, pero mientras estemos conectados, quien tenga privilegios de administrador en ese servidor puede usar nuestro agente. En un servidor propio no es problema; en uno compartido, conviene pensarlo dos veces.

Un bloque Host * al final aplica a todos los servidores que no tengan una opción propia. Es el lugar natural para ServerAliveInterval y AddKeysToAgent.

Lo que se gana sin hacer nada más

Acá está la parte que convierte el truco en algo que vale la pena. El alias y la clave no son de ssh: son de todo lo que hable SSH por debajo. Y eso es mucho más de lo que parece.

scp informe.pdf servidor2:~/
rsync -avz ~/proyecto/ servidor2:~/proyecto/
ssh servidor2 'df -h'
git clone servidor2:repos/binarios.git

El scp del que escribí hace años ahora se escribe con seis caracteres de destino en vez de veinte, y no pide contraseña. rsync tampoco. git, cuando el remoto es por SSH, tampoco. Y esa tercera línea —ejecutar un comando y volver— es la que abre la puerta a los scripts: un respaldo nocturno, un despliegue, una comprobación de estado. Nada de eso es posible mientras haya una contraseña que alguien tenga que escribir.

El último paso, cuando estemos seguros

Una vez que entramos con la clave desde todas las máquinas que usamos, podemos hacer lo que en el artículo de 2011 quedó a medias: apagar la autenticación por contraseña del lado del servidor. En /etc/ssh/sshd_config:

PasswordAuthentication no

y reiniciamos el servicio con systemctl restart ssh. Desde ese momento, los intentos de fuerza bruta contra ese servidor dejan de tener sentido: no hay contraseña que adivinar.