Rivlogin modifications

[Mike McHenry]

Andrew,

We don't (as of yet) utilize Radius lookups on our Riverstone gear.
Perhaps it would be more helpful for me to give you access to one of my
pseudo-development Riverstone chassis so you can test out the SSH
sequence yourself. Please reply to me offline if you feel this would be
useful.

Here is an example login sequence on a RS3000 chassis running 9.1.2.8
code. Anything in << brackets >> indicates something typed in.

[mmchenry at unixhost]# << ssh -1 RIVERSTONEHOST >>


----------------------------------------------------------------------
RS 3000 System Software, Version 9.1.2.8
Copyright (c) 2000-2004 Riverstone Networks, Inc.
System started on 2004-10-11 20:18:49
----------------------------------------------------------------------


Press RETURN to activate console . . .
<< RETURN >>

Password: << login password >>
RIVERSTONEHOST> enable
Password: << enable password >>
RIVERSTONEHOST#

Where the initial prompt for password is being pulled from 
system set hashed-password login xxxxxxx

and the secondary enable password is pulled from 
system set hashed-password enable xxxxxxx

> 
> I've run into a couple of things;
> 
>   - Do you use RADIUS for auth in your shop?  The 'userpassword'
> variable doesn't seem to be consulted in the same way as the existing
> rivlogin.
> 
> e.g. my .cloginrc stanzas look like
> 
> add user host {afort}
> add userpassword host {radiuspass}
> add password host {initial_login_password} {last_resort_password}
> 
> The initial password works, but when asked for RADIUS credentials
> after that, we send the username but not the correct password.
> 
> It appears that the variable used for the 'last_resort_password',
> above, is being used for any 'Password:' prompt.
> 
> I changed this behaviour a few releases back, because:
> 
>   - riverstone/enterasys CLI OSes ask for the initial_login_password
> BEFORE radius.
>   - if radius is unreachable, you get a message indicating you need
> to use the last resort (enable) password now.
>   - the user password for RADIUS is of course a seperate password.
> 
> Thus I figured the most logical mapping was the one, above.
> So the logic changes to:
>   - if we have seen a 'username' prompt, we're in radius/tac+ mode.
>   - if we're in radius/tac+ mode, the password prompt is asking for
> the users' password.
>   - if we see the message indicating we cannot reach radius, use the
> last_resort.
> 
> However, SSH logins are probably different.  Can you send me an
> example SSH login dialgoue with the switch so I can better understand
> the choices made in your patch?
> 


I never had problems in my testing either when I removed the "Press
RETURN" expect sequence and I agree that it could probably be removed
safely.

>   - On EOS 8.3 (we're running ancient code for stability reasons),
> there is a max login banner length which precludes us using our
> regular banner plus the "Press RETURN to Begin" prompt (it's like 4
> lines, perhaps 255 chars).  In any event, this means that our
> switches don't provide the initial prompt that is expected.  So, I
> have removed the expect and just have the program sleep 0.3 and then
> send \r to the switch.  Though this removes the stop-and-wait
> behaviour, I've never found it to cause problems, at least not with
> telnet.
> 

My longest hostname is 16 characters long and I haven't run into any
apparent problems so far.

> One last question - what is the length of your _longest_ hostname on
> your switches, in characters?  The majority of terminal handling
> problems only appeared for me when using longer prompts (like, longer
> than about 9 characters, if my brain is working today).
> 
> thanks again,
> -andrew