En SSH, una contraseña se presenta como un secreto que el usuario debe recordar y enviar durante el inicio de sesión. Con un par de claves, el cliente demuestra que posee la clave privada sin transmitirla al servidor; este conserva la clave pública autorizada. La diferencia cambia la forma de administrar accesos, no elimina la responsabilidad sobre ellos.
La comparación debe incluir el ciclo completo: creación, distribución, uso, revocación y recuperación. Una clave privada sin protección puede ser tan problemática como una contraseña filtrada.
Dos formas de demostrar identidad
La autenticación por contraseña depende de que el secreto no se reutilice, no se adivine y no se capture en el equipo. Puede ser necesaria como acceso de emergencia, pero los intentos repetidos y el almacenamiento inseguro elevan el riesgo. Los límites de acceso y un segundo factor pueden reducir esa exposición.
Con claves públicas, el servidor guarda una autorización asociada a un usuario y el cliente usa la privada para firmar el intercambio. La privada debe permanecer en el dispositivo autorizado y puede protegerse con una passphrase. El servidor nunca necesita recibirla para verificar la prueba.
La clave privada es un activo operativo
Una clave copiada desde un portátil comprometido permite intentar el acceso allí donde la pública siga autorizada. Proteger el archivo, usar una passphrase, restringir permisos y mantener el dispositivo actualizado son partes del control. Si se sospecha una copia, retira la clave pública de todos los servidores afectados y revisa los registros.
El archivo de autorización también necesita revisión. Una entrada antigua, un usuario que ya no trabaja en el proyecto o una clave instalada en demasiados hosts amplían el alcance de un incidente.
Gestión de ciclo de vida
Asigna una clave a una persona o servicio concreto, documenta su propósito y establece cómo se revoca. Para equipos grandes puede ser útil una autoridad o sistema de gestión que distribuya accesos sin copiar manualmente el mismo archivo a todos los servidores.
En automatización, una cuenta de servicio con permisos limitados debe tener una clave separada de la del administrador. Las tareas programadas no deberían usar una identidad con capacidad de abrir una shell privilegiada si solo necesitan leer o desplegar un recurso.
Contraseñas como excepción controlada
Desactivar contraseñas puede reducir intentos automatizados, pero una política de claves mal gestionada puede dejar al equipo sin acceso de recuperación. Si se mantiene un método alternativo, limita quién puede usarlo, desde dónde y en qué circunstancias. La excepción debe probarse y auditarse.
El acceso inicial también debe verificar la clave del host para evitar conectar a un destino distinto del esperado. Un canal cifrado no garantiza que el usuario se haya conectado al servidor correcto.
Coste y decisión práctica
Las claves suelen encajar mejor cuando hay varios administradores, automatización o necesidad de revocar una identidad sin cambiar un secreto compartido. Las contraseñas pueden resultar más sencillas en una cuenta temporal o en un procedimiento de recuperación bien restringido. La elección depende de la capacidad del equipo para custodiar y revisar cada método.
Qué revisar cuando una clave deja de ser confiable
Revoca la autorización, identifica qué hosts la aceptaban, revisa accesos recientes y crea una nueva pareja en un dispositivo confiable. Cambiar solo la passphrase no basta si el archivo privado ya fue copiado. Las claves mejoran la separación de identidades, pero no sustituyen a los permisos, los registros ni la protección del equipo cliente.
Comparar el coste de administrar identidades
Una contraseña compartida puede parecer sencilla al principio, pero obliga a cambiarla para todas las personas cuando una abandona el proyecto. Las claves individuales permiten retirar una autorización concreta y conservar las demás. Esa ventaja desaparece si todo el equipo usa la misma cuenta o si las claves se copian sin inventario.
Para automatización, crea una identidad de servicio separada y limita sus destinos y comandos cuando el sistema lo permita. Una clave utilizada por un despliegue no debería abrir una sesión administrativa interactiva en todos los servidores.
Revocación, rotación y recuperación
Define dónde se registran las claves autorizadas, quién puede añadirlas y cómo se retiran. La rotación no consiste en crear claves nuevas sin eliminar las antiguas: hay que localizar dependencias, instalar la nueva autorización, probarla y retirar la anterior.
Conserva una vía de recuperación que no dependa de la misma clave. Si el único administrador pierde su dispositivo, el equipo necesita un procedimiento verificado para recuperar acceso sin copiar una clave privada sin control.
Evitar secretos repartidos
Copiar una clave privada a varios equipos simplifica el inicio, pero multiplica los lugares que deben protegerse y revocarse. Una mejor separación asigna identidades por persona o servicio y usa un agente o almacén controlado sin dejar la privada expuesta más tiempo del necesario.
La passphrase protege el archivo si alguien accede al disco, pero no ayuda si una sesión ya iniciada está comprometida. Revisa también quién puede leer el agente, qué duración tienen sus credenciales y cómo se eliminan al terminar una tarea.
Qué debe quedar en el inventario
Un inventario práctico relaciona cada clave pública con su usuario, equipo, servidor, propósito y fecha de revisión. También debe indicar quién puede revocarla. Sin esa información, la ventaja de tener identidades separadas se pierde cuando el equipo cambia o aparece una alerta.