SSH Users Dropped

[Steve Calnek]

Hi,

No, there are no programs like hitman running on this system.

Steve/

[Hoff]

Turn on process control auditing via SET AUDIT /ENABLE [...more /stuff...]. Calls to various of the core process control services can be selectively audited.

Also start swapping some of the component pieces involved in the connection, and try and see where the problem lurks. I might load in a Mac OS X or Linux box here, and turn somebody loose with that to see if that connection dropped. Also establish "dummy" connections from the failing Windows boxes to another target, and see if those are (also) dropped.

[Steve Calnek]

Thanks Hoff, saw this very suggestion on your blog and did this about an hour ago,

$set audit/audit/enable=(process=(creprc,delprc,forcex))

We'll see what the results are on Monday.

Steve/

[Steve Calnek]

I had an SSH session dropping situation happen on another server at another site this weekend.

The user has been logged in all day working without dropping out once but then in a time frame of less than 10 minutes he dropped twice.

When I review the audit log the error is the same as the server I've been working on that last week. This users a bit more technical and experimented a bit before reporting it to me. He said the drop out occurs when ever he' was doing high speed data entry. He managed to replicate the situation consistently.

Could this be the alt type ahead buffer being set to low?

If it makes sence that this is it, what should it be set at?

Any comments?

Steve/

[Volker Halle]

Steve,

if you're looking at the audit log entry, which process does the $DELPRC (or $FORCEX) ? Is it TCPIP$S_BGxxxx process handling the IP SSH communication ? Could you post the audit log entry ?

If the user can 'reproduce' the problem, can you have him log in direcly (e.g. console) on one VMS system, SSH to another VMS system (or even the same one) and reproduce it ?

Volker.

[Wim Van den Wyngaert]

I'm using multinet so I can't test it.

A SSH session has 2 processes. 1 session and 1 process doing the SSH stuff. You looked at the interactive process (in accounting).

Could it be that the interactive one is killed by the network process meaning SSH took the initiative to kill the session ?

Wim

[Volker Halle]

Steve,

you can enable debugging for the SSH server process, the one with the name TCPIP$S_BGxxxx, by setting the system-wide logical

$ define/sys tcpip$ssh_server_debug yes

(see the code in TCPIP$SYSTEM:TCPIP$SSH_RUN.COM). It will log an enourmous amount of information into the file TCPIP$SSH_DEVICE:[TCPIP$SSH]TCPIP$SSH_RUN.LOG, but maybe this can help. Be warned, the logfile grows pretty big...

Volker.

[Wim Van den Wyngaert]

Specifies the level of debug information. By default, this logical name
is set to 99.

Default is maximum debug ????

Wim

[Volker Halle]

Wim,

the DCL code in TCPIP$SSH_RUN.COM (at least with TCPIP V5.5) looks for the existance of the TCPIP$SSH_SERVER_DEBUG logical and then just invokes the SSH server with params = "-i -d 99" but you could certainly edit this procedure temporarily to reduce the debug level, once you've found what you're looking for.

Volker.

[Steve Calnek]

Hi Gentleman,

Sorry for the delay getting back to this but I turned it over to HP. This issues now resolved but I wanted to share what it was.

An SSH client and server will exchange new keys every hour. A failed attempt at a rekey will result in the connection being dropped.

In my situation the problem was that the audit log showed the drops occurring at intervals of hour(s) rather than just an hour. What we ultimately surmised was that a rekey attempt was being made during heavy data input periods by the user on their respective workstations.

To resolve the issue I modified the SSH server config file to allow a rekey attempt every 10 hours.

RekeyIntervalSeconds 36000

This resolved the issue for me. In our situation this is not a problem but I'm certain there are higher security operations people not impressed by this.

Its not clear if this is a server or client issue. I adjusted the setting on the server because none of the clients we tried allow adjustment. We tried 5 different client emulators, but never changed the host OS which was MS Windows 2000 Pro ( I know its old, I don't control this). It could be a threading issue with that OS.

The HP help desk was not away of this issue but they found some notes on the issue from OVMS engineering that said that they had seen this occur with certain client emulators. They certainly know about it now.

I appreciated the efforts by all of you to help me. I hope this information is helpful to you or others in the future.

Regards.

Steve Calnek