SSH: qué es y cómo conectarse a un servidor paso a paso

SSH es la forma estándar de entrar a un servidor a distancia y trabajar en él con órdenes de texto. Esta guía explica qué es, cómo conectar por SSH desde Windows, Linux o macOS y cómo crear claves SSH para entrar sin contraseña. Además, enseña a copiar archivos, a abrir un túnel SSH y a configurar el servidor con OpenSSH.

No la copiamos del manual. Montamos un laboratorio con un portátil, un servidor y un equipo interno, y ejecutamos cada orden. Así aparecieron varias trampas que casi nadie cuenta. Por ejemplo, tras cuatro intentos fallidos el servidor dejó de responder también a la clave correcta durante 21 segundos.

Si nunca ha usado una terminal, empiece por nuestros comandos básicos de Linux. Aquí se da por sabido cómo se escribe una orden.

Qué es SSH y para qué sirve

SSH son las siglas de Secure Shell. Es un protocolo que abre una sesión cifrada entre dos equipos. Lo creó Tatu Ylönen en 1995 para sustituir a Telnet, que enviaba las contraseñas sin cifrar. Desde 2006 está descrito en una serie de normas públicas, las RFC 4250 a 4254.

Hoy sirve, sobre todo, para cuatro trabajos:

• Administrar servidores Linux, equipos de red y máquinas virtuales desde una terminal.
• Copiar archivos entre equipos de forma cifrada.
• Llegar a un servicio interno que no está publicado, a través de un túnel.
• Automatizar tareas: copias, despliegues y revisiones que se ejecutan solas.

Por eso lo usan a diario los administradores de sistemas. Sin embargo, también lo encuentra cualquier usuario que contrate un alojamiento web o instale un NAS.

Cómo funciona SSH, en un minuto

Hay dos programas. En el servidor corre un servicio que escucha en el puerto TCP 22. En su equipo, un cliente se conecta a ese puerto. Primero, los dos acuerdan una clave de cifrado para la sesión. Después, el servidor demuestra quién es con su propia clave. Por último, usted demuestra quién es con una contraseña o con una clave.

A partir de ahí, todo viaja cifrado: lo que escribe, lo que el servidor responde y los archivos que copie.

OpenSSH, PuTTY y los demás programas

El protocolo es uno, pero hay varios programas que lo hablan. El más extendido es OpenSSH, que nació en 1999 dentro del proyecto OpenBSD. Es gratuito, de código abierto y viene instalado en Linux, en macOS y en Windows. Al cierre de esta guía, su última versión era la 10.6, del 6 de octubre de 2026, según la página del proyecto.

PuTTY es un cliente gráfico para Windows, muy popular antes de que Windows incluyera el suyo. Sigue vigente y funciona bien. No obstante, esta guía usa OpenSSH porque las mismas órdenes sirven en los tres sistemas.

Dónde probamos SSH

El laboratorio fueron tres equipos Debian 13.7 en contenedores, con OpenSSH 10.0. Uno hacía de portátil, otro de servidor y el tercero de equipo interno, sin salida a internet. Además, probamos el cliente de un Windows 11 real contra ese mismo servidor.

Es un laboratorio virtual en un solo equipo físico. Por tanto, los tiempos sirven para comparar entre sí, no como cifras de una red real.

Cómo leer los ejemplos

• El servidor se llama srv-01.ejemplo.com y la cuenta con la que se entra, admin.
• El equipo interno, que solo se ve desde el servidor, es 10.0.20.5.
• Las órdenes con sudo se escriben en el servidor. El resto, en su equipo.
• Los ejemplos de Windows se escriben en PowerShell.

Cómo conectar por SSH a un servidor

La orden es la misma en todos los sistemas: el programa, el usuario y el servidor.

ssh admin@srv-01.ejemplo.com

El servidor pide la contraseña de esa cuenta y abre la sesión. Para salir, escriba exit. Si el servicio escucha en otro puerto, añada -p y el número.

Conectar por SSH desde Windows

