03-26-2008
11:47 AM
- last edited on
03-25-2019
05:25 PM
by
ciscomoderator
I'm in the process of setting up TACACS+ AAA for our routers, which as a matter of policy use ssh instead of telnet for VTY access. It works correctly for telnet but not for ssh, though. The relevant parts of the config include
aaa new-model
!
aaa authentication login default group tacacs+ local
aaa authentication login ssh group tacacs+
aaa authorization exec default group tacacs+ if-authenticated
aaa session-id common
!
tacacs-server host nnn.nnn.nnn.nnn
tacacs-server directed-request
tacacs-server key 7 xxxxxxxxxxxxx
!
line vty 0 4
privilege level 15
transport input all
If I hit one of those VTY lines using telnet, the negotiation from the router's side starts like this
Mar 26 14:27:42.682: AAA/BIND(000001B5): Bind i/f
Mar 26 14:27:42.682: AAA/AUTHEN/LOGIN (000001B5): Pick method list 'default'
Mar 26 14:27:42.686: TPLUS: Queuing AAA Authentication request 437 for processing
Mar 26 14:27:42.686: TPLUS: processing authentication start request id 437
Mar 26 14:27:42.686: TPLUS: Authentication start packet created for 437()
Mar 26 14:27:42.686: TPLUS: Using server nnn.nnn.nnn.nnn
Note that in the second-to-last line the request id 437 has no user id. With ssh, though, Putty prompts me for my user id "locally", and generates the following
Mar 26 14:28:38.640: AAA/BIND(000001B6): Bind i/f
Mar 26 14:28:38.640: AAA/AUTHEN/LOGIN (000001B6): Pick method list 'default'
Mar 26 14:28:38.640: TPLUS: Queuing AAA Authentication request 438 for processing
Mar 26 14:28:38.640: TPLUS: processing authentication start request id 438
Mar 26 14:28:38.640: TPLUS: Authentication start packet created for 438(userid)
Mar 26 14:28:38.640: TPLUS: Using server nnn.nnn.nnn.nnn
where the request packet *has* the user id. This transaction fails.
How do I get past this?
03-27-2008 05:55 AM
George
I do not believe that the symptom that you describe reflects anything about your router config or about TACACS but is an aspect of how you are performing the access or is a protocol difference between telnet and SSH.
I believe that your second attempt has the userID because SSH always requires a user name and most SSH clients (like Putty) require the user name before the connection is attempted and present the user name as part of opening the connection. Telnet, on the other hand, does not require a user name up front and will wait until the authentication process prompts for it before giving the user name.
In your first attempt if the debug output continued it would have shown connecting to the server. And if that were successful it would have shown the server sending a prompt asking for user name. And if the user name were supplied there would have been a transaction from the router to the server which includes the user name as part of telnet authentication.
You seem to believe that the passing of the userID is the problem that causes SSH to fail. If the SSH transaction fails, I believe that it is for some reason other than the fact that there is a user name passed in the connection opening. You have not indicated whether the telnet attempt is successful or not and that would be a good thing to know if understanding the problem with SSH.
If you would provide a more complete output of the debug we might be able to identify the problem: (is the request getting to the server, does the server respond, does the server recognize the router as a valid client for TACACS, is the key correct). It would also be helpful to know if there is anything in the log on the server about the SSH attempt. If the server saw the SSH attempt there should be some indication in the log of what it thinks the problem is.
HTH
Rick
03-27-2008 06:30 AM
Thanks for the comprehensive response, Rick. I do indeed believe that this is the result of a protocol difference between telnet and SSH. I didn't include the full debugs because I was cognizant of the 4k limit and didn't want to deal with attachments. The telent session did succeed, as shown below (i've elided some of the detailed r/w socket lines)
Mar 26 14:27:42.682: AAA/BIND(000001B5): Bind i/f
Mar 26 14:27:42.682: AAA/AUTHEN/LOGIN (000001B5): Pick method list 'default'
Mar 26 14:27:42.686: TPLUS: Queuing AAA Authentication request 437 for processing
Mar 26 14:27:42.686: TPLUS: processing authentication start request id 437
Mar 26 14:27:42.686: TPLUS: Authentication start packet created for 437()
Mar 26 14:27:42.686: TPLUS: Using server nnn.nnn.nnn.nnn
Mar 26 14:27:42.686: TPLUS: Received authen response status GET_USER (7)
Mar 26 14:27:46.770: TPLUS: Queuing AAA Authentication request 437 for processing
Mar 26 14:27:46.770: TPLUS: processing authentication continue request id 437
Mar 26 14:27:46.770: TPLUS: Authentication continue packet generated for 437
Mar 26 14:27:46.770: TPLUS: Received authen response status GET_CHALLENGE_RESP_NOECHO (13)
Mar 26 14:27:55.062: TPLUS: Queuing AAA Authentication request 437 for processing
Mar 26 14:27:55.062: TPLUS: processing authentication continue request id 437
Mar 26 14:27:55.062: TPLUS: Authentication continue packet generated for 437
Mar 26 14:27:55.074: TPLUS: Received authen response status PASS (2)
Mar 26 14:27:55.074: TPLUS: Queuing AAA Authorization request 437 for processing
Mar 26 14:27:55.074: TPLUS: processing authorization request id 437
Mar 26 14:27:55.074: TPLUS: Protocol set to None .....Skipping
Mar 26 14:27:55.074: TPLUS: Sending AV service=shell
Mar 26 14:27:55.074: TPLUS: Sending AV cmd*
Mar 26 14:27:55.074: TPLUS: Authorization request created for 437(userid)
Mar 26 14:27:55.074: TPLUS: using previously set server nnn.nnn.nnn.nnn from group tacacs+
Mar 26 14:27:55.078: TPLUS: received authorization response for 437: PASS
The SSH session, on the other hand, produces this, and then times out after 4 unsuccessful password entries.
Mar 26 14:28:38.640: AAA/BIND(000001B6): Bind i/f
Mar 26 14:28:38.640: AAA/AUTHEN/LOGIN (000001B6): Pick method list 'default'
Mar 26 14:28:38.640: TPLUS: Queuing AAA Authentication request 438 for processing
Mar 26 14:28:38.640: TPLUS: processing authentication start request id 438
Mar 26 14:28:38.640: TPLUS: Authentication start packet created for 438(userid)
Mar 26 14:28:38.640: TPLUS: Using server nnn.nnn.nnn.nnn
Mar 26 14:28:38.644: TPLUS: Received authen response status GET_CHALLENGE_RESP_NOECHO (13)
I will try to see what I can get from the server side.
03-27-2008 07:09 AM
Rick, some more detail. Below is what I get form the server (this is the ClearBox server product, a Windows-based RADIUS/TACACS+ server).
The telnet progression looks like this:
3/27/2008 9:41:02 AM TACACS Authentication transaction
Authentication request
Received from [n.n.n.n]
UniqueID=93
Realm = REALM
Action = LOGIN
AuthenType = ASCII
PrivLevel = 15
AuthenService = LOGIN
User =
Port = tty98
RemAddr = m.m.m.m
Data =
Authentication response
Sent to [n.n.n.n]
UniqueID=94
Status = GET USER
Flags = 0
ServerMsg = Login:
Data =
3/27/2008 9:41:08 AM TACACS Authentication transaction
Authentication request (continue)
Received from [n.n.n.n]
UniqueID=95
Realm = REALM
Flags = 0
UserMsg = userid
Data =
Authentication response
Sent to [n.n.n.n]
UniqueID=96
Status = GET DATA
Flags = 1
ServerMsg = Password:
Data =
Notice that "user" comes in blank, and the server sends a "GET USER"
The SSH progression looks like this:
3/27/2008 9:44:13 AM TACACS Authentication transaction
Authentication request
Received from [n.n.n.n]
UniqueID=101
Realm = REALM
Action = LOGIN
AuthenType = ASCII
PrivLevel = 15
AuthenService = LOGIN
User = userid
Port = tty98
RemAddr = m.m.m.m
Authentication response
Sent to [n.n.n.n]
UniqueID=102
Status = GET DATA
Flags = 1
ServerMsg = Password:
Data =
Since "user" comes in populated, it sends a "Password:" prompt, but that's not getting back up to the SSH client. It looks like the router isn't passing it back, to me.
03-27-2008 07:24 AM
"I believe that your second attempt has the userID because SSH always requires a user name and most SSH clients (like Putty) require the user name before the connection is attempted and present the user"
It does? That's the first I've heard. I use
Putty everyday and this is what I see:
login as: admin
admin@192.168.1.1's password:
Last login: Thu Mar 27 13:45:53 2008 from 192.168.1.140
[Expert@P1-NGx]#
Clearly, a user name is NOT required here.
CCIE Security
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide