Acceso Remoto Seguro (SSH vs. Telnet)
Una vez que el dispositivo tiene dirección IP en una interfaz (o en una VLAN de administración), se puede administrar por red con Telnet o SSH. La elección correcta siempre es SSH, porque cifra la comunicación.
Telnet vs. SSH
Section titled “Telnet vs. SSH”| Característica | Telnet | SSH |
|---|---|---|
| Puerto | 23 | 22 |
| Cifrado | Ninguno (texto plano) | Sí (clave simétrica negociada) |
| Autenticación | Usuario/contraseña sin cifrar | Cifrada (y opcionalmente con claves) |
| Integridad | No | Sí (MAC / HMAC) |
| Riesgo | Credenciales e inspección | Bajo |
| Uso actual | Evitar; legacy, laboratorio | Estándar de administración remota |
Con Telnet cualquiera que capture el tráfico de red ve las contraseñas en claro. Por eso Cisco desaconseja su uso en equipos de producción.
Requisitos para SSH en IOS
Section titled “Requisitos para SSH en IOS”Antes de generar las claves de cifrado se necesitan tres cosas:
- Hostname definido (no puede ser el default
Router/Switch). ip domain-name: dominio (ej.empresa.local) que completa el nombre de host para generar las claves.- Clave RSA generada con
crypto key generate rsa.
Además hay que tener credenciales de acceso (usuario local o AAA) y habilitar SSH en las líneas VTY.
Configuración completa de SSH
Section titled “Configuración completa de SSH”Router> enableRouter# configure terminalRouter(config)# hostname R1-OficinaR1-Oficina(config)# ip domain-name empresa.localR1-Oficina(config)# crypto key generate rsa general-keys modulus 2048The name for the keys will be: R1-Oficina.empresa.local...%SSH-5-ENABLED: SSH 2.0 has been enabledR1-Oficina(config)# ip ssh version 2R1-Oficina(config)# username admin secret ClaveFuerte!R1-Oficina(config)# line vty 0 4R1-Oficina(config-line)# transport input sshR1-Oficina(config-line)# login localR1-Oficina(config-line)# exitR1-Oficina(config)# endExplicación paso a paso:
| Comando | Función |
|---|---|
ip domain-name empresa.local |
Dominio para el nombre completo del equipo |
crypto key generate rsa |
Genera las claves RSA; habilita SSH en el equipo |
ip ssh version 2 |
Fuerza SSHv2 (más seguro que v1) |
username admin secret ... |
Crea un usuario local con contraseña |
line vty 0 4 |
Entra a las líneas de acceso remoto |
transport input ssh |
Solo acepta SSH (rechaza Telnet) en las VTY |
login local |
Autentica contra los usuarios locales |
El parámetro
modulusde la clave RSA debe ser de al menos 1024 bits (2048 recomendado). Si el equipo ya tiene claves, IOS pregunta si deseas reemplazarlas.
¿Por qué hace falta un dominio para generar la clave?
Section titled “¿Por qué hace falta un dominio para generar la clave?”SSH no genera una clave RSA “genérica” del equipo: la asocia a un nombre
completo (FQDN — Fully Qualified Domain Name), que se arma uniendo el
hostname con el ip domain-name. En el ejemplo, R1-Oficina +
empresa.local da R1-Oficina.empresa.local, que es justamente el nombre que
IOS muestra al generar la clave (The name for the keys will be: R1-Oficina.empresa.local). Por eso el dominio no es opcional ni cosmético:
sin él, IOS no tiene con qué nombre asociar la clave y crypto key generate rsa no la genera.
Ese mismo FQDN es reutilizable después: si hay un servidor DNS que resuelve
R1-Oficina.empresa.local a la IP del equipo, te podés conectar por ese
nombre en vez de memorizar la IP.
Verificar SSH
Section titled “Verificar SSH”R1-Oficina# show ip sshSSH Enabled - version 2.0Authentication timeout: 120 secs; Authentication retries: 3
R1-Oficina# show ip ssh connectionsR1-Oficina# show sshConectarse a un dispositivo con SSH
Section titled “Conectarse a un dispositivo con SSH”Desde un equipo IOS (o cualquier cliente SSH), se usa el comando ssh:
R1-Oficina# ssh -l admin 192.168.1.2Password:R2-Sucursal>Para conectarse desde un PC se usa un cliente SSH (PuTTY, Terminal, OpenSSH) hacia la dirección IP de administración del equipo, o hacia su FQDN si hay DNS que lo resuelva — la razón por la que el dominio importa, retomando la sección anterior:
ssh admin@192.168.1.2 # por IP, siempre funcionassh admin@R1-Oficina.empresa.local # por FQDN — requiere que DNS resuelva ese nombressh -l admin R1-Oficina # por hostname corto — el cliente debe asumir el dominio localLa sintaxis -l usuario destino y usuario@destino son equivalentes; cuál
usar depende del cliente SSH que tengas a mano.
Configuración mínima con Telnet (solo laboratorio)
Section titled “Configuración mínima con Telnet (solo laboratorio)”Telnet solo necesita contraseña en las líneas VTY. Se muestra por contraste, pero no se recomienda en redes reales:
R1-Oficina(config)# line vty 0 4R1-Oficina(config-line)# password cisco123R1-Oficina(config-line)# loginR1-Oficina(config-line)# transport input telnetPreguntas tipo CCNA
Section titled “Preguntas tipo CCNA”-
¿Por qué SSH reemplaza a Telnet? Porque Telnet envía datos y credenciales en texto plano y SSH cifra toda la comunicación (puerto 22).
-
¿Qué tres requisitos se necesitan antes de
crypto key generate rsa? Un hostname no default, unip domain-namey accesos (líneas VTY) que permitan usar SSH. -
¿Qué comando limita las VTY a conexiones SSH únicamente?
transport input sshenline vty. -
¿Para qué sirve
login localen las líneas VTY? Para que la autenticación use los usuarios locales definidos conusername ... secret ...en lugar de una contraseña compartida. -
¿Por qué es obligatorio configurar
ip domain-nameantes de generar la clave RSA? Porque la clave se asocia al nombre completo del equipo (FQDN = hostname + domain-name); sin dominio, IOS no puede armar ese nombre y no genera la clave.
Resumen
Section titled “Resumen”- SSH (puerto 22) cifra la administración remota; Telnet (puerto 23) no.
- Para SSH se necesitan: hostname,
ip domain-name, clave RSA y credenciales. - El
ip domain-nameno es solo para las claves: junto al hostname forma el FQDN por el que también se puede conectar, si hay DNS. transport input sshen las líneas VTY bloquea Telnet y solo permite SSH.login localautentica contra usuarios locales del equipo.- Siempre usa
enable secret,service password-encryptiony SSH en producción.