No hay que instalar nada. Según la documentación de Microsoft, el cliente de OpenSSH está disponible desde Windows 10 versión 1809 y Windows Server 2019. En nuestro Windows 11 venía instalado, en C:\Windows\System32\OpenSSH. Para comprobarlo, abra PowerShell y escriba:

ssh -V
Get-Command ssh | Select-Object Source
Get-Service ssh-agent | Select-Object Status, StartType

En nuestro equipo, la primera línea respondió OpenSSH_for_Windows_9.5p2. La segunda importa más de lo que parece. Si tiene instalado Git para Windows, hay dos clientes en el equipo, y el de Git era el 10.5. Gana el que aparezca antes en la ruta de búsqueda. Más abajo verá por qué esa diferencia de versión cuenta.

La tercera línea adelanta otra sorpresa: el servicio del agente de claves viene deshabilitado.

Conectar por SSH desde Linux y macOS

El cliente viene instalado. Abra una terminal y use la orden del principio. En Debian y Ubuntu, el paquete se llama openssh-client. El del servidor, que no siempre está, es openssh-server.

La primera conexión: la huella del servidor

La primera vez, el cliente muestra una huella y pregunta si confía en ese servidor. No es un trámite. Esa huella identifica al servidor, y aceptarla sin mirar es aceptar a cualquiera que esté en medio.

Para comprobarla, pida a quien administra el servidor que ejecute esta orden y compare el resultado:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Si coincide, responda yes. El cliente guarda la huella en el archivo known_hosts de su carpeta .ssh. Desde entonces, no vuelve a preguntar. En cambio, si un día la huella cambia, se niega a conectar. Lo vemos en la sección de errores.

Ejecutar una orden sin abrir sesión

Si añade una orden al final, el cliente la ejecuta en el servidor, muestra el resultado y vuelve:

ssh admin@srv-01.ejemplo.com 'df -h /'
ssh admin@srv-01.ejemplo.com 'exit 3'; echo $?

La segunda línea enseña un detalle útil para los scripts. El cliente devuelve el código de salida de la orden remota: en la prueba, un 3. Si lo que falla es la conexión, devuelve 255. Así, un script distingue «la orden falló» de «no pude entrar».

Claves SSH: entrar sin contraseña

Una contraseña se puede adivinar, y hay programas que lo intentan sin descanso contra cualquier servidor visible. Las claves SSH resuelven ese problema. Son dos archivos: una clave privada, que se queda en su equipo, y una pública, que se copia al servidor. Quien no tenga la privada no entra, por muchas contraseñas que pruebe.

Crear las claves SSH

ssh-keygen -t ed25519 -C "ana@portatil"

El programa pregunta dónde guardarlas y propone la carpeta .ssh de su usuario. Después pide una frase de paso, que cifra la clave privada. Póngala: si alguien copia el archivo, no podrá usarlo sin ella.

Sobre el tipo, hoy se recomienda Ed25519. De hecho, es el que OpenSSH crea por defecto desde la versión 9.5, y también el de nuestro Windows 11. En el laboratorio, la clave se creó en 5 milisegundos y la parte pública ocupó 94 bytes, una sola línea. Una RSA de 4.096 bits tardó 88 milisegundos y su parte pública ocupó 739 bytes.

Copiar la clave pública al servidor

En Linux y macOS hay una orden para eso. Pide la contraseña por última vez:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@srv-01.ejemplo.com

Conviene indicar siempre el archivo con -i. Sin esa opción, la orden eligió en nuestra prueba la clave pública más reciente de la carpeta, que no era la que usábamos. El resultado fue un «Permission denied» difícil de explicar.

Windows no trae ssh-copy-id. En su carpeta de OpenSSH solo encontramos ssh, scp, sftp, ssh-keygen, ssh-keyscan, ssh-add y ssh-agent. En su lugar, estas dos líneas de PowerShell hacen lo mismo:

scp $env:USERPROFILE\.ssh\id_ed25519.pub admin@srv-01.ejemplo.com:clave.pub
ssh admin@srv-01.ejemplo.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat clave.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && rm clave.pub"

