# Conexión remota segura con SSH y claves

**Categoría:** Linux y sistemas · **Nivel:** Intermedio · **Lectura:** 12 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/linux/conexion-remota-segura-con-ssh-y-claves/

## Respuesta rápida

**SSH** (*Secure Shell*) es el protocolo estándar para conectarte a un equipo **remoto** de forma **cifrada** y controlarlo desde la terminal como si estuvieras delante. Es la manera habitual de administrar servidores. La conexión básica es ssh usuario@servidor. Podés autenticarte de dos formas: con **contraseña** o con **clave pública**, y la segunda es la recomendada. La autenticación por clave usa un **par**: una clave **privada** que guardás en secreto en tu equipo y una clave **pública** que copiás en el servidor. Al conectarte, ambas se verifican matemáticamente sin que la privada salga nunca de tu máquina. Es **más segura** (no hay contraseña que adivinar o interceptar) y **más cómoda** (no la tecleás cada vez). Se genera con ssh-keygen y se instala en el servidor con ssh-copy-id. La clave privada debe tener [permisos 600](../permisos-y-propietarios-de-archivos-en-linux/index.md). Para **endurecer** el acceso, las medidas clásicas son: desactivar el acceso directo de root, **desactivar la autenticación por contraseña** una vez que las claves funcionan, y limitar quién puede entrar. Así, un servidor solo acepta a quien tenga la clave correcta.

## Qué es SSH

**SSH** abre una sesión de terminal **cifrada** contra un equipo remoto: todo lo que escribís y todo lo que responde viaja protegido, aunque la conexión pase por internet. Reemplazó a protocolos antiguos que enviaban las credenciales en texto plano. Es la herramienta con la que se administra prácticamente cualquier [servidor Linux](../administracion-de-servidores-linux-desde-cero/index.md).

```text
ssh ana@192.168.1.50        # conectarse como "ana" a esa dirección
ssh ana@servidor.ejemplo -p 2222 # en un puerto distinto del 22 por defecto
scp archivo.txt ana@servidor:/ruta/ # copiar un archivo por SSH
```

> **La primera conexión y la huella**
>
> La primera vez que te conectás a un servidor, SSH te muestra su **huella** (*fingerprint*) y pregunta si confiás en él. Esto protege contra suplantaciones: si más adelante la huella cambia sin motivo, SSH avisa de que **algo no cuadra**. Aceptar sin mirar la primera vez es lo normal en una red de confianza, pero conviene entender que ese aviso existe por seguridad.

## Claves vs. contraseña

La **autenticación por clave** usa dos claves que forman un par matemático: lo que una cifra, solo la otra lo verifica. La **privada** es tu secreto y no sale nunca de tu equipo; la **pública** se copia en el servidor. Al conectarte, el servidor comprueba que poseés la privada correspondiente *sin* que esta viaje por la red.

```text
# 1. Generar el par de claves (una vez, en tu equipo)
ssh-keygen -t ed25519 -C "tu-correo o nota"

# 2. Copiar la clave pública al servidor
ssh-copy-id ana@servidor

# 3. A partir de ahí, conectarte normal: ya no pide contraseña
ssh ana@servidor
```

Es **más segura** porque no hay contraseña que adivinar por [fuerza bruta](../../hacking/hydra-para-probar-la-robustez-de-autenticaciones/index.md) ni que interceptar, y **más cómoda** porque no la tecleás cada vez. Opcionalmente, la clave privada puede protegerse con una **frase de paso** local.

## Endurecer el acceso

Una vez que las claves funcionan, conviene **endurecer** la configuración del servidor (en /etc/ssh/sshd_config, reiniciando el servicio después):

- **Desactivar el acceso directo de root.** Que nadie inicie sesión como root por SSH; se entra con un usuario normal y se usa [sudo](../gestion-de-usuarios-y-grupos-en-linux/index.md).
- **Desactivar la autenticación por contraseña.** Una vez que las claves funcionan, apagar la contraseña **elimina de raíz** los ataques de fuerza bruta contra el login.
- **Limitar quién entra.** Permitir solo a los usuarios que de verdad lo necesitan.
- **Considerar cambiar el puerto** o usar un cortafuegos: reduce el ruido de escaneos automáticos (es comodidad, no seguridad real).

> **Atención**
>
> Antes de **desactivar la contraseña** o reiniciar el servicio SSH remoto, comprobá en **otra sesión** que la entrada por clave funciona. Un error de configuración que cierre tu propio acceso a un servidor remoto puede dejarte sin forma de volver a entrar. Cambiá una cosa, verificá que seguís pudiendo conectarte, y recién entonces seguí.

## Errores frecuentes

- **Dejar la clave privada con permisos abiertos.** Debe ser 600; SSH la rechaza si es más laxa.
- **Compartir o subir la clave privada.** Es un secreto; solo se copia la **pública** al servidor.
- **Permitir login de root por SSH.** Un objetivo obvio para la fuerza bruta; desactivarlo.
- **Desactivar la contraseña sin probar la clave.** Podés dejarte fuera; verificar en otra sesión primero.
- **Ignorar el aviso de huella cambiada.** Puede indicar una suplantación; investigar antes de aceptar.
- **Reutilizar una sola clave para todo sin criterio.** Está bien tener claves por contexto; y revocar las que se filtren.
- **Confiar solo en cambiar el puerto.** Ayuda contra el ruido, pero no sustituye a claves y endurecimiento.

