Configurar claves SSH sin perder el acceso

Generar e identificar la clave localmente

En un cliente OpenSSH actual, cree una clave dedicada con ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vpseverywhere_admin. Introduzca una frase de contraseña segura cuando se le solicite. El comando crea un archivo privado llamado vpseverywhere_admin y un archivo público llamado vpseverywhere_admin.pub. Si Ed25519 no está disponible debido a restricciones específicas de compatibilidad o políticas, elija una configuración RSA aprobada para ese entorno en lugar de copiar una clave antigua.

Muestre la huella digital de la clave pública con ssh-keygen -lf ~/.ssh/vpseverywhere_admin.pub. Guarde la huella digital en un registro seguro. No imprima ni transmita el archivo privado, y no lo pegue en un campo del panel de control etiquetado como "SSH key" (clave SSH); el campo debe aceptar la clave pública de una sola línea que comienza con ssh-ed25519.

• Utilice una clave independiente para la administración en lugar de una clave compartida por el equipo.
• Proteja el dispositivo local mediante cifrado de disco y actualizaciones.
• Realice copias de seguridad de la clave privada únicamente en un almacenamiento cifrado y con control de acceso.

Instale la clave pública

Cuando el acceso mediante contraseña esté disponible temporalmente, instale la clave pública utilizando ssh-copy-id -i ~/.ssh/vpseverywhere_admin.pub USER@SERVER_IP, sustituyendo ambos marcadores de posición. Alternativamente, añada la línea exacta de la clave pública a través del panel de control de aprovisionamiento del proveedor. Si realiza la edición manualmente en el VPS, el directorio ~/.ssh del usuario de destino debe pertenecer a dicho usuario y, por lo general, tener permisos 700; el archivo authorized_keys debería tener normalmente permisos 600.

Conéctese explícitamente mediante ssh -i ~/.ssh/vpseverywhere_admin USER@SERVER_IP. En la primera conexión, verifique la huella digital (*fingerprint*) de la clave de host del servidor a través de una fuente independiente y fiable antes de aceptarla. Un cambio en la clave de host puede ser legítimo tras una reinstalación, pero también puede indicar una interceptación o que la dirección ahora pertenece a otro servidor.

• Nunca resuelva una advertencia sobre la clave de host eliminando sin más el registro antiguo.
• Utilice una cuenta de administrador con nombre propio (distinta de root) siempre que sea posible.
• Mantenga la clave de cada persona en una línea independiente para facilitar su revocación.

Haga que el uso diario sea fiable

Cree un alias para el cliente SSH local en ~/.ssh/config especificando un nombre de host (*Host*), la dirección real (*HostName*), la cuenta de usuario (*User*) y la ruta de la clave (IdentityFile ~/.ssh/vpseverywhere_admin). Configure el archivo para que solo sea legible por su cuenta, si el sistema operativo así lo requiere. Un agente SSH puede reducir la necesidad de introducir repetidamente la frase de contraseña, pero desbloquee las claves únicamente en dispositivos de confianza y evite reenviar el agente a hosts no fiables.

Para los equipos, aprovisione claves públicas individuales mediante la gestión de configuraciones y elimínelas rápidamente cuando finalice el acceso. No distribuya una clave privada a través de chats o sistemas de tickets. Las claves respaldadas por hardware pueden reforzar las tareas administrativas críticas cuando tanto el cliente como el servidor admiten el tipo elegido.

• Asigne nombres a las claves según el rol y el entorno, sin incluir secretos en ellos.
• Revise las claves autorizadas tras cambios de personal o modificaciones en la automatización.
• Utilice tiempos de vida cortos y controlados para los agentes en estaciones de trabajo compartidas.

Deshabilite los métodos menos seguros solo después de haberlos probado.

Mantenga abierta la sesión actual, inicie una segunda terminal y confirme que la nueva clave permite iniciar sesión y ejecutar el comando administrativo previsto. A continuación, valide cualquier cambio en el servidor SSH con sudo sshd -t antes de ejecutar sudo systemctl reload ssh. La autenticación mediante contraseña y el inicio de sesión directo como root pueden deshabilitarse cuando ningún usuario o proceso automatizado dependa de ellos.

Mantenga un método de recuperación a través de la consola del proveedor y documente el procedimiento para restablecer el acceso. La eliminación de una clave perdida es urgente; perder la única clave funcional sin acceso a la consola provoca una interrupción del servicio.