TACACS+ authentication, telnet vs. ssh

Unanswered Question
Mar 26th, 2008
User Badges:

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?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Richard Burts Thu, 03/27/2008 - 05:55
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

gkuzmowycz Thu, 03/27/2008 - 06:30
User Badges:

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.


gkuzmowycz Thu, 03/27/2008 - 07:09
User Badges:

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.



cisco24x7 Thu, 03/27/2008 - 07:24
User Badges:
  • Silver, 250 points or more

"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

[email protected]'s password:

Last login: Thu Mar 27 13:45:53 2008 from 192.168.1.140

[[email protected]]#


Clearly, a user name is NOT required here.


CCIE Security


Actions

This Discussion