## Preguntas frecuentes

**¿Qué es SSH y para qué sirve?**
SSH, cuyas siglas corresponden a Secure Shell, es un protocolo que permite conectarse a un equipo remoto de forma segura y cifrada, y controlarlo desde la línea de comandos como si se estuviera físicamente delante de él. Su uso principal es la administración de servidores a distancia: mediante SSH, un administrador puede acceder a un servidor que puede estar en otra ciudad o en un centro de datos, ejecutar comandos, editar archivos, instalar software y gestionar servicios, todo a través de una conexión protegida. La característica esencial de SSH es que cifra toda la comunicación entre el cliente y el servidor, de modo que aunque el tráfico atraviese redes públicas como internet, nadie que lo intercepte puede leer lo que se escribe ni lo que el servidor responde, incluidas las credenciales. Esto supuso una mejora de seguridad fundamental frente a protocolos antiguos de acceso remoto que transmitían la información, incluidas las contraseñas, en texto plano y sin cifrar, lo que los hacía completamente inseguros. Además de las sesiones de terminal, SSH sirve como base para transferir archivos de forma segura y para crear túneles cifrados que protegen otras conexiones. En el ecosistema Linux, la implementación más extendida es OpenSSH, presente por defecto en prácticamente todas las distribuciones, y saber usar SSH es una habilidad imprescindible para cualquiera que administre sistemas remotos.

**¿Por qué la autenticación por clave es más segura que la contraseña?**
La autenticación por clave pública es más segura que la basada en contraseña por varias razones relacionadas con cómo se demuestra la identidad. En la autenticación por contraseña, el usuario debe conocer y transmitir un secreto que el servidor comprueba, y ese secreto es vulnerable a varios ataques: puede ser adivinado mediante fuerza bruta probando muchas combinaciones, puede ser demasiado débil, puede filtrarse si se reutiliza en otros sitios que sufran una brecha, y expone al servidor a ataques automatizados constantes que prueban credenciales contra el inicio de sesión. En la autenticación por clave, en cambio, se usa un par de claves criptográficas complementarias, una privada y una pública, y la demostración de identidad se realiza mediante una verificación matemática que prueba que el usuario posee la clave privada correspondiente a la clave pública autorizada en el servidor, pero sin que la clave privada llegue a transmitirse nunca por la red. Esto elimina de raíz varios problemas: no hay un secreto que viaje y pueda interceptarse, la clave es extraordinariamente más difícil de adivinar que cualquier contraseña por su longitud y aleatoriedad, y no hay nada que reutilizar en otros servicios. Además, la clave privada puede protegerse localmente con una frase de paso, de modo que aunque alguien robara el archivo de la clave, no podría usarlo sin esa frase. La ventaja definitiva es que, una vez configurada la autenticación por clave, se puede desactivar por completo la autenticación por contraseña en el servidor, lo que anula los ataques de fuerza bruta contra el login.

**¿Cómo genero y copio mis claves SSH?**
El proceso de configurar la autenticación por clave consta de tres pasos sencillos. El primer paso es generar el par de claves en el propio equipo, lo que se hace con la herramienta ssh-keygen, indicando preferiblemente un tipo de clave moderno y robusto. Durante la generación se puede añadir una frase de paso opcional para proteger la clave privada, y el resultado son dos archivos: la clave privada, que se guarda de forma segura y no debe salir nunca del equipo, y la clave pública, que es la que se compartirá con los servidores. El segundo paso es copiar la clave pública al servidor al que se quiere acceder, para lo cual existe la herramienta ssh-copy-id, que se encarga automáticamente de añadir la clave pública al archivo de claves autorizadas del usuario en el servidor, dejando todo listo; si esa herramienta no está disponible, el mismo resultado se puede lograr copiando manualmente el contenido de la clave pública al archivo correspondiente en el servidor. El tercer paso es simplemente conectarse de forma normal con el comando ssh, momento en el que, gracias a que la clave pública ya está autorizada, el acceso se concede mediante la verificación criptográfica sin pedir contraseña. Es importante asegurarse de que la clave privada tenga permisos restrictivos, concretamente accesible solo por su dueño, ya que de lo contrario el propio cliente SSH se negará a usarla por seguridad. Una vez comprobado que la conexión por clave funciona correctamente, se puede proceder a endurecer el servidor desactivando la autenticación por contraseña.

