Conexiones SSH: de la primera conexión a un acceso fiable

Qué aprenderás y cómo recorrerlo

Esta guía desarrolla el uso cotidiano del cliente OpenSSH para acceder a servidores Linux: primera conexión, huellas, claves, configuración, transferencia y diagnóstico. Ofrece fundamento aplicado y procedimientos completos dentro de ese ámbito. Los saltos y túneles se presentan como ampliación; administrar sshd, diseñar una política de acceso o automatizar una flota necesitan secciones propias.

Tu objetivo declarado: conectarte a servidores Linux. Supuestos: puedes abrir una terminal y dispones de un servidor propio o autorizado, su dirección y una cuenta. No has declarado experiencia previa. «Local» significa tu equipo; «remoto», el servidor. Los comandos de preparación del equipo usan una shell tipo Bash en Linux/macOS; las diferencias de Windows se indican al final.

Conviene leer en orden: primero entiendes qué identidad se verifica, después autorizas la tuya y por último diagnosticas y amplías el acceso. Todos los nombres *.example.com, cuentas y rutas de trabajo son ficticios: sustitúyelos por los datos de tu entorno. No se han ejecutado conexiones reales para elaborar esta entrada.

1. Qué ocurre al conectar

SSH es un protocolo para transportar comunicaciones protegidas entre equipos. ssh es el cliente que ejecutas; sshd es el servicio que espera conexiones en el servidor. Linux es el sistema de destino de esta guía, pero SSH no es exclusivo de Linux.

El canal protege la confidencialidad y la integridad de los datos durante el tránsito. La identidad del servidor permite saber con quién estableces ese canal. La autenticación del usuario determina a qué cuenta puedes acceder. Son comprobaciones distintas: una conexión cifrada hacia un impostor seguiría siendo una conexión con el equipo equivocado. La arquitectura del protocolo, RFC 4251, explica esta separación.

La clave de host pertenece al servidor; tu clave de usuario te identifica a ti. Tampoco son lo mismo autenticarte y tener privilegios: entrar como operador no te convierte en administrador. Los permisos y sudo se deciden en el servidor.

2. Primera conexión: verificar antes de entrar

Reúne cuatro datos

Necesitas dirección o nombre DNS, puerto, nombre de la cuenta Linux y método de acceso inicial. El puerto habitual es 22, pero el administrador puede usar otro. El usuario de tu portátil y el de Linux pueden ser diferentes. Un panel web o una contraseña de proveedor tampoco equivalen necesariamente a una cuenta SSH.

En tu equipo

ssh -V
ssh -p 2222 operador@servidor.example.com

-V muestra la versión instalada. En la segunda línea, -p selecciona el puerto; operador es la cuenta remota. Si no existe el comando, instala el cliente OpenSSH mediante el mecanismo de tu sistema. El servidor necesita además un servicio SSH activo y una ruta de red que lo permita. Referencia de sintaxis: ssh(1).

La huella: el DNI de la clave del servidor

En una primera conexión puede aparecer una huella SHA256:… y una pregunta para confiar en ella. Pide la huella esperada al administrador por un canal ya autenticado o consúltala desde la consola del proveedor. Quien tenga acceso fiable a esa consola puede obtener, para una clave Ed25519 del servidor:

En el servidor, desde una consola ya fiable

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

Compara la huella de la misma clase de clave con la que muestra tu cliente. Si coinciden, acepta. El cliente registra la clave en ~/.ssh/known_hosts y la contrasta en futuras conexiones. Si no tienes un canal para verificarla, solo puedes establecer confianza en lo que recibes esa primera vez; ese límite debe ser una decisión consciente.

ssh-keyscan recoge claves de la red, pero no acredita que pertenezcan al servidor correcto. Usarlo y aceptar su resultado sin contraste conserva el problema inicial. Véanse ssh-keyscan(1) y ssh-keygen(1).

Si la identidad cambia

REMOTE HOST IDENTIFICATION HAS CHANGED! puede significar reinstalación, rotación de claves, cambio de destino o una interceptación. Primero confirma la causa y la nueva huella por una vía fiable. Solo después elimina el registro antiguo correspondiente:

En tu equipo, tras verificar el cambio

ssh-keygen -F '[servidor.example.com]:2222'
ssh-keygen -R '[servidor.example.com]:2222'

Para el puerto habitual, la búsqueda y eliminación suelen usar solo el nombre, sin corchetes ni puerto. Vuelve a conectar y verifica la huella nueva. Desactivar la comprobación con StrictHostKeyChecking=no elimina precisamente la protección que te avisó.

3. Acceso con claves: qué guarda cada lado

