La WLC estaba funcionando. La interfaz web cargaba bien. Mi usuario tenía privilegios administrativos y desde la UI podía ejecutar comandos sin mayor problema. Todo parecía normal… hasta que intenté entrar por SSH.
Me conectaba correctamente, el equipo aceptaba mi usuario y contraseña, pero al entrar no caía en modo privilegiado. En lugar de ver esto:
CONTROLLER-9800#
entraba así:
CONTROLLER-9800>
Y cuando intentaba elevar privilegios con:
enable
la WLC respondía:
% Error in authentication.
Ese mensaje, así solito, puede ser bastante engañoso. De entrada parece un problema de contraseña, de usuario, de SSH o incluso de permisos. Pero en este caso el detalle estaba en otro lado: la WLC sí me dejaba entrar, pero no tenía bien definido cómo autenticar el acceso privilegiado por SSH.
El escenario
El problema aparecía al entrar por SSH a una Cisco Catalyst 9800 Wireless LAN Controller. El acceso por web funcionaba, y desde la interfaz gráfica podía ejecutar comandos de diagnóstico.
El síntoma era exactamente este:
CONTROLLER-9800>enable
% Error in authentication.
Es decir, el usuario entraba en modo usuario, representado por el signo:
>
pero no podía pasar al modo privilegiado, representado por:
#
En equipos Cisco esto es importante porque el modo > es limitado. Puedes ver algunas cosas, pero no tienes control administrativo completo. Para configurar, revisar con más detalle o guardar cambios necesitas estar en modo privilegiado.
Primera sospecha: ¿el usuario no tiene privilegio 15?
Lo primero que revisé fue si el usuario local tenía privilegios administrativos.
Desde la interfaz web ejecuté:
show running-config | include username
La configuración mostraba usuarios locales con privilege 15, algo parecido a esto:
username admin privilege 15 secret 9 <HASH>
username usuario_admin privilege 15 secret 9 <HASH>
username soporte privilege 15 secret 9 <HASH>
Eso era importante.
En Cisco, privilege 15 es el nivel más alto de privilegio. En teoría, un usuario con ese nivel debería poder entrar directamente al prompt privilegiado:
CONTROLLER-9800#
o al menos poder elevarse sin problema usando:
enable
Pero no estaba pasando.
Ahí quedó claro que el problema no era simplemente “el usuario no es administrador”. El usuario sí existía y sí estaba configurado con privilegios altos.
Entonces había que mirar otra parte de la configuración.
Segunda pista: no había enable secret
Después revisé si la WLC tenía configurada una contraseña de enable.
El comando fue:
show running-config | include enable secret|enable password
Y no devolvió nada útil.
Eso significaba que no existía algo como:
enable secret <PASSWORD>
ni tampoco:
enable password <PASSWORD>
Aquí apareció una parte importante del problema.
Cuando uno entra en modo usuario:
CONTROLLER-9800>
y ejecuta:
enable
el equipo necesita validar ese salto hacia modo privilegiado. Si no tiene un enable secret configurado, o si AAA está esperando otro método de autenticación, puede terminar respondiendo:
% Error in authentication.
No porque SSH esté caído. No porque el usuario no exista. Sino porque el equipo no tiene una forma válida, o bien definida, de autenticar ese cambio de nivel.
Tercera pista: las líneas VTY no estaban usando el método local
Luego revisé la configuración de las líneas VTY:
show running-config | section line vty
La salida era parecida a esta:
line vty 0 4
length 0
transport input ssh
line vty 5 15
transport input ssh
A primera vista no se ve tan dramático. SSH estaba permitido, y eso explicaba por qué sí podía conectarme.
Pero faltaba algo clave.
No había una línea como:
login local
ni una como:
login authentication local_auth
Eso significa que las líneas remotas aceptaban SSH, pero no tenían aplicado de forma explícita el método de autenticación local que yo necesitaba.
Y como la WLC tenía AAA habilitado, ese detalle pesaba todavía más.
Revisión de AAA
También revisé la sección AAA:
show running-config | section aaa
La configuración tenía algo parecido a esto:
aaa new-model
aaa group server radius RADIUS_GROUP_NAC
server name RADIUS_SERVER_NAC
ip radius source-interface VlanX
deadtime 5
aaa authentication login AAA_AUTH_NAC group RADIUS_GROUP_NAC
aaa authentication login local_auth local
aaa authorization network default local
aaa login success-track-conf-time 24
aaa server radius dynamic-author
client 203.0.113.10
aaa session-id common
Nota rápida: los nombres e IPs anteriores están anonimizados. La idea es mostrar la estructura sin exponer datos reales de infraestructura, proveedores, pruebas NAC o direcciones públicas.
En esa configuración había una línea muy importante:
aaa authentication login local_auth local
Esa línea significa:
Crea un método de autenticación llamado local_auth y usa la base de usuarios locales del equipo.En pocas palabras: la WLC ya tenía una “receta” para autenticar usuarios locales.
El problema es que esa receta no estaba aplicada a las líneas VTY.
Es como tener la llave correcta guardada en un cajón, pero la puerta por donde estás entrando no está configurada para usar esa llave.
La solución que funcionó
La corrección fue configurar dos cosas:
- Una contraseña de
enable secret. - Aplicar el método de autenticación local a las líneas VTY.
El bloque final quedó así:
conf t
enable secret TU_PASSWORD_SEGURO
line vty 0 4
login authentication local_auth
transport input ssh
line vty 5 15
login authentication local_auth
transport input ssh
end
write memory
Después de eso, cerré la sesión SSH, volví a entrar y el problema quedó resuelto.
Ya podía entrar correctamente con mi usuario local y usar privilegios administrativos.
Qué hace cada comando
Vamos por partes, porque aquí está lo más interesante.
Entrar a configuración global
conf t
Este comando entra al modo de configuración global.
Es el modo donde puedes modificar la configuración activa del equipo. Sin esto, solo estarías consultando información o ejecutando comandos operativos.
Configurar enable secret
enable secret TU_PASSWORD_SEGURO
Este comando define la contraseña que permite pasar de modo usuario:
CONTROLLER-9800>
a modo privilegiado:
CONTROLLER-9800#
La palabra secret importa. En Cisco es preferible usar:
enable secret
en lugar de:
enable password
porque enable secret guarda la contraseña de forma protegida en la configuración.
Antes de configurar esto, al ejecutar:
enable
la WLC no tenía una contraseña válida para autenticar el salto de privilegios. Por eso devolvía:
% Error in authentication.
Configurar las líneas VTY 0 a 4
line vty 0 4
Las líneas VTY son las líneas virtuales que se usan para acceso remoto, como SSH.
Cuando entras por SSH a un equipo Cisco, realmente estás ocupando una línea VTY. El rango 0 4 representa las primeras cinco sesiones remotas posibles.
Después se aplicó:
login authentication local_auth
Esta línea le dice al equipo:
Para los accesos remotos que entren por estas líneas, usa el método AAA llamado local_auth.Y ese método ya existía en la configuración:
aaa authentication login local_auth local
O sea, en español simple:
Cuando alguien entre por SSH, valida el usuario contra la base de usuarios locales del equipo.
Luego se mantuvo:
transport input ssh
Esto permite SSH como transporte de entrada para esas líneas.
Y eso está bien. De hecho, es lo recomendable. Telnet no debería usarse porque no cifra la comunicación.
Configurar las líneas VTY 5 a 15
line vty 5 15
login authentication local_auth
transport input ssh
La WLC tenía las líneas VTY divididas en dos bloques:
line vty 0 4
line vty 5 15
Por eso configuré ambos.
Esto es importante porque si solo corriges line vty 0 4, las primeras conexiones podrían funcionar, pero si esas líneas están ocupadas y una nueva sesión cae en el rango 5 15, podrías volver a tener el mismo problema.
En ambientes pequeños quizá nunca lo notes, pero en equipos de producción conviene dejar ambos rangos consistentes.
Salir de configuración
end
Este comando te saca del modo de configuración y te regresa al modo privilegiado.
Guardar la configuración
write memory
Este comando guarda la configuración actual.
Sin esto, el cambio funciona en la configuración activa, pero puede perderse si el equipo se reinicia.
También se puede usar:
copy running-config startup-config
Ambos cumplen la misma intención: guardar los cambios para que sobrevivan a un reinicio.
Entonces, ¿por qué antes funcionaba y luego dejó de funcionar?
Esta fue la parte que más me interesó, porque el equipo no estaba recién instalado. Antes el acceso por SSH había funcionado.
Hay varias posibilidades.
1. Antes existía un enable secret y se eliminó
Es posible que en algún momento la WLC sí tuviera configurado:
enable secret <PASSWORD>
y después se haya perdido por una restauración parcial, una plantilla, un cambio manual o una migración de configuración.
Cuando revisé:
show running-config | include enable secret|enable password
no apareció nada.
Eso confirmaba que, al menos en ese momento, el equipo no tenía contraseña de enable configurada.
2. Antes las líneas VTY sí usaban autenticación local
También es posible que antes existiera esta línea bajo line vty:
login authentication local_auth
o esta otra:
login local
Pero en la configuración actual ya no estaba.
La diferencia parece pequeña, pero no lo es.
Tener usuarios locales con privilege 15 no basta si las líneas por donde entras no están usando correctamente esa base local de usuarios.
En otras palabras:
username usuario_admin privilege 15 secret 9 <HASH>
dice que el usuario existe y es administrador.
Pero:
login authentication local_auth
le dice a SSH que use ese mecanismo para autenticarte.
Si esa segunda parte falta, el usuario puede existir perfectamente y aun así el acceso por SSH no comportarse como esperas.
3. AAA cambió el comportamiento
Cuando está activo:
aaa new-model
la administración de autenticación cambia.
AAA significa:
- Authentication
- Authorization
- Accounting
En cristiano: quién eres, qué puedes hacer y qué se registra de lo que haces.
En esta WLC existía un método local:
aaa authentication login local_auth local
y también un método relacionado con RADIUS/NAC:
aaa authentication login AAA_AUTH_NAC group RADIUS_GROUP_NAC
Eso no está mal. De hecho, es común tener autenticación local y autenticación externa.
El problema aparece cuando las líneas de administración remota no tienen claramente asignado qué método deben usar.
La interfaz web puede seguir funcionando porque no necesariamente usa exactamente el mismo flujo que SSH. Por eso desde la UI podía ejecutar comandos, pero por SSH quedaba atorado en modo usuario.
Y esa es una trampa común: que algo funcione desde la web no significa que el acceso por SSH esté bien configurado.
La diferencia entre UI y SSH
Este punto vale la pena explicarlo.
En una WLC 9800 puedes tener acceso administrativo desde la interfaz gráfica y, al mismo tiempo, tener una configuración incompleta o rota para acceso por SSH.
La UI puede autenticarte por su propio flujo, mientras que SSH depende de las líneas VTY y de AAA.
Por eso un usuario podía existir como:
username usuario_admin privilege 15 secret 9 <HASH>
y aun así, al entrar por SSH, terminar en:
CONTROLLER-9800>
El usuario no era el problema principal.
El problema era la ruta de autenticación usada por SSH.
Cómo quedó antes y después
Antes tenía algo parecido a esto:
aaa new-model
aaa authentication login local_auth local
line vty 0 4
length 0
transport input ssh
line vty 5 15
transport input ssh
Y además no había:
enable secret
Eso dejaba el acceso SSH en una situación medio incompleta.
Después quedó así:
aaa new-model
aaa authentication login local_auth local
enable secret <PASSWORD>
line vty 0 4
length 0
login authentication local_auth
transport input ssh
line vty 5 15
login authentication local_auth
transport input ssh
La diferencia real fue esta:
enable secret <PASSWORD>
y esta:
login authentication local_auth
Con eso, SSH ya sabía cómo autenticar usuarios locales y el equipo ya tenía una contraseña válida para el modo enable.
Comandos útiles para diagnosticarlo
Si a alguien le pasa lo mismo, estos son los comandos que revisaría primero.
Ver si existe enable secret
show running-config | include enable secret|enable password
Si no devuelve nada, probablemente no tienes contraseña de enable configurada.
Ver los usuarios locales
show running-config | include username
Busca que el usuario tenga privilege 15, por ejemplo:
username admin privilege 15 secret 9 <HASH>
Si el usuario no tiene privilege 15, puede entrar con permisos limitados.
Ver la configuración AAA
show running-config | section aaa
Busca si existe algo como:
aaa new-model
aaa authentication login local_auth local
Si tienes RADIUS, TACACS o NAC, también revisa qué método está usando la administración.
Una versión anonimizada de una configuración con RADIUS podría verse así:
aaa new-model
aaa group server radius RADIUS_GROUP_NAC
server name RADIUS_SERVER_NAC
ip radius source-interface VlanX
deadtime 5
aaa authentication login AAA_AUTH_NAC group RADIUS_GROUP_NAC
aaa authentication login local_auth local
aaa authorization network default local
aaa login success-track-conf-time 24
aaa server radius dynamic-author
client 203.0.113.10
aaa session-id common
Lo importante aquí no es el nombre del grupo ni la IP. Lo importante es identificar si existe un método local, como:
aaa authentication login local_auth local
y si ese método realmente está aplicado al acceso por SSH.
Ver las líneas VTY
show running-config | section line vty
Una configuración funcional usando el método local_auth debería verse más o menos así:
line vty 0 4
login authentication local_auth
transport input ssh
line vty 5 15
login authentication local_auth
transport input ssh
Si no aparece login authentication ... o login local, ahí puede estar el problema.
Solución base recomendada
Si ya tienes usuarios locales con privilegio 15 y un método AAA local llamado local_auth, puedes usar algo así:
conf t
enable secret TU_PASSWORD_SEGURO
line vty 0 4
login authentication local_auth
transport input ssh
line vty 5 15
login authentication local_auth
transport input ssh
end
write memory
Si no tienes definido el método local_auth, primero tendrías que crearlo:
conf t
aaa authentication login local_auth local
end
write memory
Y luego aplicarlo a las líneas VTY.
Alternativa más simple sin método AAA nombrado
En algunos equipos, si quieres usar autenticación local de forma más directa, podrías configurar:
conf t
enable secret TU_PASSWORD_SEGURO
line vty 0 15
login local
transport input ssh
end
write memory
Pero si ya tienes aaa new-model activo y métodos definidos, me gusta más dejarlo explícito con:
login authentication local_auth
porque es más claro, más ordenado y menos ambiguo.
Cuidado si usas RADIUS, TACACS o NAC
Aquí hay que ir con calma.
Si tu WLC usa RADIUS, TACACS, Cisco ISE o algún sistema NAC para administración o control de acceso, no conviene cambiar AAA a ciegas. Puedes dejar fuera a otros administradores o romper un flujo que sí estaba funcionando para otros accesos.
En este caso, la idea no fue desactivar RADIUS ni quitar AAA. La solución fue mucho más concreta:
Aplicar a las líneas VTY el método local que ya existía y configurar una contraseña de enable.Eso redujo el riesgo.
No toqué innecesariamente el método de autenticación usado para pruebas NAC, ni cambié el grupo RADIUS, ni modifiqué políticas inalámbricas.
Qué aprendí de este caso
Este problema me dejó una idea bastante clara: en redes, muchas veces el error visible no es el error real.
El mensaje decía:
% Error in authentication.
Pero no era simplemente “contraseña incorrecta”.
La WLC aceptaba mi usuario. SSH funcionaba. La UI funcionaba. Los usuarios locales existían. El privilegio 15 estaba configurado.
El problema estaba en la unión de piezas:
- no había
enable secret; - las líneas VTY no estaban usando explícitamente
local_auth; - AAA estaba activo;
- la UI y SSH no se comportaban igual.
Y eso es justo lo que vuelve interesante este tipo de fallas. No se arreglan solo probando otra contraseña. Se arreglan entendiendo el camino completo: cómo entra el usuario, qué método AAA se aplica, qué privilegios recibe y cómo se guarda la configuración.
Conclusión
Si en una Cisco WLC 9800 puedes entrar por SSH, pero al ejecutar:
enable
recibes:
% Error in authentication.
no te quedes solo con la idea de que la contraseña está mal.
Revisa primero estas tres cosas:
show running-config | include enable secret|enable password
show running-config | include username
show running-config | section line vty
Y si usas AAA:
show running-config | section aaa
En mi caso, la solución fue configurar un enable secret y aplicar el método de autenticación local a las líneas VTY:
conf t
enable secret TU_PASSWORD_SEGURO
line vty 0 4
login authentication local_auth
transport input ssh
line vty 5 15
login authentication local_auth
transport input ssh
end
write memory
No fue un cambio grande. Fueron pocas líneas.
Pero esas pocas líneas hicieron que el acceso SSH dejara de quedarse a medias y volviera a comportarse como debía.
A veces, la diferencia entre un acceso roto y uno funcional no está en crear otro usuario, reiniciar el equipo o culpar a SSH. Está en revisar si las piezas correctas están conectadas entre sí.
Y en este caso, la pieza que faltaba era simple: la WLC tenía usuarios locales, tenía AAA, tenía SSH… pero las líneas VTY no estaban usando explícitamente el método correcto, y el equipo tampoco tenía una contraseña de enable.
Una falla pequeña, sí. Pero de esas que te pueden hacer perder bastante tiempo si no sabes dónde mirar.