Servidores Linux

Entrar por SSH y orientarse

Lección 2 de 8 · 14 min

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

  1. 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.

    ed25519 es el tipo de llave recomendado hoy: más corta y más rápida que las antiguas RSA.

  2. Copiar la pública al servidor

    ssh-copy-id usuario@servidor

    Te 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.pub en el archivo ~/.ssh/authorized_keys del servidor.

  3. Comprobar que entra sin contraseña

    ssh usuario@servidor

    Si 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.

  4. Dejar de escribir la dirección larga

    En tu equipo, el archivo ~/.ssh/config guarda apodos. Con cuatro líneas escribes ssh produccion en vez de la dirección completa, el usuario y el puerto.

Un apodo en ~/.ssh/config
Host produccion
    HostName 161.97.143.88
    User developer
    IdentityFile ~/.ssh/mi_llave
    Port 22

El 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.

El aviso, y lo que significa
ssh developer@161.97.143.88
Resultado
The 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.

Los cinco comandos de reconocimiento
# 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
who
Resultado
Static 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.

  1. ¿En qué máquina estoy y qué sistema tiene?
  2. ¿Desde cuándo está encendida y cuánta carga soporta?
  3. ¿Queda espacio en disco? Es la causa más común de fallos raros.
  4. ¿Cuánta memoria hay disponible de verdad?
  5. ¿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