El servidor tiene tu clave pública. Tu cliente demuestra que puede firmar con la privada, sin enviarla al servidor. La frase de paso cifra la clave privada en disco; la contraseña de la cuenta remota es otra credencial. Una pública se puede compartir para autorizar acceso; una privada no se copia al servidor ni se pega en un chat.

1 · Genera una identidad en tu equipo

En tu equipo · Linux/macOS, shell tipo Bash

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_servidores -C "equipo-personal"

Introduce una frase de paso cuando se solicite. Se crean el archivo privado y otro terminado en .pub. Si el nombre ya existe, elige otro: reemplazar una clave puede dejar sin acceso a los servidores que autorizaban la anterior. Ed25519 es una elección práctica con OpenSSH moderno; una política corporativa o un entorno regulado pueden exigir otra opción. Confirma la compatibilidad en el entorno concreto.

Separar claves por dispositivo permite retirar un portátil sin reemplazar las de todos tus equipos. Separarlas además por entorno reduce el alcance de una pérdida, a cambio de más gestión. Conserva una recuperación segura o una vía alternativa de acceso. Referencia de generación: ssh-keygen(1).

2 · Autoriza la pública en la cuenta correcta

Para instalar la primera clave ya necesitas alguna vía autorizada: contraseña permitida, otra clave o consola administrativa. ssh-copy-id no crea acceso desde cero.

En tu equipo · si tienes ssh-copy-id

ssh-copy-id -i ~/.ssh/id_ed25519_servidores.pub -p 2222 operador@servidor.example.com

Se indica explícitamente la .pub para seleccionar qué identidad añadir. Si la herramienta no está disponible, pide al administrador que incorpore esa pública, como una única línea completa, al archivo autorizado de la cuenta de destino. No sustituyas el archivo entero: podría contener otras claves. El procedimiento y sus opciones están en ssh-copy-id(1), Debian.

En una configuración Linux habitual, la cuenta remota debe ser propietaria de sus archivos. Si ya existe authorized_keys, estos permisos son un punto de partida:

En el servidor, dentro de la cuenta de destino

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

~ se refiere aquí al directorio de la cuenta remota, no al de tu portátil. No crees el archivo en el home de root si pretendes entrar como operador. El home y los archivos tampoco deben permitir escritura a terceros. Una política distinta puede cambiar la ubicación mediante AuthorizedKeysFile. Fuentes: sshd(8) y sshd_config(5).

3 · Prueba sin depender de la contraseña remota

En tu equipo · abre una segunda terminal

ssh -p 2222 -i ~/.ssh/id_ed25519_servidores \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  operador@servidor.example.com

Puede pedir la frase de paso de la clave local. La selección de publickey evita dar por probado el acceso con clave cuando en realidad has entrado mediante la contraseña remota. Si el servidor exige clave más un segundo factor, esta prueba de un solo método no completa esa política: utiliza el procedimiento indicado por su administrador.

4 · Usa un agente sin perder de vista su alcance

Un agente realiza las operaciones de autenticación con las claves cargadas; evita desbloquear el archivo en cada conexión. Comprueba si tu sesión ya dispone de uno antes de iniciar procesos adicionales.

En tu equipo

ssh-add -l
ssh-add -t 1h ~/.ssh/id_ed25519_servidores
ssh-add -d ~/.ssh/id_ed25519_servidores

La primera línea enumera identidades; la segunda carga esta clave durante una hora; la tercera la retira del agente. Si el error indica que no hay conexión con un agente y tu entorno no lo gestiona, en Bash puedes iniciar uno con eval "$(ssh-agent -s)". Sus variables quedan en esa shell. Consulta ssh-agent(1) y ssh-add(1).

La frase de paso protege el archivo; una clave ya disponible en un agente sigue siendo utilizable por procesos que puedan acceder a él. Retirarla del agente tampoco revoca el acceso en el servidor. Para revocar, elimina la pública autorizada en cada destino afectado, con ayuda administrativa si hace falta. Una clave comprometida requiere además revisar accesos y cerrar sesiones: borrar la autorización no termina automáticamente las que ya estaban abiertas.

4. Un alias evita errores repetidos

Guarda un bloque como este en ~/.ssh/config de tu equipo. El alias laboratorio es local; HostName especifica el destino real. Si ya tienes configuración, integra el bloque y revisa sus coincidencias.

Host laboratorio
    HostName servidor.example.com
    User operador
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_servidores
    IdentitiesOnly yes
    ForwardAgent no
    ServerAliveInterval 30
    ServerAliveCountMax 3

IdentityFile selecciona la identidad; IdentitiesOnly limita las identidades ofrecidas a las configuradas y evita probar indiscriminadamente las del agente. Los mensajes ServerAlive ayudan a detectar una conexión que deja de responder; estos valores suelen cortarla tras unos 90 segundos sin respuesta. No reconectan ni conservan por sí mismos los procesos.