Muchas guías proponen una sola línea, que envía el archivo con Get-Content y una barra vertical. La probamos tres veces y falló dos. La causa la reprodujimos aparte: con la consola en UTF-8, Windows PowerShell 5.1 antepone tres bytes invisibles a lo que canaliza. Como resultado, el servidor guardó la clave y después la rechazó, sin ningún aviso. En cambio, scp copia el archivo byte a byte.

A partir de ahí, el servidor ya no pide contraseña. En el laboratorio, entrar con clave tardó unos 95 milisegundos, y con contraseña, unos 130.

El agente: escribir la frase de paso una sola vez

Una clave con frase de paso la pide en cada conexión. El agente la guarda en memoria mientras dura la sesión de trabajo. En Linux y macOS:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l

En Windows, el agente es un servicio y viene deshabilitado. Microsoft indica estas órdenes, en una ventana de PowerShell abierta como administrador:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

El agente importa también para los scripts. Lo comprobamos: una clave con frase de paso, usada sin agente por un proceso automático, no entra. El cliente no puede preguntar la frase y la conexión termina en «Permission denied».

Cuatro errores con las claves SSH que no avisan

En todos estos casos, el mensaje del cliente es el mismo «Permission denied». La causa solo se ve en el registro del servidor.

• La clave privada es legible por otros. Con permisos 644, el cliente avisó con «UNPROTECTED PRIVATE KEY FILE» y la ignoró. Se arregla con chmod 600.
• La carpeta del servidor admite escritura ajena. Con la carpeta personal o .ssh en 777, el servidor rechazó la clave. En su registro anotó «bad ownership or modes for directory».
• La clave pública se partió al pegarla. Debe ocupar una sola línea. Partida en dos, el servidor la descartó sin anotar el motivo.
• Se copió otra clave. Es el caso de ssh-copy-id sin -i que contamos arriba.

Para el segundo, esta es la corrección en el servidor:

chmod 700 ~ ~/.ssh
chmod 600 ~/.ssh/authorized_keys

El archivo config: un alias para cada servidor

Escribir el usuario, el nombre y el puerto en cada conexión cansa y provoca errores. El cliente lee un archivo, config, en la carpeta .ssh de su usuario. Funciona igual en Windows, Linux y macOS. Este es el que usamos en el laboratorio:

Host srv
    HostName srv-01.ejemplo.com
    User admin

Host intranet
    HostName 10.0.20.5
    User admin
    ProxyJump srv

Host *
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Con él, basta escribir el alias. Además, la opción -G muestra qué valores usará el cliente, sin conectar:

ssh -G intranet | grep -E '^(user|hostname|proxyjump) '
ssh srv hostname

La línea ServerAliveInterval 60 evita un problema frecuente. De fábrica, ese valor es 0: el cliente no envía nada mientras usted no escribe. Por eso, algunos routers y firewalls cortan la sesión tras unos minutos de silencio. Con 60, el cliente manda una señal cada minuto.

En el archivo config gana la primera coincidencia

El cliente lee el archivo de arriba abajo y, para cada opción, se queda con el primer valor que encuentra. Así lo dice el manual, y nos pasó. Añadimos el bloque intranet al final, después de un Host * que fijaba otro usuario. Como resultado, el cliente intentó entrar con ese otro usuario y falló.

Por tanto, la regla es sencilla: los bloques concretos van arriba y Host *, siempre al final.

Reutilizar la conexión

Cada conexión nueva repite la negociación. Si lanza muchas órdenes seguidas contra el mismo servidor, puede dejar una conexión abierta y reutilizarla:

mkdir -p ~/.ssh/cm
ssh -o ControlMaster=auto -o ControlPath=~/.ssh/cm/%r@%h:%p -o ControlPersist=60 srv hostname

En el laboratorio, la primera conexión tardó 146 milisegundos y las cuatro siguientes, entre 12 y 15. Sin esta opción, cada una tardaba entre 111 y 149.

No funciona en el cliente de Windows. Con las mismas opciones, el de Windows 11 respondió «getsockname failed: Not a socket» y no conectó.

Copiar archivos por SSH: scp, sftp y rsync

Tres programas de OpenSSH copian archivos sobre la misma conexión cifrada, con el mismo usuario y la misma clave.