**¿Qué medidas endurecen un servidor SSH?**
Existen varias medidas ampliamente recomendadas para endurecer la seguridad de un servidor SSH, que se configuran en el archivo de configuración del servicio y requieren reiniciarlo para que surtan efecto. La primera y una de las más importantes es desactivar el acceso directo del usuario administrador root por SSH, de modo que nadie pueda iniciar sesión directamente como root; en su lugar, se entra con una cuenta de usuario normal y se elevan privilegios puntualmente mediante sudo, lo que además mejora la trazabilidad. La segunda medida, muy potente, es desactivar por completo la autenticación por contraseña una vez que se ha verificado que la autenticación por clave funciona correctamente, ya que esto elimina de raíz la posibilidad de ataques de fuerza bruta contra el inicio de sesión, que son una de las amenazas más constantes contra los servidores expuestos a internet. La tercera es limitar explícitamente qué usuarios tienen permitido conectarse por SSH, restringiendo el acceso solo a las cuentas que realmente lo necesitan. Otras medidas complementarias incluyen cambiar el puerto por defecto, lo que no aporta seguridad real pero reduce el ruido de los escaneos automáticos, y usar un cortafuegos para limitar desde qué direcciones se acepta la conexión. Una precaución fundamental al aplicar cualquiera de estos cambios en un servidor remoto es verificar, desde una segunda sesión abierta, que el acceso sigue funcionando antes de cerrar la sesión actual, para no correr el riesgo de dejarse fuera del servidor por un error de configuración.

**¿Qué permisos debe tener mi clave privada?**
La clave privada de SSH debe tener permisos muy restrictivos, concretamente el equivalente a lectura y escritura únicamente para su propietario, sin ningún permiso para el grupo ni para el resto de los usuarios, lo que en notación octal corresponde al valor seis cero cero. La razón es que la clave privada es un secreto que otorga acceso a todos los servidores donde esté autorizada la clave pública correspondiente, de manera que si otros usuarios del mismo equipo pudieran leerla, podrían copiarla y suplantar la identidad de su dueño para acceder a esos servidores. Este requisito es tan importante que el propio cliente SSH lo verifica activamente y se niega a usar una clave privada cuyos permisos sean demasiado abiertos, mostrando un error de advertencia, precisamente para evitar que el usuario exponga su secreto por descuido. Del mismo modo, conviene que la carpeta que contiene las claves, que suele ser un directorio oculto de configuración de SSH dentro de la carpeta personal del usuario, tenga también permisos restrictivos que la hagan accesible solo por su propietario. La clave pública, en cambio, no es secreta por naturaleza, ya que su propósito es precisamente distribuirse a los servidores, y por tanto puede tener permisos más abiertos sin ningún riesgo. Este cuidado con los permisos es un ejemplo concreto de cómo el sistema de permisos de archivos de Linux protege directamente la seguridad de las credenciales, y es una de las primeras cosas que hay que revisar si una conexión por clave falla inesperadamente.

**¿Qué es la huella del servidor y por qué me la muestra?**
La huella del servidor, también llamada fingerprint, es una representación corta y única de la clave pública del propio servidor SSH, que sirve para identificarlo de forma inequívoca. Cuando un cliente se conecta por primera vez a un servidor, SSH le muestra esa huella y le pregunta si confía en el servidor y desea continuar, guardando después la huella para futuras conexiones. El propósito de este mecanismo es proteger contra un tipo de ataque en el que alguien se interpone en la comunicación y se hace pasar por el servidor legítimo para interceptar la conexión. Al registrar la huella en la primera conexión y compararla en las siguientes, SSH puede detectar si el servidor al que se conecta ha cambiado su identidad: si en una conexión posterior la huella no coincide con la guardada, SSH muestra una advertencia llamativa avisando de que la identidad del servidor ha cambiado, lo que podría indicar bien un cambio legítimo, como una reinstalación del servidor, bien un intento de suplantación que conviene investigar antes de continuar. En la práctica, en la primera conexión dentro de una red de confianza es habitual aceptar la huella, aunque lo ideal es verificarla por un canal independiente cuando la seguridad es crítica. Lo importante es entender que ese aviso no es un mero trámite, sino una protección real, y que una advertencia de huella cambiada que no tenga una explicación conocida debe tomarse en serio y no ignorarse sin más.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Administración remota y SSH.
2. **Underc0de, foro.** [Sección Redes](https://underc0de.org/foro/redes/). Acceso remoto seguro.

### Documentación oficial

1. **OpenSSH.** [Manual oficial](https://www.openssh.com/manual.html). La implementación de SSH descrita en la guía.
2. **Arch Wiki.** [SSH keys](https://wiki.archlinux.org/title/SSH_keys). Guía práctica de claves.
3. **Arch Wiki.** [OpenSSH](https://wiki.archlinux.org/title/OpenSSH). Configuración y endurecimiento del servidor.
4. **man7.org.** [ssh(1)](https://man7.org/linux/man-pages/man1/ssh.1.html). Página de manual del cliente.

## Guías relacionadas

- [Administración de servidores](../administracion-de-servidores-linux-desde-cero/index.md)
- [Permisos en Linux](../permisos-y-propietarios-de-archivos-en-linux/index.md)
- [Usuarios y grupos](../gestion-de-usuarios-y-grupos-en-linux/index.md)
- [Configurar un servidor web](../configurar-un-servidor-web-en-linux/index.md)
- [Índice de Linux y sistemas](../index.md)