Para la mayoría de las opciones rige el primer valor obtenido: coloca bloques específicos antes de un eventual Host *. Algunas opciones, como IdentityFile, acumulan valores. Puedes examinar el resultado con ssh -G laboratorio y después conectar con ssh laboratorio. Referencia: ssh_config(5).

En Linux/macOS restringe la escritura del archivo a tu usuario; chmod 600 ~/.ssh/config es una opción habitual. La configuración del cliente decide cómo solicitas una conexión. No abre puertos ni modifica las políticas del servicio remoto.

5. Trabajar al otro lado

Terminal y comandos remotos

Tras entrar, comprueba dónde estás antes de operar. whoami muestra la cuenta, hostname el equipo y pwd el directorio. Cierra la shell con exit. Puedes ejecutar una comprobación sin abrir una sesión interactiva:

En tu equipo; el texto entre comillas se ejecuta remotamente

ssh laboratorio 'whoami; hostname; pwd'

En Bash, las comillas simples evitan que tu shell expanda variables dentro del texto antes de enviarlo. Cambiar las comillas puede cambiar qué equipo interpreta $HOME, comodines o sustituciones. Para tareas complejas, usa un script revisado con parámetros controlados; concatenar datos no confiables en un comando remoto puede ejecutar instrucciones imprevistas.

Archivos: usa el mismo alias

En tu equipo · ejemplos de archivos ficticios

scp ./informe.txt laboratorio:informe.txt
scp laboratorio:informe.txt ./informe-descargado.txt
sftp laboratorio

En estos ejemplos, el destino relativo remoto está en el home de la cuenta. La primera orden sube el archivo, la segunda lo descarga. Revisa el nombre de destino: una transferencia puede reemplazar un archivo existente. En clientes OpenSSH recientes, scp usa SFTP por defecto; un servidor sin ese subsistema puede requerir revisar la compatibilidad. Referencia: scp(1).

En la sesión sftp, pwd y ls miran el lado remoto; lpwd y lls miran el local. put informe.txt sube, get informe.txt descarga y bye termina. Si no usas alias, el puerto de scp y sftp se escribe con -P mayúscula; en ssh, con -p minúscula. Referencia: sftp(1).

Qué significa perder la conexión

Una terminal SSH depende de la conexión de red. Si se interrumpe, el comportamiento de los procesos depende de la shell y de cómo se lanzaron; no presupongas que seguirán trabajando. Para sesiones que quieras retomar, un multiplexor de terminal como tmux puede ser apropiado si está instalado y autorizado. Los trabajos de producción deberían ejecutarse mediante el mecanismo de tareas o servicios del sistema. Esta guía no desarrolla su configuración.

Si una sesión interactiva queda bloqueada, la secuencia Intro, ~, . puede cerrar el cliente con el carácter de escape por defecto. Es una desconexión forzada, no una confirmación de que el trabajo remoto haya finalizado.

6. Diagnóstico: encuentra la primera capa que falla

Cambiar la clave no arregla una ruta de red y abrir un puerto no corrige una cuenta equivocada. Empieza por lo que el mensaje ya permite descartar. Prueba con el alias y recoge más detalle solo cuando lo necesites:

En tu equipo

ssh -G laboratorio
ssh -vvv -o ConnectTimeout=10 laboratorio

El primero muestra la configuración efectiva; el segundo añade detalle y acota la espera de conexión. Antes de compartir una traza, oculta nombres, direcciones, cuentas y rutas. Busca la progresión: conexión TCP, negociación, clave de host, identidad ofrecida y autenticación. Referencia: ssh(1).

Si el cliente muestra Offering public key pero el servidor no la acepta, comprueba que autorizaste esa pública en esa cuenta. Una identidad correcta puede rechazarse por permisos, restricciones de origen, certificado o política. El registro de sshd en el servidor puede explicar el motivo; debe revisarlo quien tenga acceso administrativo. Su ubicación depende de la distribución.

Si administras un Ubuntu, su guía de OpenSSH Server explica instalación, registros y validación de configuración. No copies cambios de sshd_config ni reinicies servicios a ciegas: conserva un acceso fiable y valida los cambios antes de aplicarlos. La configuración efectiva puede incluir otros archivos y bloques condicionales.

7. Bastiones y túneles: cuándo te hacen falta

Esta sección introduce las herramientas para reconocer un caso y elegir el siguiente paso. Sus permisos, rutas y exposición requieren revisión del entorno; no sustituye una guía completa de redes.

Un bastión para llegar a otra máquina

