Tras actualizar el sistema operativo de un sistema Linux e intentar acceder por SSH te puedes encontrar con el mensaje Server refused our key. Averigüemos qué sucede para resolverlo.
El mensaje tras intentar acceder con clave pública puede ser parecido al siguiente:
Using username "ubuntu".
Server refused our key
ubuntu@192.168.0.153's password:
El sistema está rechazando la autentificación con nuestra clave pública que hasta ahora funcionaba. No hay cambios de configuración o estos no deberían afectar. Incluso las configuraciones por defecto aceptan la autentificación por clave pública, de modo que si el sistema encontró una versión personalizada del sshd_config, preguntó y elegiste dejar el archivo de configuración que se proporciona con el paquete, debería estar funcionando.
Entonces… ¿Qué pasa?
Las exigencias para las claves SSH han aumentado, de modo que openssh ya no acepta claves en SHA-1, que son las clasificadas como ssh-rsa.
Soluciones.
Crear e instalar nuevos pares de claves con algoritmos más actualizados es una opción, que requeriría luego actualizar la clave pública en todos los lugares a los que acceder.
Otra opción es configurar que se acepten de nuevo las claves RSA bajo SHA-1 en el servidor.
Para ello, editamos el archivo /etc/ssh/sshd_config y agregamos lo siguiente:
PubkeyAcceptedKeyTypes +ssh-rsa
Con esto, le estamos indicando que acepte claves ssh-rsa, solo falta hacer que relea la configuración y probarlo:
sudo systemctl reload sshd
¿Cómo acceder para configurar las nuevas claves o el archivo de configuración?
Si no podemos acceder por mostrarse el error Server refused our key, podemos intentar llegar al servidor de otros modos:
- Con contraseña, si no está expresamente deshabilitado el acceso con contraseñas.
- Desde otro usuario que tenga claves diferentes y soportadas.
- Desde algún panel de control que esté instalado, como podría ser Webmin.
- Desde consola, si la hay, bien remota o física al equipo.
- Directamente a la unidad de almacenamiento del equipo afectado extrayéndola físicamente si no va encriptada y conectándola en otro equipo.
¿Y si ni así podemos acceder?
Todavía queda un cartucho que va a salvar la situación. El cliente SSH puede utilizar el mismo par de claves que se usaban con protocolo SHA-2, sin cambiar nada en el servidor, ni la clave pública ni la privada.
Esto lo puede hacer, por ejemplo, FileZilla, de forma automática.
Bajo Windows, para usar PuTTY, utilizando PuTTYgen se puede regenerar el archivo .ppk con la clave lista para usar en RSA SHA-2 (ahora denominado tan solo RSA en el interface).
Abrimos PuTTYgen (PuTTY Key Generator), de la versión 0.75 o superior. Confirmado que con la 0.76 funciona, mientras que con la 0.74 no.
Pulsando en File >Load private Key, seleccionamos la clave privada, probablemente denominada id_rsa. Puede requerir Seleccionar «All Files (*.*)» para ver ese archivo y no solamente los * .ppk.
Ya nos va avisando para que tras importarla, hay que grabarla antes de poderla usar, lo que generará el .ppk actualizado.
Grabamos el nuevo archivo .ppk que contendrá la clave privada.
Si no hemos indicado contraseña de acceso a la clave privada porque no la deseamos, pulsamos Sí.
Al remplazar el antiguo .ppk por el nuevo recién creado, PuTTY conectará con el nuevo y sin tener que cambiar nada en el servidor.