Using jump server

[NeRFuX]

Hi,

We are using a Ubuntu as a jumpserver, and users need to have SSH key to authenticate.

When I have setup this, I'm able to connect to the linux server, but CLI Analyzer do not insert the command for ssh to the device I'm trying against.

I have also tried to modify the "Commands" and expect, under Jump Server Profile to match the prompt on the Linux host.

I'm not able to find any log /debug that indicates that the software have problem parsing the Commands to the shell

Is this a bug or is there something that I'm missing out on?

[kevwilso]

Hi Ole,

Can you post your Jump Server configuration and we'll take a look.

Thanks,

Kevin W.

[NeRFuX]

Here is a sceenshoot of the configuration.

[kevwilso]

Ole,

Thanks for the picture.  We need one more thing.  Can you turn on automatic logging and capture the initial login.  Also, what version of CLI Analyzer are you using?

Thanks,

Kevin W

[NeRFuX]

Here is the log from the session.

As you can see, there is nothing inserted after the login.

I'm using v3.4.0

[Steve Rodrigue]

I have the exact same problem. Looks like the scripts lines won't kick in.

I suspect a problem with the dollar sign ($) on the first expect line to be the cause of the issue...

expect "[$username@xxxxxxx ~]\$"    <---- I even tried to escape the character without success.
send "ssh $username@$hostname -p $port\r"
expect "Password:"
send "$password\r"

[Steve Rodrigue]

It may also be related to the server prompt...

Last login: Fri Jul 21 16:03:10 2017 from xxxxx.domain.com

[username@jumpserver ~]$

^^^^ 

This is the exact prompt I get when I log to my jump server.

[Steve Rodrigue]

I can reproduce the problem, I mess a bit with the script...

When I manually log into my switch, I can see that the expect script is executed AFTER I get login to my equipment. Looks like the script kick in only when it sees a "#".

Example:

[username@jumpserver ~]$ ssh router

Access to this device or the attached networks is prohibited

without express written permission. Violators will be

prosecuted to the fullest extent of both civil and criminal law.

L'acces a ce peripheque ainsi qu'aux reseaux qui y sont connectes

est interdit sans autorisation acrite. Les contrevenants seront

poursuivis en vertue des lois civiles et penales.

Password:

Cisco Nexus Operating System (NX-OS) Software

TAC support: http://www.cisco.com/tac

Copyright (c) 2002-2014, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained in this software are

owned by other third parties and used and distributed under

license. Certain components of this software are licensed under

the GNU General Public License (GPL) version 2.0 or the GNU

Lesser General Public License (LGPL) Version 2.1. A copy of each

such license is available at

http://www.opensource.org/licenses/gpl-2.0.php and

http://www.opensource.org/licenses/lgpl-2.1.php

router# \n\n\nssh username@router -p 22

^

% Invalid command at '^' marker.

router#

[cmagnum]

Hi Steve,

I noticed you are using $username in your expect. We currently only support putting $username, $password, $hostname and $port variables in send statements, not expect statements. Expect statements are just a literal string comparison at this time.

Thanks,

Chris M.

[NeRFuX · Accepted solution]

Hi, 

I looked at this together with an developer at Cisco now. And in my case the problem was:

1. I had inserted an enable password in the jump server credential profile. This makes the CLI Analyzer able to login, but is waiting for the "hostname>enable"- prompt  (like if you use a Cisco device as jump server). This will not work if you are using a linux box. 

Removing this password fixed the problem were nothing was happening when you were connected successfully to the jump server. 

2. The expect waited for "Password" when its connect do a device, but since we have configure TACACS password are written in lowercase. So this was fixed by just chaning the expect to look for password in lowercase. 

[weylin.piegorsch]

I would think regular expression support might help here.  I'm havng an issue whereby some devices provide a "password" prompt, other provide a "Password" prompt - note the difference in upper/lower case.

Unfortunately, at the moment it looks like the jump server expect processor is doing a search for a specific string, except for certain specific character that it doesn't allow.

I've opened TAC case 682770245 to try to get a better answer on how this is "supposed" to behave.  One approach is to have a jump server profile that varies between different states.  However, for something as simple as a difference in uppercase / lowercase, having different jump server profiles is an inelegant and ugly hack. (Yes, I could just drop the p from the expect string, but that's equally as stupid.)

We'll see what TAC comes back with.  If this is something that can't be done, I'll request to convert the TAC case to a feature request for either IOS-style regex or POSIX-style extended regex support; I think (in theory) that would also address the issue you're seeing here.

[kevwilso · Accepted solution]

Hi Weylin,

You can go ahead and close the case.  Regex processing on the Expect is in the development roadmap for Jump Server processing.

Thanks,

Kevin W.