Cómo conectarse a un VPS por SSH desde Windows, macOS y Linux

Datos que necesitas antes de conectarte

Ten a mano la dirección IP pública, el usuario, el puerto SSH y el método de autenticación. En una instalación nueva el usuario puede ser root, ubuntu o debian, según la imagen. No adivines: revisa el correo de provisión o el panel del proveedor.

El puerto predeterminado es el 22. Si el proveedor indica otro, se añade con -p. Para una llave privada se utiliza -i:

ssh -p 22 -i ~/.ssh/mi_llave [email protected]

La IP 203.0.113.10 es de documentación. No copies el ejemplo literalmente.

Conectarse desde Windows 10 y Windows 11

Abre PowerShell o Terminal de Windows. Comprueba que OpenSSH está disponible:

ssh -V

Luego inicia la conexión:

ssh root@IP_DEL_VPS

La primera vez aparecerá la huella digital del servidor. Compárala con la consola del proveedor antes de escribir yes. Después introduce la contraseña; mientras escribes no se muestran puntos ni asteriscos, lo cual es normal.

Si OpenSSH no está instalado, entra en Configuración > Sistema > Características opcionales, busca “Cliente OpenSSH” e instálalo. PuTTY sigue siendo útil si prefieres una interfaz gráfica, pero ya no es obligatorio para una conexión básica.

Conectarse desde macOS

Abre Terminal desde Aplicaciones > Utilidades o búscala con Spotlight. El cliente SSH viene instalado. Ejecuta:

ssh usuario@IP_DEL_VPS

Para una llave descargada, limita primero sus permisos y conéctate:

chmod 600 ~/Downloads/mi_llave
ssh -i ~/Downloads/mi_llave usuario@IP_DEL_VPS

Si macOS pregunta si Terminal puede acceder a la carpeta Descargas, permite el acceso únicamente si allí está la llave que elegiste.

Conectarse desde Linux

La mayoría de distribuciones incluyen el cliente OpenSSH. Desde la terminal usa el mismo comando:

ssh usuario@IP_DEL_VPS

En Debian o Ubuntu puedes instalar el cliente con sudo apt install openssh-client; en Fedora, Rocky Linux o AlmaLinux, con sudo dnf install openssh-clients.

Cómo verificar la huella SSH

La advertencia de primera conexión protege contra servidores falsos y ataques de intermediario. Desde la consola web del VPS puedes obtener las huellas con:

sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Compara el resultado con el valor de tipo ED25519 mostrado en tu computador. Si una máquina conocida cambia de huella sin que hayas reinstalado el sistema, detente e investiga. Para retirar una entrada antigua después de una reinstalación legítima:

ssh-keygen -R IP_DEL_VPS

Primeros comandos dentro del servidor

Confirma dónde estás y qué sistema utiliza el VPS:

whoami
hostnamectl
cat /etc/os-release
uptime
free -h
df -h

No empieces copiando una lista desconocida de comandos como root. Actualiza el sistema, crea un usuario administrativo y configura llaves SSH antes de publicar servicios.

Errores comunes al conectarse por SSH

Usa la consola web del proveedor si una regla de firewall o una configuración de SSH te deja fuera. En un VPS de Terranode puedes acceder a la consola desde el panel incluso cuando SSH no responde.

Qué ocurre realmente cuando ejecutas ssh usuario@servidor

La conexión SSH pasa por resolución de nombre, red TCP, negociación criptográfica, verificación de identidad del servidor y autenticación del usuario. Identificar la fase que falla evita cambiar contraseñas cuando el problema es un puerto cerrado.

• El nombre o IP lleva al host; el puerto lleva al proceso sshd; la huella identifica la máquina.
• Tu contraseña o llave demuestra quién eres, pero no sirve si el usuario remoto no existe.
• El prompt final confirma una sesión, no necesariamente privilegios administrativos.

La comprobación práctica debe acompañar el cambio. Añade -v al cliente y lee dónde se detiene: Connecting, Connection established, host key o Authentications that can continue. Esa secuencia es más útil que probar comandos al azar.

La precaución principal en este punto es clara: borrar known_hosts completo ante cualquier aviso elimina protección para todos tus servidores. Retira solo la entrada concreta después de verificar una reinstalación legítima.

Windows Terminal, PowerShell y rutas de llaves sin confusión

Windows 10 y 11 incluyen OpenSSH en la mayoría de instalaciones. PowerShell y Windows Terminal ejecutan el mismo cliente; la diferencia habitual está en cómo se escribe la ruta de la llave y en sus permisos.