scp informe.pdf srv:/tmp/
scp -r carpeta srv:/tmp/
rsync -a carpeta/ srv:/tmp/carpeta/

El tercero de la familia, sftp srv, abre una sesión interactiva con órdenes como put, get y ls. Es el que usan los programas gráficos, como FileZilla o WinSCP.

Medimos los tres con dos cargas: un archivo de 500 MB y una carpeta con 5.000 archivos de 4 KB.

Prueba	scp	rsync	tar por SSH
Un archivo de 500 MB	1,9 s	2,5 s	No medido
5.000 archivos pequeños, primera copia	8,3 s	0,8 s	0,5 s
Los mismos 5.000, sin cambios	8,0 s	0,2 s	No medido

Con un archivo grande, da igual cuál use. En cambio, con muchos archivos pequeños la diferencia fue de diez a uno. Además, rsync solo envía lo que cambió. Tras modificar un archivo, mandó ese único archivo, 4.103 bytes. scp volvió a copiar los 5.000.

Hay un detalle que conviene saber. Desde OpenSSH 9.0, scp ya no usa su protocolo antiguo, sino el de SFTP. Lo vimos en la traza: «Sending subsystem: sftp». Si un equipo viejo no lo admite, la opción -O recupera el modo anterior.

Windows trae scp y sftp, pero no rsync. Para copias grandes dentro de Windows, vea nuestra guía de Robocopy.

Túnel SSH: llegar a lo que no está publicado

Un túnel SSH lleva una conexión de otro programa por dentro de la sesión cifrada. Sirve para llegar a un servicio interno sin abrirlo a internet. En los ejemplos, ese servicio es una página web en 10.0.20.5, que solo se ve desde el servidor.

Túnel SSH local: un puerto de su equipo hacia dentro

ssh -f -N -L 8080:10.0.20.5:80 srv
curl http://localhost:8080/

La primera línea abre el puerto 8080 en su equipo y lo une con el puerto 80 del equipo interno. La opción -N indica que no hay orden que ejecutar y -f deja el túnel en segundo plano. En la prueba, la página interna respondió en localhost:8080. Sin túnel, la misma petición directa agotó el tiempo de espera.

Ese puerto solo escucha en su propio equipo. Lo comprobamos: quedó abierto en 127.0.0.1 y en ::1, no en la red. Es decir, sus compañeros no pueden usar su túnel.

Salto por un servidor

Si lo que quiere es abrir sesión en el equipo interno, no hace falta un túnel a mano. La opción -J entra al primero y, desde él, al segundo:

ssh -J admin@srv-01.ejemplo.com admin@10.0.20.5 hostname

Es lo que hace ProxyJump en el archivo config de arriba. Con él, ssh intranet basta. El salto añadió unos 40 milisegundos en el laboratorio. Además, también sirve para copiar: scp archivo intranet:/tmp/ funcionó a través del salto.

Su clave privada no sale de su equipo. Tras la prueba, el servidor de salto solo guardaba las claves públicas autorizadas y las huellas conocidas.

Túnel inverso y túnel dinámico

ssh -f -N -R 9090:localhost:8000 srv
ssh -f -N -D 1080 srv
curl --socks5-hostname localhost:1080 http://10.0.20.5/

La primera línea hace el camino contrario: abre el puerto 9090 en el servidor y lo trae al puerto 8000 de su equipo. La segunda convierte la sesión en un proxy. Así, cualquier programa que hable SOCKS sale por el servidor. Las tres funcionaron en la prueba.

Un túnel inverso expone un equipo de dentro hacia fuera. Por eso, en una empresa conviene que nadie lo abra sin que el área de TI lo sepa.

El reenvío del agente, con cuidado

La opción -A presta su agente al servidor mientras dura la sesión. Desde allí puede saltar a otro equipo con su clave, sin copiarla. Lo probamos: sin -A, el servidor no veía ningún agente, y con -A, veía nuestra clave y pudo entrar al equipo interno.

El riesgo está en el propio manual. Quien administre ese servidor puede usar su agente mientras usted esté conectado. Por tanto, para saltar es preferible -J, que no presta nada.

Lo que el servidor puede prohibir

