SSH (Secure Shell) es el protocolo estándar para acceder de forma cifrada a servidores remotos; conocerlo es esencial en Digital Forensics porque permite adquirir, inspeccionar y preservar evidencia remota de forma segura y verificable. Hasta ahora hemos comenzado a ver como adentrarnos en un dispositivo para detectar y demostrar que ha sido expiado o recuperar una memoria dañada, pero todavía falta uno de los pilares esenciales en toda esta disciplina: el servidor, ese lugar desde donde entrará y saldrá la información del dispositivo implicado.
Hoy comenzaremos por ese protocolo esencial para poder conectarnos y que nos servirá como excusa, gracias a sus procedimientos para entender como funciona el cifrado de seguridad con el que se realizan la mayoría de conexiones, no solo con SSH.
Qué es SSH y cómo funciona
SSH (Secure Shell) crea un canal cifrado entre un cliente y un servidor para ejecutar comandos remotos, transferir archivos y tunelizar conexiones. Utiliza criptografía asimétrica para la autenticación (claves públicas/privadas) y cifrado simétrico para la sesión, evitando que un atacante intercepte credenciales o datos en texto plano.
¿Por qué es importante en Digital Forensics?
- Acceso remoto a evidencia: muchos servidores no son físicamente accesibles; SSH permite adquirir imágenes forenses y logs de forma remota si se hace correctamente.
- Preservación de la cadena de custodia: usar conexiones seguras y registrar hashes/fingerprints evita manipulación y demuestra integridad.
- Detección de compromiso: análisis de claves,
authorized_keysy sesiones SSH ayuda a identificar puertas traseras o cuentas persistentes
Por si no ha quedado claro: Dominar SSH no solo facilita el acceso técnico a sistemas remotos, sino que es una habilidad forense crítica para adquirir evidencia de forma segura, detectar compromisos y mantener la validez legal de las pruebas. Así pues, comencemos!
Accediendo a un VPS
Es probable que la mayoría de nuestros lectores ,si están comenzando, no tengan acceso a un servidor (obviamente, sin conocimientos podría resultar catastrófico en caso de error) pero resulta relativamente sencillo y barato contratar un VPS o que nos dejen acceder a uno con algún software instalado para ‘cacharrear’ un poco. Así que para comenzar y si alguno quiere ponerse ‘manos en la masa’ daremos esta primera explicación orientada a un VPS, pero claro ¿qué es?
PRACTICANDO CON UN VPS
Las siglas significan Virtual Private Server (Servidor Privado Virtual). Para entenderlo sin tecnicismos, imagina un edificio de apartamentos:
- El Servidor Físico: Es el edificio completo (como los racks que vemos en cualquier torre de servidor).
- El VPS: Es tu apartamento. Tienes tu propia puerta, tu propia llave y total libertad para pintar las paredes o cambiar los muebles.
Aunque compartes los cimientos (el hardware) con otros vecinos, lo que tú hagas dentro de tu «apartamento» no les afecta a ellos, y viceversa. Tienes recursos garantizados (RAM, CPU) y, lo más importante, permisos de administrador (root).
¿Por qué son ideales para aprender SSH desde cero?
Aprender SSH en un VPS es como practicar paracaidismo con una red de seguridad gigante. Estas son las razones principales:
- Entorno Real, Riesgo Cero: SSH se diseñó para administrar máquinas remotas. Practicar desde tu PC hacia un servidor que está a kilómetros de distancia simula exactamente lo que harás en el mundo profesional.
- El Botón del «Pánico»: Si configuras mal el firewall y te quedas fuera, o si borras algo crítico por error, no tienes que formatear tu ordenador personal. En un VPS, simplemente haces clic en «Reinstall OS» y en 30 segundos tienes un servidor nuevo y limpio.
- IP Pública Propia: Un VPS te da una dirección IP accesible desde cualquier parte del mundo. Esto te permite practicar conceptos avanzados como el túnel SSH, redirección de puertos y seguridad contra ataques reales (verás que, en cuanto lo enciendas, bots de todo el mundo intentarán entrar).
- Accesibilidad Económica: Hoy en día hay opciones muy baratas (o incluso capas gratuitas en proveedores como Oracle Cloud, AWS o Google Cloud) que son perfectas para estudiantes.
¡Quédate tranquilo! La mayoría de los administradores de sistemas tienen «cicatrices de guerra» por haber configurado mal un archivo de SSH y perder el acceso. Hacer esto en un VPS es una anécdota; pero hacerlo en un servidor de producción física es un viaje a los infiernos.
Conexión segura y cifrada desde una terminal
Ahora que ya tenemos claro que es un servidor virtual, tenemos que entender que SSH es como abrir una ventana de comandos directamente dentro de tu VPS. Pero lo importante es cómo lo hace:
• Secure → la conexión va cifrada
• Shell → te da acceso a una terminal
• H → a través de la red (host remoto)
Es decir: SSH = una forma segura de entrar en tu servidor y escribir comandos como si estuvieras allí.
En vez de dar una trillada explicación teórica desde cero, vamos a hacerlo a la inversa, vamos a imaginar que alguien nos da los datos de acceso a un VPS ya configurado para que practiquemos, entonces, lo que hará será darnos unos datos similares a estos:
DATOS DEL SERVIDOR
Hosting: Dinahosting
Dominio: actumforense.es
IP: 82.98.000.000
Nombre del equipo / DNS: vls00000.dinaserver.com
S.O: Linux Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-1059-kvm x86_64)
CPUs: 8
RAM: 128 GB
Disco duro: 1 TB
USUARIOS & GRUPOS
actumforensesshteam -> capa de seguridad en el acceso ssh
actumforenseshellmaster -> usuario específico para conexión por ssh al server
* Conexión sin contraseña mediante clave ssh y cifrado EdDSA
CLAVES SSH & CONFIGURACIÓN SSHD
clave EdDSA pública:
ssh-ed123456789123456789eddsa-key-123456789123456789
clave EdDSA privada:
<ruta_a_la_carpeta_de_usuario>\.ssh\privatekey (se transporta en una llave USB externa bajo la ruta:
E:\Actum_Forense\+SERVIDOR\)
EXPLICACIÓN ¿Qué nos han dado?:
La IP pública (82.98.000.000)
El nombre DNS (vls00000.dinaserver.com)
La IP es como el número de teléfono del servidor.El nombre DNS es como el nombre del contacto en tu agenda. Ambos llevan al mismo sitio, pero uno es más fácil de recordar
Para conectarte por SSH necesitas tres piezas:
- A dónde conectarte → IP o DNS
- Con qué usuario → en tu caso
actumforenseshellmaster - Cómo demostrar que eres tú → tu clave privada EdDSA
Nuestro amigo, benefactor o el proveedor ha configurado el servidor de esta manera:
actumforensesshteam→ una capa de seguridad (probablemente fail2ban, firewall, o reglas de acceso)actumforenseshellmaster→ el usuario autorizado- acceso sin contraseña → solo con clave privada
- Cifrado EdDSA → un tipo moderno de clave SSH, más seguro que RSA
*verás que no hay contraseña, podríamos usarla perfectamente pero dada la incomodidad de introducirla ‘a ciegas’ en la consola, en muchas ocasiones los administradores optan por obviarla si saben hacerlo, así que de momento no la usaremos hasta la próxima clase para simplificar el proceso(si en tu caso, vas a usar un servidor al que le han asignado una contraseña, te hará falta ponerla una vez te autentifiques)
¿Dónde almacenamos la clave privada EdDSA?
Esta almacenada en una llave usb removible en la dirección: E:\Actum_Forense\+SERVIDOR\
La clave privada es como una llave física para abrir la puerta del servidor.
Sin ella, nadie puede entrar, ni siquiera con el usuario correcto.
Eso significa que solo cuando conectamos la memoria USB se puede acceder al VPS. Podríamos tenerla almacenada en un ordenador, pero entonces el riesgo de que alguien pueda acceder hackeando nuestro equipo se multiplica. Tenerla físicamente desconectada excepto cuando accedemos multiplica nuestra seguridad exponencialmente.
Es decir, SSH necesita saber dónde está tu clave privada para usarla, y esta clave privada se llama en nuestro caso: privatekey
ACCEDIENDO DESDE LA TERMINAL
Lo primero ahora es ver desde que sistema operativo accederemos, lo normal sería Linux, pero es muy probable que muchos de los lectores más principiantes uses Windows o Apple, así que comenzaremos con este SO de fácil acceso. Es importante que usar el sistema de Microsoft cambia ligeramente los comandos y el flujo de trabajo respecto a un Linux que es el principal entorno profesional para estas cuestiones aunque ro no es relevante para nuestro propósito inicial.
Nuestro Windows necesita un “programa SSH”
En Windows hay dos formas principales de usar SSH:
- PowerShell / CMD, que ya traen SSH integrado
- PuTTY, un programa externo muy usado
Con PowerShell no hay que instalar nada, PuTTY es más visual, con ventanas y botones. Así que más adelante igual usar una de estas aplicaciones te resulta interesante pero para comenzar nada mejor que el querido/odiado PowerShell de Windows y evitamos complicarnos la vida.
1 — Indicar a PowerShell dónde está tu clave privada
En nuestro caso la clave privada está en la memoria USB por seguridad, (suponiendo que accedemos desde la unidad E:) así que:
E:\Actum_Forense\+SERVIDOR\privatekey
Para que PowerShell pueda usarla, normalmente la clave suele estar en la carpeta estándar de SSH:
C:\Users\<TU_USUARIO>\.ssh\
Pero nosotros por seguridad NO queremos copiarla al disco, porque la idea es que solo exista en la USB para dificultar que nadie se apropie de ella.
Entonces usaremos otra opción: decirle explícitamente a PowerShell dónde está la clave, sin moverla.
Eso se hace con el parámetro -i
ssh -i "RUTA_DE_LA_CLAVE" usuario@servidor
es decir:
ssh -i «E:\Actum_Forense\+SERVIDOR\privatekey» usuario@servidor
2 — Construir el comando SSH
Con nuestros datos, el comando sería:
ssh -i «E:\Actum_Forense\+SERVIDOR\privatekey» actumforenseshellmaster @82.98.000.000
o usando el DNS:
ssh -i «E:\Actum_Forense\+SERVIDOR\privatekey» actumforenseshellmaster @vls00000.dinaserver.com
3 — Comprobar permisos de la clave privada
PowerShell y OpenSSH en Windows a veces rechazan una clave si los permisos del archivo son demasiado “abiertos”.
La clave debe ser solo legible por ti.
En Windows esto se comprueba así:
- Botón derecho sobre
privatekey - Propiedades
- Seguridad
- Debe aparecer solo tu usuario con permisos de lectura (y no “Todos”, “Usuarios”, etc.)
4 — Probar la conexión sin ejecutarla del todo
Antes de intentar entrar al servidor, es buena práctica comprobar que PowerShell reconoce la clave y entiende el comando SSH.
Hay un modo seguro de hacerlo:
usar la opción -v (verbose), que no cambia nada del acceso, pero te muestra en pantalla qué está haciendo SSH.
El comando nos quedaría sí con nuestra ruta:
ssh -v -i «E:\Actum_Forense\+SERVIDOR\privatekey» actumforenseshellmaster @82.98.000.000
Cuando lo ejecutes, verás muchas líneas de diagnóstico, como:
- “Offering public key…”
- “Authenticating with public key…”
- “Trying private key…”
Esto nos permite ver si la clave se está usando correctamente antes de que intente entrar.
No te preocupes: si algo falla, no has dañado nada en el servidor. Solo nos informa.
5 — Hacer la conexión real
Si la prueba ha ido bien, ya podemos usar el comando sin -v, que es la forma normal de entrar:
ssh -i "E:\Actum_Forense\+SERVIDOR\\privatekey" actumforenseshellmaster @82.98.000.000
Si todo está bien, deberías ver algo como:
- Un aviso la primera vez preguntando si confiamos en la huella del servidor
- Luego aparecerá un prompt tipo:
actumforenseshellmaster @vps:~$
Y ya estaríamos dentro del servidor!
6 — ¿Cómo sabemos que realmente estamos “dentro”?
Cuando entramos por SSH, la terminal cambia de “estar en Windows” a “estar en Linux”.
La forma más sencilla de comprobarlo es con un comando muy básico:
whoami
En Windows te diría tu usuario de Windows. En el servidor te dirá:
actumforenseshellmaster
7 — ¿Y la frase “Enter passphrase for key…”?
Podemos preguntarnos ¿Por qué no nos pidió ninguna clave? y la respuesta es que la idea clave es: SSH nunca pide la clave privada
Esto es lo más importante:
La clave privada no se escribe, no se teclea, no se introduce.SSH la usa automáticamente desde el archivo.
La clave privada no es una contraseña. Es un archivo que el programa SSH lee para demostrar tu identidad.
Por eso:
- No nos pide “introduce tu clave privada”
- No nos pide “escribe tu contraseña”
- No nos pide nada
Simplemente usa el archivo que tú le indicaste con -i.
¿Entonces qué pide SSH normalmente?
SSH solo pide algo si falta uno de estos elementos:
- Clave privada
- Permisos correctos
- Clave pública instalada en el servidor
- Usuario autorizado
Como nosotros ya teníamos todo configurado correctamente, SSH no necesita preguntarte nada.
Es como si llegáramos a una puerta con una llave física; No te preguntan “¿cuál es tu llave?”
Simplemente la metes en la cerradura y abre.
Ahora bien puede ocurrir que nos salga esta línea:
Enter passphrase for key…
Esa solo aparece si la clave privada está protegida con passphrase.
Nuestra clave privada no tiene passphrase, así que SSH no te pide nada y ya estamos dentro de nuestro servidor. Y hasta aquí por hoy.
En la próxima entrada aprenderemos que son las cosas básicas que podemos hacer a través de de la terminal remota en un servidor y la famosa y molesta contraseña de acceso. Nos vemos!
Autor: Manuel Castelló
Deja una respuesta