Logon Action not working

[chuckmdonaldson]

I have added a simple logon action to do the following:

expect: #
send: bash

It is not working. Nothing happens. Any ideas?

I am running 6.7.1.

[MrC]

Are you trying to automatically launch the bash shell as a sub-shell immediately upon login?

You are likely already running bash, and auto-entering bash just starts a new shell. Type 'exit' once logged in. If my theory is correct, only the sub-shell exits and you're still connected.

[chuckmdonaldson]

Yes, I am trying to automatically launch a bash sub-shell upon logging in. It is definitely not working.

I am logging in as root and the shell is ksh. Bash does not get executed.

I also have two ways of logging into these servers. One way is through a jump box in which I use an expect script and it all works fine. The second way is direct via VPN using logon actions and this is where I am having the problem.

[rtb]

Hi chuckmdonaldson,

Do you actually see "bash" appear in the terminal window where you would expect it to appear?

If not, then you may need to wait for something that is more unique than "#".

Can you post the output that you see when attempting to connect to this remote device?

[chuckmdonaldson]

Nothing actually happens.

Here is what I have to choose from when I log in, after the @ symbol is the hostname and will change from server to server.

[root@akrsupcrfp01: / ]
#

[rtb]

Hi chuckmdonaldson,

Since you do not see the word "bash" appear after the "#", it is likely that the command is being sent prior because the "#" character appears more than once.

Since the Expect/Send functionality is so limited, you may want to consider using a Python script to accomplish your goal.

You could wait for "[root@" or ": / ]" if those are unique strings that do not appear prior to the prompt. You would then wait for the "#", and then you would send "bash" followed by a carriage return.

Have you considered using a Python login script rather than the Expect/Send sequence?

[MrC]

Hmmm, why not just change your login shell?

Or, why not add a command in your ksh profile that exec's bash, but only for the interactive login shell?

[chuckmdonaldson]

I have tried several things in the expect sequence.

#
root
: / ]

None of them work and they are unique.

I have not considered python as I am not familiar with that scripting language and this should be fairly simple to setup.

[MrC]

Have you moved your rule to the top of the list (or removed the default login and password entries)? These work in order. This works fine for me here.

[chuckmdonaldson]

Originally Posted by MrC

Hmmm, why not just change your login shell?

Or, why not add a command in your ksh profile that exec's bash, but only for the interactive login shell?

I can't do the above things as these are customer servers and I don't have the authority to do so.

[rtb]

Hi chuckmdonaldson,

Understandable. We often find that the shell cannot be changed for this reason.

Would you be able to send a raw log reflecting the complete manual connection process when connecting to a server using the VPN?

If so, here are the steps to generate a raw log:

1. Before connecting with the session, select Raw Log Session from SecureCRT's File menu.
   
2. In the Select Log File dialog, choose a folder and filename in which you would like the log text to be stored and click the Save button. At this point, if you open the File menu, you will notice that Raw Log Session now has a check-mark next to it; this indicates that raw logging is activated.
   
3. Now connect to the remote machine and perform the actions which cause the reported problem to occur.
   
4. Disconnect the session and select Raw Log Session from the File menu to turn off the raw log feature.
   
5. Browse to the location of the raw log file and attach it to your message.

What operating system are you using where SecureCRT is installed?

Would you also send the complete Expect/Send sequence you are using (please remove any sensitive data)?

Please send this to support@vandyke.com with a subject of Attn: Todd - Forum thread 8579.

[chuckmdonaldson]

RESOLVED!!!

Thank you! The issue was the default login/password entries.

[rtb]

Hi chuckmdonaldson,

I am glad to hear that MrC's suggestion resolved the issue.