• Comprueba Get-Command ssh y ssh -V antes de instalar PuTTY u otro cliente.
• Las llaves suelen vivir en $env:USERPROFILE\.ssh; usa comillas si la ruta contiene espacios.
• El agente ssh-agent evita repetir la frase de paso sin dejar una llave privada sin protección.

Para verificar esta parte sin depender de intuiciones, una conexión explícita con ssh -i "$env:USERPROFILE\.ssh\id_ed25519" usuario@IP elimina dudas sobre qué llave ofrece el cliente. Después puedes crear un alias en el archivo config.

La precaución principal en este punto es clara: copiar una clave privada a OneDrive, correo o chat facilita la conexión hoy y compromete todos los servidores mañana. Distribuye públicas; conserva la privada en el dispositivo que la generó.

macOS y Linux: permisos, agente y selección de identidad

En sistemas Unix, OpenSSH rechaza llaves privadas legibles por otros usuarios. El mensaje sobre UNPROTECTED PRIVATE KEY FILE se corrige restringiendo permisos, no ejecutando SSH como root.

• Usa chmod 600 para la privada y chmod 700 para el directorio .ssh.
• Carga la llave protegida con ssh-add y comprueba el inventario del agente con ssh-add -l.
• Añade IdentitiesOnly yes cuando tienes muchas llaves y el servidor corta tras varios intentos.

La evidencia que conviene guardar es concreta. Ejecuta ssh -G alias | grep -E 'hostname|user|port|identityfile' para ver la configuración final que usará el cliente. Así detectas reglas heredadas de otro bloque Host.

La precaución principal en este punto es clara: un ssh-agent desbloqueado da acceso mientras dura la sesión local. Bloquea el equipo, limita reenvío de agente y no uses ForwardAgent yes de forma global.

La huella del servidor: cómo verificarla sin aceptarla a ciegas

La huella responde a «¿es este el servidor que esperaba?». La primera conexión no tiene historial, por lo que debes obtener el valor por un canal independiente: consola del proveedor, inventario firmado o administrador que ya accede.

• Compara preferentemente la huella ED25519, completa y con el mismo algoritmo.
• Después de reinstalar, genera la huella desde consola antes de retirar la entrada antigua.
• Si no hubo reinstalación ni cambio planificado, trata el aviso como posible intermediario o IP reasignada.

Antes de dar el paso por terminado, en el servidor, ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub produce el valor. En el cliente, la advertencia muestra el algoritmo y SHA256 que deben coincidir.

La precaución principal en este punto es clara: aceptar yes por costumbre convierte una protección criptográfica en un aviso decorativo. La contraseña puede viajar cifrada hacia el servidor equivocado si validas una huella falsa.

Crear aliases seguros para no memorizar puertos y usuarios

El archivo ~/.ssh/config reduce errores operativos cuando administras varios VPS. Un alias guarda host, usuario, puerto e identidad sin guardar la frase de paso ni la clave dentro del archivo.

• Usa nombres que indiquen entorno, por ejemplo tienda-produccion, no aliases ambiguos como server1.
• Aplica valores comunes bajo Host * con cautela; una opción global puede romper servicios Git u otros saltos.
• Separa la llave de producción de la usada en pruebas y especifica IdentitiesOnly yes.

En producción, la validación útil es la que reproduce la ruta real. Valida cada alias con ssh -G tienda-produccion antes de confiarlo a un script. El resultado muestra opciones expandidas y permite revisar si apunta a la IP correcta.

La precaución principal en este punto es clara: no pongas contraseñas en config. OpenSSH no ofrece un campo seguro para ello y cualquier truco que automatice una contraseña suele exponerla en archivos o procesos.

Una revisión compacta para esta fase puede ejecutarse así:

Host tienda-produccion
  HostName 203.0.113.10
  User adminweb
  Port 22
  IdentityFile ~/.ssh/id_ed25519_tienda
  IdentitiesOnly yes
  ServerAliveInterval 30

Lee la salida completa y conserva la hora de la prueba. Estos comandos no corrigen nada por sí solos: sirven para confirmar el estado antes de decidir el siguiente cambio.

Diagnosticar timeout, refused y no route to host

Estos tres errores aparecen antes de autenticar. timeout indica que no llegó una respuesta; refused, que el destino respondió pero nada acepta ese puerto; no route, que el sistema no encuentra una ruta utilizable.

• Confirma IP y puerto desde el panel, luego prueba conectividad desde otra red para descartar bloqueo local.
• Desde la consola del VPS revisa systemctl status ssh, ss -ltnp y las reglas de firewall.
• Distingue firewall del sistema, firewall del proveedor, NAT doméstico y restricciones de la red desde la que sales.