El administrador decide si se permiten túneles, con la opción AllowTcpForwarding. De fábrica vale yes. Al ponerla en no, el túnel local dejó de pasar datos y el cliente respondió «administratively prohibited». También dejó de funcionar el salto con -J, que usa el mismo mecanismo.

Configurar el servidor SSH con OpenSSH

El servicio se configura en /etc/ssh/sshd_config. Esta orden muestra los valores que de verdad aplica, que es lo que cuenta:

sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries) '

Estos fueron los valores de fábrica de Debian 13:

Opción	Valor de fábrica	Qué significa
Port	22	Puerto en el que escucha
PasswordAuthentication	yes	Admite contraseñas
PubkeyAuthentication	yes	Admite claves
PermitRootLogin	prohibit-password	root entra con clave, no con contraseña
MaxAuthTries	6	Intentos por conexión
AllowTcpForwarding	yes	Permite túneles
X11Forwarding	yes	Permite reenviar ventanas gráficas
ClientAliveInterval	0	No comprueba si el cliente sigue ahí

Verificamos la cuarta fila. Con la contraseña correcta, root recibió «Permission denied». Con una clave autorizada, entró.

En sshd_config gana el primer valor

Aquí vale la misma regla que en el cliente, y causa más daño. El archivo de Debian empieza con una línea Include que carga antes todo lo que haya en /etc/ssh/sshd_config.d/. Muchas imágenes de nube dejan ahí un archivo que activa las contraseñas.

Lo reprodujimos. Creamos 50-cloud-init.conf con PasswordAuthentication yes. Después añadimos PasswordAuthentication no al final de sshd_config, como haría cualquiera. La comprobación sshd -t no dio ningún error. Sin embargo, el servidor seguía aceptando contraseñas.

La solución es escribir los cambios en un archivo propio cuyo nombre ordene antes, por ejemplo 10-empresa.conf. Con él, el valor efectivo pasó a no.

Dejar solo las claves

Este es el contenido de /etc/ssh/sshd_config.d/10-empresa.conf que probamos:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers admin

Antes de aplicarlo, confirme que su clave entra. Después, compruebe la sintaxis, recargue el servicio y mire el valor efectivo:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|allowusers) '

En Debian y Ubuntu el servicio se llama ssh. En Red Hat, AlmaLinux y Rocky, sshd.

Comprobar antes de reiniciar

La orden sshd -t es el seguro de vida. Escribimos mal una opción a propósito, PermitRootLogn. La comprobación lo señaló con el archivo y la línea, y devolvió un error.

Luego hicimos lo que no se debe: reiniciar sin comprobar. El servicio no arrancó y las conexiones nuevas recibieron «Connection refused». No obstante, la sesión que ya estaba abierta siguió viva y terminó su trabajo.

De ahí sale la costumbre que salva servidores: al cambiar la configuración, deje una sesión abierta y pruebe la entrada desde otra ventana.

Limitar lo que puede hacer una clave

Cada línea del archivo authorized_keys admite opciones delante de la clave. Son útiles para las claves de procesos automáticos:

restrict,command="/usr/bin/uptime" ssh-ed25519 AAAA... monitor@srv-02
from="203.0.113.10" ssh-ed25519 AAAA... ana@portatil

Con la primera, esa clave solo ejecuta uptime. Lo probamos: pedimos otras órdenes y el servidor respondió siempre con uptime. Tampoco pudo abrir túneles. Con la segunda, la clave solo vale desde esa dirección. Desde otra, el servidor anotó «correct key but not from a permitted host».

Intentos fallidos: el bloqueo por origen de OpenSSH

Desde la versión 9.8, de julio de 2024, OpenSSH castiga por su cuenta a quien falla. La opción se llama PerSourcePenalties y viene activada. Cada fallo de autenticación suma 5 segundos de castigo a la dirección de origen. Cuando la suma llega a 15, el servidor deja de atender a esa dirección durante un tiempo.

Lo medimos, y el resultado tiene dos caras. Lanzamos cuatro intentos seguidos con una clave no autorizada, en un tercio de segundo. El quinto ya no llegó a autenticarse: «Connection reset». Lo importante vino después. La clave correcta tampoco entró. Tardó 21 segundos en volver a hacerlo.

