Beta Forum for the new SCRT?

[bgagnon]

Hi Robert,

Let's get timestamped trace options of the session that hangs and see if we can figure out why.

• Edit session to include custom data on each line of logging in the Terminal / Log File category of Session Options (%h:%m:%s:%t -- will give us format similar to shown below)
  
• Choose Log Session from File menu (supply name and location)
  
  The log file name can also be configured in same category mentioned above but start logging from the File menu instead of choosing Start log upon connect because the Session Options way does not include the initial negotiation information (including remote identifier).
  
  
• Choose Trace Options from the File menu
  
• Double-check there are checkmarks next to Trace Options and Log Session
  
• Connect session and take steps that cause issue
  
• Supply log file as an attachment to your response
  
  The timestamps will not appear in the terminal window, but should be logged.
  
  The output should look similar to:
  
  08:24:32:709 -- [LOCAL] : SSH2Core version 7.0.0.537
  08:24:32:709 -- [LOCAL] : Connecting to ###.###.###.###:22 ...
  08:24:32:709 -- SecureCRT - Version 7.0.4 (build 537)
  08:24:32:709 -- [LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
  08:24:32:709 -- [LOCAL] : Using protocol SSH2
  08:24:32:709 -- [LOCAL] : RECV : Remote Identifier = 'SSH-2.0-VShell_3_8_0_131 VShell'

Since trace options can contain sensitive information, feel free to send it as an attachment via email to support@vandyke.com. Please reference "Attn Brenda - Forum Thread #12235" in the subject line.

NOTICE: The requested troubleshooting data may include sensitive information (usernames, passwords, publicly-accessible host names or IP addresses, etc.).

Please redact sensitive information that would not be appropriate for email communication prior to sending the requested information.

If there is sensitive information that must be conveyed in order to provide a complete picture of the scenario you're facing, please let us know and we will set up a secure upload mechanism that can be used.

[rguente]

Hi Brenda

I can now reproduce the problem and (I guess) I've found the reason.
- The first session start --> always perfect.
- Starting 7 sessions with Alt+B --> always perfect

The problem is related to Cisco-routers running IOS-XR.
When I start a single session is afterwards a message-box with the text "The server refused to start a shell." displayed.
(this is nerving, but seems to be XR-related)

If I don't klick "OK" then the next session will not start until I clicked "OK".

This wasn't the case in the Version 7.

Regards,
Robert

[bgagnon]

Hi Robert,

This wasn't the case in the Version 7.

Version 7 covers a lot of ground.

We released SecureCRT versions 7.0.x, 7.1.x, 7.2.x and 7.3.x. Can you be more specific?

Is this a saved session you are using for the Cisco XR device? And is it the same session you used in v7.x.x?

If not, I expect the configuration differs. If you enable Do not request a shell in the Connection / Port Forwarding category of SecureCRT's Session Options, what are the results?

[rguente]

Hi Brenda,

I use these sessions since a few years. I can't say if I used them already with version 6 or not. But since years...

The main problem with the message-box is, that when I open a session, the box is placed behind the SCRT-window and is not visible then.

If you enable Do not request a shell in the Connection / Port Forwarding category of SecureCRT's Session Options, what are the results?

Nothing special happens when I enable this on the jumphost-session.
On the Router-session is the clear result, that I don't get a shell. So it's not a real option.
For my understanding should the solution be, that the message-box doesn't block additional sessions. That's all.

Best regards,
Robert

[bgagnon]

Hello Robert,

To clarify, it is the router session where I wanted you to enable the Do not request a shell option. By doing so, my hope is the server will not even send the message "server refused to start a shell".

I would still like to obtain the information about the prior version where you believe the behavior was different. If it is *changed behavior* on SecureCRT's part, our development team should investigate.

We believe the reason the dialog is displayed behind the main application window is because the message is coming from the SSH2Core, not SecureCRT itself.

I have created a feature request on your behalf in our product enhancement database to prevent dialog boxes from displaying under main SecureCRT application window (or display the info in terminal window) and added this thread to it. Should a future release of SecureCRT include this feature, notification will be posted here.

If you prefer direct email notification, send an email to support@vandyke.com and include "Feature Request - Forum Thread #12335" in the subject line or use this form from the support page of our website.

[rguente]

Hi Brenda,

Thank you very much for your support and the feature request!

To clarify, it is the router session where I wanted you to enable the Do not request a shell option

I wrote that I tried this, with the result, that I don't get a shell from the router.
And without a shell it's quite difficult to work on the router.

Best regards and have a good time,
Robert

[bgagnon]

Hi Robert,

Sorry for the misunderstanding:

On the Router-session is the clear result, that I don't get a shell. So it's not a real option.

I understood "it's not a real option" to mean since you don't get a shell anyway, no reason to enable the option.

So even with that option enabled, you get the dialog informing you the remote server refuses to start a shell? How odd, I cannot help with that since the message is coming from the remote host, but it's probably worth contacting Cisco about it.

[rguente]

Dear Brenda,

I've found finally the solution for this unwanted message!
Disable in Global Options --> SSH2 --> "Enable OpenSSH agent forwarding"

That's all! The message disappeared now.

Anyway. Your feature request is still a good idea.

Thank you again very much for your support!
Robert

[bgagnon]

Hi Robert,

Thanks for the update. I would not have thought of that. I am glad to hear you found a solution.