La comprobación práctica debe acompañar el cambio. En Windows Test-NetConnection IP -Port 22; en macOS o Linux nc -vz IP 22 comprueban TCP sin mezclar autenticación. Si TCP abre, deja de tocar UFW y estudia SSH.

La precaución principal en este punto es clara: reiniciar el VPS repetidamente no corrige una IP errónea ni un puerto bloqueado. Además destruye evidencia temporal y puede interrumpir otras tareas.

Resolver Permission denied sin debilitar el servidor

Permission denied significa que sí alcanzaste SSH, pero ninguna autenticación ofrecida fue aceptada. La parte final del mensaje —publickey, password— revela qué métodos permite el servidor.

• Confirma primero el usuario: ubuntu, debian y root no comparten authorized_keys.
• Usa ssh -vvv -i llave usuario@host y busca qué identidad se ofrece y qué responde el servidor.
• Desde consola revisa propietarios y modos de home, .ssh y authorized_keys, además del log de sshd.

Para verificar esta parte sin depender de intuiciones, la cadena segura suele ser directorio home no escribible por terceros, .ssh con 700, authorized_keys con 600 y propietario correcto. sshd -T revela políticas efectivas.

La precaución principal en este punto es clara: reactivar contraseñas globalmente para resolver una llave expone todas las cuentas. Corrige usuario, llave o permisos desde consola y vuelve a probar.

Copiar archivos con scp y sftp usando la misma identidad

Una vez funciona SSH, scp, sftp y rsync -e ssh reutilizan transporte, puerto y llaves. El error frecuente es olvidar el puerto personalizado o transferir como root archivos que luego la aplicación no puede leer.

• En scp, el puerto se indica con -P mayúscula; en ssh, con -p minúscula.
• Usa un directorio de entrada propiedad del usuario y mueve después con sudo cuando el destino sea del sistema.
• Para transferencias grandes, rsync reanuda mejor y muestra progreso sin volver a enviar bloques iguales.

La evidencia que conviene guardar es concreta. Tras copiar, revisa tamaño, hash y propietario en el VPS. Una transferencia exitosa no garantiza permisos adecuados ni que el archivo se haya colocado en el entorno correcto.

La precaución principal en este punto es clara: nunca envíes la llave privada al VPS para «tenerla a mano». El servidor solo necesita tu clave pública; la privada debe permanecer en el cliente.

Sesiones largas, cortes y trabajo remoto fiable

SSH no garantiza que una sesión interactiva sobreviva a un cambio de red. Para actualizaciones o importaciones largas usa tmux o screen, de modo que el proceso continúe aunque cierres el portátil.

• Activa keepalives del cliente para detectar conexiones muertas, no para ocultar procesos sin supervisión.
• Ejecuta tareas repetibles con systemd, cron o un pipeline; una terminal abierta no es automatización.
• Evita compilar o editar como root cuando un usuario de despliegue puede hacerlo con permisos limitados.

Antes de dar el paso por terminado, abre una sesión tmux, inicia una tarea de prueba, desconecta y vuelve a adjuntarte. Practicarlo antes de una migración reduce decisiones improvisadas.

La precaución principal en este punto es clara: aumentar indiscriminadamente tiempos de espera puede dejar sesiones huérfanas. El objetivo es recuperar el trabajo, no mantener conexiones eternas.

Recuperar acceso cuando SSH queda bloqueado

La consola web es el camino de emergencia cuando el demonio no inicia, el firewall cerró el puerto o la única llave fue retirada. Debes probarla antes del incidente y saber qué credenciales exige.

• Desde consola ejecuta sshd -t, revisa el journal y confirma la dirección escuchada.
• Añade temporalmente una regla limitada a tu IP en vez de abrir todo el servidor.
• Restaura una configuración conocida, prueba una conexión externa y retira la excepción temporal.

En producción, la validación útil es la que reproduce la ruta real. Documenta la secuencia exacta y dónde están las claves de recuperación. El acceso de emergencia que solo conoce una persona no es un procedimiento operativo.

La precaución principal en este punto es clara: no reinstales el VPS como primera respuesta: puedes perder datos y la evidencia del error. Reinstala solo con backups verificados y un plan de reconstrucción.

Caso práctico: separar un fallo de red de uno de autenticación

Una forma útil de consolidar el procedimiento es recorrer un incidente de principio a fin. En este caso, el objetivo no es acumular comandos, sino dejar acceso remoto por SSH en un estado que otra persona pueda entender, verificar y recuperar.

Primero registra el estado anterior y la hora. La conexión SSH pasa por resolución de nombre, red TCP, negociación criptográfica, verificación de identidad del servidor y autenticación del usuario. Identificar la fase que falla evita cambiar contraseñas cuando el problema es un puerto cerrado. Por eso la primera decisión debe quedar escrita junto con el resultado esperado. Si el cambio afecta acceso o datos, abre una ruta de recuperación independiente antes de continuar.