Con contraseñas ocurrió lo mismo. A un intento fallido cada tres segundos, el bloqueo llegó al noveno. En el registro, cada rechazo quedó así: «drop connection … penalty: failed authentication».

Para una empresa, esto tiene tres consecuencias:

• El castigo es por dirección, no por usuario. Si toda la oficina sale a internet con la misma dirección pública, los fallos de una persona bloquean a todas.
• Un servidor de salto concentra los fallos. En nuestra prueba, el equipo interno penalizó al servidor de salto, porque todas las conexiones le llegan desde él.
• Un script mal configurado se bloquea solo, y bloquea a quien comparta su dirección.

La salida es una lista de direcciones exentas. La escribimos en el archivo de configuración propio:

PerSourcePenaltyExemptList 203.0.113.10

Con el portátil en esa lista, seis fallos seguidos no provocaron ningún bloqueo y la clave correcta entró a continuación. El castigo máximo, según el manual del servidor, es de 10 minutos.

Cambiar el puerto de SSH: qué se gana y qué no

Es el consejo más repetido. Lo probamos moviendo el servicio al puerto 2022. Un escaneo completo de los 65.535 puertos lo encontró en 2,2 segundos. Además, identificó el programa y su versión exacta: «OpenSSH 10.0p2 Debian».

Por tanto, cambiar el puerto no esconde nada a quien busque. Lo que sí reduce es el ruido: la mayoría de los intentos automáticos solo prueban el 22, así que el registro queda más limpio. Es una medida de comodidad, no de protección. Lo que protege es quitar las contraseñas y no exponer el servicio.

Errores de SSH más comunes y su causa

Mensaje	Causa más probable	Qué hacer
Connection refused	El servicio no corre o el puerto es otro	Revisar el servicio y el puerto
Connection timed out	Un firewall descarta la conexión	Revisar las reglas y la ruta
Connection reset o closed, sin pedir nada	Bloqueo por intentos fallidos	Esperar o añadir el origen a los exentos
Permission denied (publickey)	Clave no autorizada o permisos abiertos	Mirar el registro del servidor
Host key verification failed	La huella no está guardada o cambió	Comprobar la huella
REMOTE HOST IDENTIFICATION HAS CHANGED	El servidor se reinstaló, o hay alguien en medio	Confirmar el motivo antes de borrar
no matching host key type found	Equipo antiguo que solo ofrece ssh-rsa	Actualizarlo o permitirlo solo para él
administratively prohibited	El servidor no permite túneles	Pedirlo al administrador

Para saber qué pasa de verdad, hay dos fuentes. En el cliente, la opción -v muestra cada paso:

ssh -v srv 2>&1 | grep -E 'Offering|Authenticated|Permission denied|kex: algorithm'

En el servidor, el registro del servicio dice quién entró, quién falló y a quién se bloqueó:

sudo journalctl -u ssh -g "Accepted|Failed|penalty" --since today

Cuando la huella del servidor cambia

Regeneramos las claves del servidor, como ocurre al reinstalarlo. El cliente mostró el aviso «REMOTE HOST IDENTIFICATION HAS CHANGED» y se negó a conectar.

Ese aviso tiene dos explicaciones: una reinstalación o un intento de interceptar la conexión. Por eso, primero confirme con quien administra el servidor que hubo un cambio. Solo entonces, borre la huella antigua:

ssh-keygen -R srv-01.ejemplo.com

En la siguiente conexión, el cliente volverá a preguntar por la huella nueva.

Equipos antiguos y cifrado nuevo en OpenSSH

OpenSSH retira con el tiempo los algoritmos que dejan de ser seguros. Tres cambios recientes explican muchos fallos con equipos viejos:

• La versión 8.8, de 2021, desactivó las firmas RSA con SHA-1, llamadas ssh-rsa.
• La versión 10.0, de 2025, eliminó por completo las claves DSA.
• También desde la 10.0, el acuerdo de claves por defecto es resistente a ordenadores cuánticos.

