Cómo configurar SSH sin perder el acceso

Para configurar SSH sin quedar fuera del servidor, identifique primero la distribución y el usuario remoto, mantenga abierta la sesión actual, genere la clave en su equipo, copie solo la pública y pruebe una segunda conexión. Endurezca contraseñas o acceso root únicamente después de validar sshd y la recuperación.

El límite operativo es sencillo: no cierre la única puerta que todavía abre. El orden importa más que memorizar comandos. Antes de tocar el servicio, confirme estos puntos:

• Distribución y versión: Ubuntu, Debian y RHEL organizan paquetes, servicio y fragmentos de configuración de forma distinta.
• Usuario remoto: la clave debe autorizarse en la cuenta que realmente utilizará, no en una cuenta elegida por costumbre.
• Acceso actual: conserve la terminal que ya funciona hasta terminar todas las pruebas.
• Recuperación: compruebe que puede abrir la consola del proveedor o un acceso fuera de banda.
• Red: confirme que el cortafuegos del sistema y las reglas de red del proveedor permiten el puerto que ya usa SSH.

Esta guía no cambia el puerto ni desactiva contraseñas en el primer paso. Primero construye una entrada por clave. Después demuestra que funciona. Solo entonces plantea el endurecimiento opcional.

Identifique el sistema, el usuario y el servicio

Ejecute las comprobaciones desde la sesión remota que ya tiene abierta:

cat /etc/os-release
id
printf '%s\n' "$USER"

Anote el identificador de la distribución y el nombre exacto del usuario. La cuenta puede ser distinta de root y también distinta del nombre que usa en su ordenador.

Ubuntu y Debian suelen gestionar el servicio como ssh. RHEL y derivados suelen usar sshd. No recargue ninguno todavía. Primero confirme cuál existe:

systemctl status ssh --no-pager 2>/dev/null || systemctl status sshd --no-pager

Si OpenSSH Server aún no está instalado, use el gestor correspondiente a la distribución. No ejecute ambos bloques.

Ubuntu o Debian:

sudo apt update
sudo apt install openssh-server

RHEL y derivados:

sudo dnf install openssh-server
sudo systemctl enable --now sshd

La instalación puede modificar el estado del servicio. Verifique desde otro equipo que la conexión prevista responde antes de seguir con cambios de autenticación.

Prepare la recuperación antes de cambiar el acceso

Abra el panel de su proveedor y localice la consola web, consola serie o mecanismo equivalente. No basta con saber que el proveedor tiene un panel: compruebe que su cuenta entra, que la recuperación multifactor funciona y que puede identificar el servidor correcto.

En las fichas de Hetzner y DigitalOcean puede partir de la información del proveedor, pero la disponibilidad concreta de consola, rescate y reglas de red depende del producto contratado. Verifíquela en su propio panel.

Revise también dos capas de red:

1. Cortafuegos del sistema: nftables, firewalld, UFW u otra herramienta local.
2. Cortafuegos de la nube: grupo de seguridad, firewall de red o reglas del panel.

No abra puertos adicionales por si acaso. Confirme que el puerto actual está permitido desde su dirección de administración y que la consola seguirá disponible si una regla queda mal.

Mantenga abierta la sesión existente. Esa terminal es su vía de reversión si la nueva clave, los permisos o la configuración fallan. Cerrarla para comprobar la nueva no es valentía; es tirar la salida de emergencia.

Genere la clave en el equipo cliente

La clave privada se crea y permanece en su ordenador. El servidor recibe únicamente la parte pública.

En Linux, macOS o Windows con OpenSSH, genere una clave Ed25519 con un nombre que permita reconocer su destino:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_miservidor

El programa pedirá una frase de paso. Usarla protege la clave privada almacenada; un agente SSH puede evitar escribirla en cada conexión sin eliminar esa protección.

Compruebe qué archivos se han creado y muestre la huella de la pública:

ls -l ~/.ssh/id_ed25519_miservidor ~/.ssh/id_ed25519_miservidor.pub
ssh-keygen -lf ~/.ssh/id_ed25519_miservidor.pub

No copie el archivo sin extensión .pub al servidor. Ese es el secreto privado. Si se filtra, deje de tratarlo como una credencial segura y sustituya el par.

Copie la clave pública al usuario correcto

Mientras la autenticación actual todavía funciona, use ssh-copy-id desde el cliente:

ssh-copy-id -i ~/.ssh/id_ed25519_miservidor.pub usuario@servidor

Sustituya usuario y servidor por los valores que verificó. ssh-copy-id añade la clave pública al archivo authorized_keys de esa cuenta.

