Cómo conectarte a tu nuevo servidor cloud por SSH

Cómo conectarte a tu nuevo servidor cloud por SSH

El servidor está funcionando, el panel muestra una dirección IP, un usuario y una contraseña, y ahora necesitas entrar. Esta es esa primera conexión, más las pocas cosas que conviene hacer antes de instalar nada.

Lo que te da el panel

Abre el servidor en tu panel de control y mira el bloque Access. Ahí están las tres cosas que necesitas: la dirección IP, Login y Password. Al lado hay dos botones. Generate new password crea una contraseña aleatoria nueva y Set new password acepta la que elijas tú. Las dos actúan sobre el servidor en marcha, así que úsalas si la contraseña lleva un rato en alguna ventana de chat.

La primera conexión

En macOS y en cualquier escritorio Linux, SSH ya viene instalado. En Windows forma parte del sistema desde Windows 10 y Windows Server 2019, así que el mismo comando funciona en PowerShell sin instalar PuTTY:

ssh root@203.0.113.10

La primera vez, SSH muestra una huella y pregunta si quieres continuar. Esa pregunta no es un trámite: SSH te está diciendo que nunca ha visto este host y no puede responder por él. En un servidor que acabas de crear, responde yes. Guarda la clave en ~/.ssh/known_hosts y no vuelve a preguntar por esa dirección.

Pasa a claves y luego cierra la puerta

Las contraseñas se reutilizan, se escriben en la ventana equivocada y se pegan en tickets. Las claves no. Genera una en tu propia máquina, no en el servidor:

ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id root@203.0.113.10

Después comprueba que el acceso con clave funciona en una segunda ventana de terminal, antes de cambiar nada. No cierres la primera. Si el ajuste nuevo está mal, esa sesión ya abierta es justo lo que usarás para deshacerlo.

Cuando la segunda ventana entre sin pedir contraseña, edita /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password

y recarga con systemctl reload ssh en Debian y Ubuntu, o systemctl reload sshd en AlmaLinux y Rocky.

Los cuatro errores que aparecen de verdad

Lo que ves	Qué significa	Qué hacer
Permission denied (publickey)	El servidor ya no acepta contraseñas y no tiene tu clave	Abre la consola KVM y revisa ~/.ssh/authorized_keys y sshd_config
Connection refused	Algo respondió: el host está encendido, pero nada escucha en el puerto 22	Consola y luego systemctl status ssh - el servicio está parado o en otro puerto
Connection timed out	No respondió nada: un firewall descarta los paquetes, la dirección no es esa, o el servidor está apagado	Comprueba el estado de encendido en el panel y después tus reglas de firewall
REMOTE HOST IDENTIFICATION HAS CHANGED	La clave del host no coincide con la que guardaste	Es lo normal tras reinstalar el sistema o restaurar una instantánea. Borra la entrada antigua con ssh-keygen -R 203.0.113.10

La diferencia útil está en las dos filas centrales. Refused significa que el servidor es alcanzable y el problema es un servicio. Timed out significa que tus paquetes no recibieron respuesta, así que el problema está entre tú y él.

La consola es la vía de vuelta

Todos los errores de este artículo te dejan fuera de SSH y ninguno te deja fuera del servidor. El panel tiene una consola KVM, es decir una pantalla y un teclado conectados directamente a la VM, y una consola de texto para los sistemas que la admiten. Ninguna pasa por SSH, así que un sshd_config roto, una regla de firewall que bloqueó tu propia dirección o una clave borrada se arreglan en cosa de un minuto.

Conviene saberlo antes de empezar, porque cambia lo que cuenta como arriesgado. Quedarte fuera aquí es una molestia, no un incidente.

Los primeros diez minutos

• Actualiza el sistema - apt update && apt upgrade o dnf upgrade, antes de que llegue nada más al disco
• Crea un usuario y deja de usar root - adduser you, añádelo a sudo o wheel y entra con él a partir de ahora
• Fija el hostname y revisa el reloj - hostnamectl set-hostname web-01 y luego timedatectl, porque una hora mal puesta rompe certificados y registros
• Activa las actualizaciones de seguridad automáticas - unattended-upgrades en Debian y Ubuntu, dnf-automatic en el resto
• Haz una instantánea - antes de la primera instalación, no después de que algo se rompa

En resumen

La primera conexión es un solo comando. Donde conviene ir despacio es en el cambio a claves, y la regla que lo hace seguro es simple: no cierres nunca la sesión que funciona hasta que una nueva se haya demostrado. Si aun así sale mal, la consola del panel sigue ahí.

Servidores cloud en Chequia y Portugal, desde EUR 15/mes, con consola y reinicio de contraseña en todos: dcxv.com/data-center#cloud