Muchos routers típicamente se configuraron para permitir acceso remoto mediante Telnet. Telnet constantemente ha recibido críticas porque todo es enviado en texto plano. Por lo tanto si alguien ejecuta un sniffer y captura una petición de autenticación válida, un ciberatacante puede capturar la contraseña y acceder remotamente hacia el router. Basado sobre este riesgo, frecuentemente se recomienda utilizar SSH para acceder remotamente hacia los routers, porque toda la información está ahora encriptada. Esto presenta dos potenciales problemas y retos. Primero, para ejecutar SSH, librerías criptográficas deben ser instaladas y configuradas. Dado algunos routers pequeños tienen hardware y poder de cómputo limitado, esto presenta un reto en algunos casos. Ejecutar SSH no siempre es una opción sobre todos los routers.
El segundo problema es únicamente conmutar hacia SSH no resuelve el problema fundamental. El problema fundamental con acceder remotamente al router no es el ciberatacante pueda obtener la contraseña, sino un ciberatacante puede realizar fuerza bruta a la contraseña, pues las contraseñas no son frecuentemente muy complejas, no se cambian con frecuencia, no tienen bloqueo implementado, y son las mismas contraseñas utilizadas a través de toda la organización. Por lo tanto simplemente cambiar desde Telnet hacia SSH utilizando autenticación con contraseña proporciona a las organizaciones una falsa sensación de seguridad, pero no arregla el problema.
Para arreglar el problema de las contraseñas con SSH, se necesita utilizar certificados digitales o llaves previamente compartidas. El problema es esto añade recursos adicionales al router. Sin embargo en la mayoría de los casos, si un router admite e implementa SSH, puede generalmente soportar certificados o llaves previamente compartidas.
Fuentes:
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/…
https://www.cisco.com/c/es_mx/support/docs/ip/telnet/200718-Configure-T…