Después aplica una sola modificación y observa su efecto. Windows 10 y 11 incluyen OpenSSH en la mayoría de instalaciones. PowerShell y Windows Terminal ejecutan el mismo cliente; la diferencia habitual está en cómo se escribe la ruta de la llave y en sus permisos. La evidencia mínima incluye la orden ejecutada, su salida relevante y una comprobación desde el lugar real del usuario. Ejecutar la prueba únicamente dentro del VPS puede ocultar reglas de red, DNS o proxy que forman parte del servicio.

En el tercer paso revisa privilegios y exposición. En sistemas Unix, OpenSSH rechaza llaves privadas legibles por otros usuarios. El mensaje sobre UNPROTECTED PRIVATE KEY FILE se corrige restringiendo permisos, no ejecutando SSH como root. Pregunta qué identidad ejecuta el proceso, qué archivos puede leer y desde qué redes se alcanza. Si la respuesta es «cualquiera» o «todo», detente y reduce el alcance antes de añadir otra capa.

A continuación prueba la condición de fallo. La huella responde a «¿es este el servidor que esperaba?». La primera conexión no tiene historial, por lo que debes obtener el valor por un canal independiente: consola del proveedor, inventario firmado o administrador que ya accede. Una buena validación incluye el camino positivo y el negativo: lo autorizado funciona y lo que decidiste bloquear deja de funcionar. Guarda la salida y no cierres el acceso de emergencia hasta completar ambos lados.

Luego simula recuperación. El archivo ~/.ssh/config reduce errores operativos cuando administras varios VPS. Un alias guarda host, usuario, puerto e identidad sin guardar la frase de paso ni la clave dentro del archivo. Revertir en una ventana tranquila revela dependencias ausentes, permisos que solo existían en la sesión del administrador y pasos que nunca se documentaron. El rollback debe indicar qué se restaura, desde dónde y cómo sabes que terminó bien.

Finalmente observa el servidor durante una ventana comparable a la carga habitual. Estos tres errores aparecen antes de autenticar. timeout indica que no llegó una respuesta; refused, que el destino respondió pero nada acepta ese puerto; no route, que el sistema no encuentra una ruta utilizable. Si aparecen errores nuevos, crecimiento sostenido o reintentos, el cambio todavía no está terminado. Si la ruta funciona y las métricas permanecen dentro de lo previsto, registra versión, fecha y responsable. Ese registro convierte una solución individual en una operación repetible.

El resultado esperado no es «se ejecutaron los comandos», sino una evidencia breve: configuración válida, servicio accesible solo por la ruta prevista, prueba negativa correcta, datos persistentes cuando corresponda y un camino de recuperación ensayado. Con esa disciplina, acceso remoto por SSH deja de depender de memoria o improvisación.

Acceder a un VPS privado mediante ProxyJump

Cuando una base de datos o un servidor interno no tiene IP pública, no debes abrir SSH en cada máquina. El patrón más limpio es usar un bastion: un único VPS expuesto que recibe la conexión y la reenvía al host privado. OpenSSH realiza el salto con -J, sin copiar tu llave privada al servidor intermedio:

ssh -J operador@BASTION_PUBLICO [email protected]

La primera identidad autentica el acceso al bastion y la segunda al servidor privado. Si cada salto usa una llave o puerto diferente, decláralos por separado en ~/.ssh/config:

Host bastion-terranode
  HostName 203.0.113.10
  User operador
  IdentityFile ~/.ssh/id_ed25519_bastion
  IdentitiesOnly yes

Host app-privada
  HostName 10.20.0.15
  User deploy
  IdentityFile ~/.ssh/id_ed25519_app
  IdentitiesOnly yes
  ProxyJump bastion-terranode

Con esa configuración basta ejecutar ssh app-privada; scp app.tar.gz app-privada:/tmp/ también reutiliza el salto. La llave de la aplicación permanece en tu equipo y el bastion solo transporta la conexión cifrada. Evita activar ForwardAgent yes de forma global: un administrador o proceso con acceso suficiente al host intermedio podría aprovechar el agente mientras la sesión está abierta. Si necesitas reenvío de agente para un caso controlado, limítalo a un host y a una ventana concreta.

Para diagnosticar este esquema ejecuta ssh -vvv app-privada y observa por separado la conexión al bastion y al destino. Un timeout en el segundo salto suele indicar rutas o firewall de la red privada; Permission denied después del salto señala usuario, llave o permisos del host interno. Esta separación conserva el principio del resto de la guía: identifica primero la fase que falla y solo entonces modifica la configuración relacionada.