authorized_keys es el archivo de OpenSSH que lista las claves públicas autorizadas para entrar en una cuenta. Para que sshd lo acepte, ~/.ssh debe tener permisos 700 y authorized_keys 600, sin escritura para grupo ni otros. Cada línea admite opciones como from=, command= y no-pty, que limitan desde dónde y para qué se usa la clave.
Permisos de authorized_keys: 700 en ~/.ssh y 600 en el archivo
sshd ignora authorized_keys si el directorio ~/.ssh o el propio archivo tienen permisos más abiertos de lo esperado: 700 para ~/.ssh y 600 para authorized_keys y para las claves privadas. Lo comprueba la directiva StrictModes de sshd_config, activa por defecto, que además revisa que el directorio home no sea escribible por grupo u otros.
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keysCuando algo falla, el registro del servidor lo dice sin rodeos: busca líneas como Authentication refused: bad ownership or modes. En Debian y Ubuntu se consultan con journalctl -u ssh; en otras distribuciones el servicio se llama sshd. Desactivar StrictModes para salir del paso es mala idea: oculta el problema y permite que otro usuario con escritura en tu home cuele su propia clave.
Opciones de authorized_keys: from=, command= y no-pty con ejemplo
Cada línea de authorized_keys sigue el formato [opciones] tipo clave comentario, con las opciones separadas por comas, sin espacios y delante del tipo de clave. La lista completa está en la sección AUTHORIZED_KEYS del manual oficial de sshd.
from="203.0.113.0/24,198.51.100.7",no-pty,no-port-forwarding ssh-ed25519 AAAAC3Nza... admin@movil
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3Nza... backup@nas
restrict,pty ssh-ed25519 AAAAC3Nza... soporte@portatil- from="patrones": solo acepta la clave si el cliente llega desde esas direcciones o nombres. Admite comodines, notación CIDR y negación con
!. - command="…": fuerza ese comando, pida lo que pida el cliente. Lo solicitado queda en la variable
SSH_ORIGINAL_COMMANDpor si el script quiere validarlo. - no-pty: no asigna terminal. Útil para claves de rsync, copias o despliegues.
- no-port-forwarding, no-agent-forwarding, no-X11-forwarding: cortan cada tipo de reenvío por separado.
- restrict: desactiva todo lo anterior de golpe; después se reactiva lo necesario, por ejemplo con
pty.
Combinar command= con restrict es el patrón habitual para claves de copias de seguridad: aunque alguien robe la clave, solo puede ejecutar ese script. from= añade una segunda barrera, pero un móvil con datos rara vez tiene IP de origen fija. En ese caso compensa entrar por una red privada en malla como Prialo o Tailscale y limitar from= a las direcciones de esa red.
5 errores habituales en authorized_keys y cómo detectarlos
El primer diagnóstico es siempre ssh -v usuario@servidor: muestra qué claves ofrece el cliente y en qué punto las rechaza el servidor.
- Permisos o propietario incorrectos. Copiar el archivo como root lo deja con dueño root y sshd lo descarta. Se arregla con el bloque de chmod y chown anterior.
- Clave partida en varias líneas. Pegar desde un editor que ajusta el texto rompe la clave. Cada clave ocupa exactamente una línea.
- Opciones con espacios o comillas sin cerrar. Un espacio tras una coma o una comilla abierta invalida la línea entera; sshd la ignora sin avisar al cliente.
- Clave RSA rechazada por el algoritmo. Desde OpenSSH 8.8 la firma
ssh-rsacon SHA-1 está desactivada por defecto, y clientes antiguos dejan de entrar. La salida es migrar a Ed25519, admitida desde OpenSSH 6.5. - command= que rompe Mosh, SFTP o scp. Mosh arranca
mosh-servermediante una conexión SSH inicial y SFTP pide su subsistema; un command= fijo sustituye ambos. Desde OpenSSH 9.0 scp usa SFTP por defecto, así que también falla. Usa claves distintas para sesiones interactivas y para automatización.
authorized_keys desde iOS y Android frente al escritorio
La clave privada puede generarse en el propio móvil y guardarse en el almacén seguro del sistema, de modo que en el servidor solo hay que añadir la línea pública a authorized_keys.
| Tarea | iOS/Android con termi1 | Escritorio con OpenSSH |
|---|---|---|
| Generar la clave | En el móvil; queda en el almacén seguro | ssh-keygen -t ed25519 |
| Instalar la clave pública | Pegarla en authorized_keys o emparejar un Mac con Companion | ssh-copy-id usuario@servidor |
| Revisar el archivo | SFTP integrado sin salir de la sesión | Editor local o cliente sftp |
| Editar con vim o nano | Teclado propio con Esc, Ctrl, Tab y flechas | Teclado físico |
| Corte de red a mitad de tarea | Mosh y tmux mantienen la sesión | La sesión SSH se corta |
En la terminal SSH y Mosh termi1 la clave privada no sale del dispositivo ni llega a servidores de Sinergia, y termi1 Companion (macOS 14 o posterior) instala la clave pública en el Mac con un código de seis cifras. Si pides a la IA «arregla los permisos de ssh», escribe chmod 600 ~/.ssh/authorized_keys en el prompt sin pulsar Intro; en conexiones etiquetadas como producción, Production Guard retiene lo que cambia algo. La terminal es gratis y funciona sin cuenta; está en termi1 en la App Store y en Google Play.
Preguntas frecuentes
¿Qué permisos debe tener authorized_keys?
authorized_keys debe tener permisos 600, lectura y escritura solo para su propietario, y el directorio ~/.ssh permisos 700. Con StrictModes activo, que es el valor por defecto, sshd ignora el archivo si grupo u otros pueden escribir en él, en ~/.ssh o en el directorio home.
¿Para qué sirve command= en authorized_keys?
command= en authorized_keys fuerza un comando concreto cada vez que alguien se autentica con esa clave, pida lo que pida el cliente. El comando solicitado queda en la variable SSH_ORIGINAL_COMMAND. Se usa en copias de seguridad y despliegues, combinado con restrict o no-pty.
¿Por qué SSH sigue pidiendo contraseña si ya añadí mi clave?
SSH pide contraseña cuando sshd no acepta ninguna clave de authorized_keys. Las causas más comunes son permisos demasiado abiertos, propietario incorrecto, una clave partida en varias líneas o una opción mal escrita. ssh -v en el cliente y el registro de sshd en el servidor señalan cuál es.
¿Funciona Mosh con una clave restringida en authorized_keys?
Mosh funciona con claves restringidas siempre que no lleven command=, porque arranca mosh-server a través de una conexión SSH inicial. Después la sesión viaja por UDP, por defecto en los puertos 60000-61000, que deben estar abiertos en el cortafuegos del servidor.