El formato
# Deploy key, added for the release job
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINH9eelf0P7eT5ue6SualUXFrh1c9p3Maaem93iZtC2Q you@laptop
from="203.0.113.10",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINxDNsPpUAbI52nc1OduztL+ backup-jobUna línea se lee de izquierda a derecha:
- Opciones, opcionales. Separadas por comas, sin espacios salvo que estén entre comillas dobles.
- Tipo de clave, como
ssh-ed25519ossh-rsa. - La clave, una cadena larga en base64.
- Un comentario, opcional. Es solo para ti.
Se ignoran las líneas en blanco y las que empiezan por #. Una línea sin sentido se salta, y las siguientes siguen funcionando.
Estos errores te cuestan la clave en silencio, y solo ves Permission denied:
- Una clave partida en dos líneas, normalmente por pegarla en un editor que ajusta el texto. Cada clave debe ir en una sola línea.
- Una clave sin su tipo al principio.
- Un espacio después de una coma en las opciones, como en
from="203.0.113.10", restrict.
¿Necesitas una clave para ponerla ahí? Consulta cómo generar una clave SSH Ed25519.
Opciones útiles
| Opción | Efecto |
|---|---|
restrict | Desactiva el reenvío de puertos, de agente y de X11, los terminales y ~/.ssh/rc. |
command="..." | Ejecuta este comando sea cual sea el que pidió el cliente. |
from="..." | El inicio de sesión debe venir de una de estas direcciones o nombres. Funcionan CIDR y patrones. |
permitopen="host:port" | Limita ssh -L a este destino. |
expiry-time="20991231" | La clave deja de funcionar después de esta fecha. |
cert-authority | La línea es una autoridad certificadora, no una clave de usuario. Consulta certificados SSH. |
verify-required | Para claves FIDO: cada firma debe incluir un PIN o una comprobación similar. |
Para ejemplos prácticos, consulta cómo restringir una clave a un solo comando.
Permisos
Los ajustes seguros, ejecutados como el usuario en el servidor:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysSi los creaste como root, corrige también el propietario:
sudo chown -R user:user /home/user/.sshEsto es lo que pasó en nuestras pruebas y lo que dijo el log del servidor:
| Ajuste | Resultado |
|---|---|
authorized_keys con modo 600 o 644 | Funciona |
authorized_keys con modo 666 | Rechazado: Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys |
~/.ssh con modo 700 o 755 | Funciona |
~/.ssh con modo 777 | Rechazado: Authentication refused: bad ownership or modes for directory /home/user/.ssh |
| Archivo propiedad de root, modo 644 | Funciona, porque el usuario puede leerlo |
| Archivo propiedad de root, modo 600 | Rechazado: Could not open user 'user' authorized keys '/home/user/.ssh/authorized_keys': Permission denied |
La comprobación se llama StrictModes y está activada por defecto. Déjala activada. Un directorio personal con modo 775 pasó en nuestro Debian, donde el grupo contiene solo a ese usuario, pero es un cambio de Debian, así que otros sistemas pueden rechazarlo. El cliente solo ve Permission denied, así que lee siempre el log del servidor. Consulta cómo depurar una conexión SSH.
Qué línea gana
Cuando una clave aparece más de una vez, sshd lee de arriba abajo y usa la primera línea que deja pasar el inicio de sesión. Solo se aplican las opciones de esa línea. De ahí salen dos resultados que conviene conocer:
- Una línea simple por encima de una restringida la anula. Si la clave aparece primero sin opciones y después con
command="...", el inicio de sesión recibe una sesión normal, sin restricciones. - Una línea cuya condición falla no detiene la búsqueda. Si la primera línea tiene un
from=que no coincide, o unexpiry-timeya pasado, la siguiente línea con la misma clave aún puede dejar pasar el inicio de sesión. Para cortar el acceso de una clave, borra todas sus líneas.
Cambiar dónde está el archivo
El ajuste del servidor AuthorizedKeysFile indica dónde buscar. Consulta el valor actual con:
sudo sshd -T | grep -i authorizedkeysfileEl valor por defecto es .ssh/authorized_keys .ssh/authorized_keys2, así que una clave en un authorized_keys2 olvidado también funciona. Busca uno cuando quites accesos.
Un cambio habitual es guardar los archivos fuera de los directorios personales, donde solo root puede editarlos:
# /etc/ssh/sshd_config.d/10-keys.conf
AuthorizedKeysFile /etc/ssh/authorized_keys/%u%u es el nombre de usuario y %h el directorio personal. Las rutas relativas parten del directorio personal. Cada usuario debe poder leer su propio archivo, por ejemplo con modo 644 y root como propietario. Crea esos archivos antes de recargar sshd y mantén una sesión abierta mientras pruebas.
Para obtener las claves de otro sitio, como un servicio de directorio, usa AuthorizedKeysCommand. Consulta sshd_config(5).
Ver qué hay en el archivo
ssh-keygen -lf ~/.ssh/authorized_keysEsto muestra una huella para cada clave. En una línea con opciones, el texto de las opciones aparece donde esperarías el comentario, por ejemplo 256 SHA256:NxFS... restrict,command="/usr/local/bin/ssh-allow" (ED25519). La huella sigue siendo correcta.
Preguntas
¿Dónde está el archivo authorized_keys?
Por defecto en ~/.ssh/authorized_keys, en el directorio personal de la cuenta con la que entras. El ajuste AuthorizedKeysFile del servidor puede indicar otra ruta; compruébalo con sudo sshd -T | grep -i authorizedkeysfile.
¿Hay que reiniciar sshd después de editar authorized_keys?
No. sshd lee el archivo en cada inicio de sesión, así que el cambio vale desde la siguiente conexión.
¿Por qué SSH sigue pidiendo contraseña después de añadir mi clave?
Normalmente los permisos son demasiado abiertos, la clave está partida en dos líneas o acabó en la cuenta equivocada. El log del servidor indica el motivo; el cliente solo muestra la petición de contraseña o Permission denied.