Un bastión es un equipo intermedio al que sí puedes llegar. ProxyJump lo usa como salto para establecer la conexión SSH al destino. Configura las dos identidades localmente:

Host bastion
    HostName salto.example.com
    User acceso
    IdentityFile ~/.ssh/id_ed25519_servidores
    IdentitiesOnly yes

Host aplicacion
    HostName app.example.com
    User operador
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_servidores
    IdentitiesOnly yes

Después usa ssh aplicacion. El bastión debe alcanzar el destino y permitir ese reenvío; tu cliente autentica cada servidor. Puedes usar claves distintas por salto. No necesitas copiar la privada al bastión ni habilitar ForwardAgent. El reenvío del agente permite al lado remoto solicitar operaciones de autenticación mientras está disponible; úsalo solo si la tarea lo necesita y confías en ese entorno. Fuente: ProxyJump y ForwardAgent, ssh_config(5).

Un túnel local para un servicio remoto

Supón que una aplicación web escucha en el puerto 8080 del loopback del servidor. Puedes abrir en tu equipo un puerto que conduzca hasta ella:

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:18080:127.0.0.1:8080 laboratorio

Mientras el comando esté activo, abre http://127.0.0.1:18080 en tu navegador. -N evita abrir una shell. La escucha explícita en loopback limita el acceso por red a tu equipo; otros procesos locales todavía pueden usarla. ExitOnForwardFailure detecta fallos al crear el reenvío, pero no garantiza que la aplicación final responda. Detén el túnel con Ctrl+C.

El cifrado cubre el tramo SSH; si el servidor contacta con un tercer equipo, ese tramo adicional necesita su propia protección. La autenticación de la aplicación sigue vigente. Un proxy SOCKS no convierte automáticamente todo el tráfico ni todas las consultas DNS en tráfico del túnel. Evita ampliar escuchas a todas las interfaces sin estudiar quién podrá acceder. Referencias: reenvíos, ssh(1) y ExitOnForwardFailure.

8. Consulta rápida

Diccionario de los términos que aparecen

Huella

Resumen de una clave pública para compararla por un canal fiable.

Clave de host

Identidad del servidor. Se contrasta con known_hosts en el cliente.

Clave de usuario

Identidad con la que solicitas acceso a una cuenta. Su pública se autoriza en el servidor.

Frase de paso

Protección del archivo privado local. Diferente de la contraseña remota.

Agente

Proceso local que usa claves cargadas para autenticar.

Loopback

Interfaz de la propia máquina: 127.0.0.1 en los ejemplos IPv4.

Puerto

Número que identifica un punto de servicio en una dirección de red.

DNS

Sistema que resuelve nombres en direcciones; algunas redes requieren VPN para su DNS interno.

Si tu equipo utiliza Windows

Con el cliente OpenSSH disponible puedes usar ssh, scp y los alias. La configuración de usuario suele estar en %USERPROFILE%\.ssh\config. Los comandos Bash de esta guía no se trasladan literalmente a PowerShell: los permisos se gestionan mediante ACL y el agente puede ser un servicio de Windows. Tampoco presupongas que ssh-copy-id está instalado. Sigue la documentación de Microsoft sobre gestión de claves para esos pasos locales; el servidor de destino de esta guía sigue siendo Linux.

Práctica opcional con resultado útil

En un servidor de pruebas autorizado, crea el alias, verifica la huella y abre una segunda conexión con tu clave. Ejecuta whoami, hostname y pwd. La utilidad es comprobar que el alias elige la cuenta y el destino esperados antes de realizar tareas con efectos. No necesitas compartir salidas ni completar esta práctica para continuar.

9. Fuentes y por dónde continuar

Referencia principal: manual oficial ssh(1). Para opciones de alias, consulta ssh_config(5); para identidades, ssh-keygen(1). Las fuentes específicas están enlazadas junto a los procedimientos que sustentan.

Documentación consultada el 16 de octubre de 2026. Los manuales web pueden describir una versión más nueva que la instalada en tu equipo: contrasta ssh -V y, en Unix, man ssh y man ssh_config. La política del servidor puede exigir segundo factor, certificados o algoritmos concretos.

El siguiente desarrollo lógico es administrar un servidor SSH sin perder el acceso: consola de recuperación, configuración efectiva, validación, políticas de autenticación y registros. Después encajan la automatización con permisos limitados y los certificados para muchos servidores. Aquí se han explicado los fundamentos del cliente; no se da por cubierto ese ámbito de administración.

Puedes plantear dudas sobre un mensaje concreto o pedir más profundidad en claves, saltos o túneles. Para mantener un acceso fiable, recuerda la secuencia que ya puedes usar como mapa: llegar al destino, verificar su identidad, autenticar la tuya y confirmar dónde vas a trabajar.