Dos formas de entrar, y solo una es buena
SSH admite dos maneras de comprobar que eres tú: una contraseña, o un par de llaves. Las dos funcionan; solo una aguanta el mundo real.
Una contraseña se puede adivinar probando, y eso es exactamente lo que hacen los programas que recorren internet: millones de intentos contra cualquier servidor que responda. Una llave no se adivina probando.
Cómo funciona un par de llaves
Generas dos archivos que van juntos. La llave pública se copia al servidor y puede verla cualquiera: sirve para cerrar, no para abrir. La privada se queda en tu equipo y no sale de ahí nunca.
Al conectarte, el servidor lanza un reto que solo se puede responder teniendo la privada. La llave privada nunca viaja por la red, así que no hay nada que interceptar.
La llave privada es la llave de tu casa. No se manda por correo, no se sube a un repositorio, no se comparte con un compañero -si necesita entrar, se añade su llave pública-. Y se le pone frase de paso, que es lo que impide que sirva si alguien se lleva tu portátil.
Dejar el acceso por llave funcionando
Generar el par, en TU equipo
ssh-keygen -t ed25519 -C "ana@portatil"Te pregunta dónde guardarla -acepta lo que propone- y una frase de paso. Ponla. Es lo único que protege la llave si te roban el equipo.
ed25519es el tipo de llave recomendado hoy: más corta y más rápida que las antiguas RSA.Copiar la pública al servidor
ssh-copy-id usuario@servidorTe pide la contraseña esta última vez y deja la llave en su sitio. Si el comando no existe en tu equipo, se hace a mano: pegar el contenido de
~/.ssh/id_ed25519.puben el archivo~/.ssh/authorized_keysdel servidor.Comprobar que entra sin contraseña
ssh usuario@servidorSi te pide la frase de paso de tu llave, va bien. Si te pide la contraseña del usuario del servidor, la llave no quedó puesta: no sigas hasta arreglarlo.
Dejar de escribir la dirección larga
En tu equipo, el archivo
~/.ssh/configguarda apodos. Con cuatro líneas escribesssh produccionen vez de la dirección completa, el usuario y el puerto.
Host produccion
HostName 161.97.143.88
User developer
IdentityFile ~/.ssh/mi_llave
Port 22El aviso de la primera conexión
La primera vez que entras a un servidor, SSH muestra una huella digital y
pregunta si continúas. Casi todo el mundo escribe yes sin leer, y con eso
desactiva la única protección que hay contra que alguien se ponga en medio.
ssh developer@161.97.143.88The authenticity of host '161.97.143.88' can't be established. ED25519 key fingerprint is SHA256:9dCkH2p... Are you sure you want to continue connecting (yes/no)?
Esa huella identifica al servidor. Al aceptarla queda guardada, y si algún día vuelve a preguntártela por el mismo servidor, algo pasó: o lo reinstalaron, o no estás hablando con quien crees. La primera vez no puedes comprobar nada -salvo que el proveedor te la haya dado-, pero a partir de ahí sí.
Ya estás dentro: los primeros dos minutos
Te dan acceso a un servidor que no conoces y te dicen «mira a ver qué le pasa». Antes de tocar nada, cinco preguntas en orden. Son siempre las mismas y siempre en este orden, porque cada respuesta cambia lo que harías después.
# 1. Que maquina es y que sistema tiene
hostnamectl
# 2. Desde cuando esta encendida y cuanta carga lleva
uptime
# 3. Cuanto disco queda (la causa mas comun de "no funciona nada")
df -h
# 4. Cuanta memoria hay libre de verdad
free -h
# 5. Quien mas esta conectado ahora mismo
whoStatic hostname: vps-produccion
Operating System: Ubuntu 26.04 LTS
09:41:12 up 84 days, 3:22, 1 user, load average: 0.42, 0.51, 0.48
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 197G 188G 1.2G 99% /
total used free shared buff/cache available
Mem: 7.8Gi 4.1Gi 412Mi 88Mi 3.3Gi 3.4Gi
developer pts/0 2026-09-07 09:41 (190.85.x.x)Mira la tercera respuesta del ejemplo: 99% de disco, 1,2 GB libres. Ahí está el problema, y lo encontraste en veinte segundos sin saber nada de ese servidor.
Un disco lleno hace que las cosas fallen de formas que no se parecen en nada a
«el disco está lleno»: bases de datos que no escriben, sesiones que no se guardan,
servicios que no arrancan. Por eso df -h va de los primeros.
Cómo se lee cada respuesta
hostnamectl - dónde estás
Nombre de la máquina, versión del sistema y arquitectura.
El nombre es lo importante: confirma que no estás en el servidor equivocado. Es la comprobación que se salta todo el mundo justo antes de un desastre.
uptime - desde cuándo y con cuánta carga
up 84 days significa que lleva 84 días sin reiniciar. Si dice minutos y nadie lo reinició, se reinició solo: eso cambia por completo el diagnóstico.
Los tres números finales son la carga media en 1, 5 y 15 minutos. Como regla, se comparan con el número de núcleos: una carga de 4 en una máquina de 4 núcleos está al límite.
df -h - cuánto disco queda
-h es «legible para humanos»: gigas en vez de bloques.
Se mira la columna Use% de la línea montada en /.
Por encima del 90% hay que actuar; al 100% el servidor ya está fallando.
free -h - la memoria que parece llena y no lo está
La columna que importa es available, no free. Linux usa la memoria libre como caché de disco a propósito, y la suelta en cuanto alguien la necesita.
Por eso ver poca memoria «libre» es normal y no es un problema. Se mira available.
who - quién más está conectado
Si hay otra persona dentro, conviene saberlo antes de reiniciar un servicio. Y si hay una sesión que no reconoces, eso es lo primero que hay que investigar.
Salir sin dejar la sesión abierta
exit cierra la sesión y te devuelve a tu equipo. Conviene
cogerle el gesto: una terminal olvidada abierta en un servidor de producción es una
puerta que alguien puede empujar desde tu propia máquina.
Cada comando con su pregunta
Arrastra cada comando a la pregunta que responde, o toca uno y luego su espacio.
- ¿En qué máquina estoy y qué sistema tiene?
- ¿Desde cuándo está encendida y cuánta carga soporta?
- ¿Queda espacio en disco? Es la causa más común de fallos raros.
- ¿Cuánta memoria hay disponible de verdad?
- ¿Hay alguien más conectado ahora mismo?
Compruébalo tú mismo
¿Por qué una llave SSH es más segura que una contraseña?
free -h dice que quedan 412 Mi libres de 7,8 Gi. ¿Hay problema de memoria?
SSH vuelve a preguntarte por la huella de un servidor al que ya habías entrado. ¿Qué significa?
Lo que sigue
Ya entras y sabes dónde estás parado. En la siguiente lección te mueves por
el sistema de archivos, aprendes a leer los permisos de un vistazo y entiendes por
qué no se trabaja como root aunque el servidor te deje.
Siguiente: Archivos, permisos y sudo
Continuar ← Qué es un servidor y cómo conseguir uno