Reprodujimos el primero con un servicio que solo ofrecía ssh-rsa, como hacen algunos switches y routers antiguos. El cliente respondió «no matching host key type found. Their offer: ssh-rsa». Con esta opción, y solo para ese equipo, la negociación continuó:

ssh -o HostKeyAlgorithms=+ssh-rsa admin@10.0.20.9

Es un parche, no una solución. Lo correcto es actualizar el equipo.

El tercer cambio se nota en Windows. Contra el mismo servidor, el cliente de Windows 11, versión 9.5, acordó curve25519-sha256. El de Git para Windows, versión 10.5, acordó mlkem768x25519-sha256, el algoritmo nuevo. Los dos son seguros hoy. Sin embargo, desde la versión 10.1 el cliente avisa cuando una conexión no usa el nuevo, como explica una nota del proyecto.

SSH en una empresa: buenas prácticas

Lo anterior se resume en pocas reglas, todas probadas en el laboratorio:

1. Entrar con claves y desactivar las contraseñas.
2. Proteger cada clave privada con una frase de paso y usar el agente.
3. No permitir la entrada directa de root.
4. Escribir los cambios en un archivo propio y comprobar con sshd -t antes de recargar.
5. Dejar una sesión abierta mientras se cambia la configuración.
6. Añadir a los exentos las direcciones fijas de la oficina.
7. Dar a cada persona su propia clave, y retirarla cuando deje el equipo.

Falta la más importante: no publicar el puerto de SSH en internet si no hace falta. Es preferible llegar a él a través de una VPN. Explicamos cómo en la guía de WireGuard.

Por último, administrar por SSH no deja constancia de lo que se cambió. Conviene anotar cada intervención en un caso, como hace una mesa de ayuda TI. Para el trabajo diario en el servidor, siga con los comandos avanzados de Linux.

Lo que no probamos

No instalamos el servidor de OpenSSH en Windows, porque habría cambiado el equipo de pruebas. Según Microsoft, desde Windows Server 2025 viene instalado y basta con habilitarlo. Tampoco ejecutamos las órdenes que activan el agente en Windows: son las de su documentación.

Además, no probamos PuTTY, macOS, las claves en llaves físicas, los certificados de SSH ni el segundo factor. La recarga con systemctl no existe en los contenedores del laboratorio. Allí recargamos el servicio a mano y revisamos el registro en un archivo.

Preguntas frecuentes sobre SSH

¿Qué puerto usa SSH?

El 22 de TCP, registrado para este protocolo. El administrador puede cambiarlo. En ese caso, el cliente necesita la opción -p o una línea Port en el archivo config.

¿SSH es gratis?

Sí. OpenSSH se publica con una licencia libre y no tiene ediciones de pago. Viene incluido en Linux, macOS y Windows.

¿En qué se diferencian SSH y Telnet?

Telnet envía todo sin cifrar, incluida la contraseña. Este protocolo cifra la sesión entera y comprueba la identidad del servidor. Por eso, Telnet solo debería quedar en equipos muy antiguos y en redes aisladas.

¿SFTP y FTPS son lo mismo?

No. SFTP funciona sobre este protocolo, por el puerto 22 y con las mismas claves. FTPS, en cambio, es el FTP clásico con cifrado añadido, y usa otros puertos.

¿PuTTY u OpenSSH en Windows?

Los dos sirven. OpenSSH ya viene con Windows y sus órdenes son las mismas que en Linux. PuTTY ofrece una ventana con sesiones guardadas y usa su propio formato de claves.

Cuándo pedir ayuda con sus servidores

Un servidor al que se entra por SSH necesita algo más que una buena configuración inicial. Hay que actualizarlo, revisar quién tiene acceso, retirar las claves de quien se va y vigilar el registro.

En KHARONTE administramos servidores Linux y Windows, máquinas virtuales y redes de empresas, con cada intervención registrada en un caso. Lo hacemos como servicios administrados de TI, por una mensualidad, o como outsourcing de infraestructura de TI cuando su empresa prefiere sumar personal a su equipo.

Si quiere conocer el resto de nuestros servicios de TI para empresas, o que revisemos cómo se administran hoy sus servidores, escríbanos.