En el servidor, revise propietario y permisos desde la misma cuenta remota:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Si los archivos pertenecen a otra cuenta, no aplique un chown a ciegas. Averigüe primero por qué. Un directorio personal montado por red, una política SELinux o una herramienta de aprovisionamiento puede requerir un tratamiento específico.

Pruebe una segunda sesión sin cerrar la primera

Abra otra terminal en el equipo cliente. Fuerce el uso de la clave nueva y pida diagnóstico detallado si falla:

ssh -i ~/.ssh/id_ed25519_miservidor usuario@servidor

Dentro de la segunda sesión, confirme la identidad:

id
hostname

No basta con ver un prompt. Compruebe que entró en el servidor correcto, con el usuario previsto y con capacidad para ejecutar las tareas administrativas que necesitará.

Si la conexión falla, conserve la primera sesión y revise en este orden:

• ruta y nombre de la clave privada en el cliente;
• usuario remoto indicado en el comando;
• contenido y permisos de authorized_keys;
• propietario del directorio personal y de .ssh;
• mensajes del cliente con la opción -v;
• registros del servicio SSH en la distribución;
• reglas del cortafuegos local y de la nube.

No desactive todavía ningún método de acceso. Corrija una sola causa y repita la segunda conexión.

Valide la configuración efectiva de sshd

OpenSSH puede leer el archivo principal y fragmentos adicionales. Ubuntu advierte que un valor definido antes puede prevalecer sobre otro posterior. Por eso conviene revisar la configuración efectiva, no solo una línea aislada.

sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

Antes de cualquier recarga, valide la sintaxis:

sudo sshd -t

El comando correcto no muestra salida y termina sin error. Si informa un problema, no reinicie ni recargue el servicio. Corrija la configuración desde la sesión que sigue abierta y vuelva a validar.

Guarde una copia legible de la configuración principal antes de editarla:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.before-key-auth

En Ubuntu, revise también los fragmentos de /etc/ssh/sshd_config.d. En Debian y RHEL, compruebe si el paquete o la imagen cloud añadió archivos o directivas propias.

Endurezca solo después de superar la prueba

La autenticación por clave puede convivir con la contraseña mientras valida el acceso. Retirar contraseñas o bloquear el inicio directo de root es un cambio posterior, no parte de la copia de la clave.

Antes de aplicar ese cambio, exija todas estas condiciones:

• la segunda sesión entra usando la clave nueva;
• el usuario correcto puede elevar privilegios cuando corresponde;
• sshd -t termina sin errores;
• la consola del proveedor está probada;
• la regla de red actual está documentada;
• otra persona o clave administrativa no quedará inutilizada.

El estado endurecido suele incluir autenticación pública habilitada y, según su modelo de acceso, contraseña o root directo deshabilitados. No copie estas decisiones sin revisar cuentas de automatización, tareas de copia, despliegues y herramientas que aún dependan del método anterior.

Después de editar, ejecute de nuevo:

sudo sshd -t

Solo si la validación pasa, recargue el servicio que corresponde a su distribución.

Ubuntu o Debian:

sudo systemctl reload ssh

RHEL y derivados:

sudo systemctl reload sshd

Mantenga la primera sesión abierta y pruebe una tercera conexión nueva. Confirme que la clave funciona y que el método que pretendía retirar ya no se acepta. Cierre la sesión antigua únicamente cuando esa comprobación haya terminado.

Revierta sin improvisar

Si la nueva conexión deja de funcionar pero conserva la sesión original, restaure la copia, valide y recargue el servicio adecuado:

sudo cp /etc/ssh/sshd_config.before-key-auth /etc/ssh/sshd_config
sudo sshd -t

Después use la orden de recarga propia de Ubuntu, Debian o RHEL mostrada antes. No encadene restauración y recarga en una sola línea: si la copia o la validación falla, necesita ver el error antes de tocar el servicio.

Si ya perdió SSH, use la consola del proveedor. Restaure la configuración, permisos o regla de red desde allí. Un modo de rescate puede montar el sistema de archivos en una ruta distinta; confirme el volumen y el archivo antes de editar. Migrar también cuesta; recuperar a ciegas suele costar más.

Documente la salida. Anote usuario, clave pública autorizada, archivo modificado, servicio recargado, regla de red y procedimiento de consola. Configurar el acceso sin registrar la recuperación solo aplaza el incidente. El servidor es una nave de trabajo: toda escotilla necesita una apertura comprobada desde fuera.

La secuencia segura completa