Selective debug of secure FTP sessions

[Richard W Hunt]

I searched the forum and my available documentation kits before asking this. I also tried on-line but couldn't quite figure out what to ask for after several tries.

I had a problem last week where we had some trouble with a client sending SFTP to my OpenVMS 7.3-2 and TCPIP 5.4 ECO7. The user's problem was solved via workaround involving the Alpha ZIP program from the [...COMPAQ...] sub-paths. But that isn't the question.

In trying to debug the problem, I discovered the "real" meaning of SFTP being a sub-system of SSH. In order to debug the SecureFTP session, I had to turn on debug for ALL SSH sessions, even the ones not using SFTP. Pain in the toches and left a lot of cleanup for me. Those files get awfully large, too.

So... is there a way to selectively enable extra information only for SFTP sub-system sessions within SSH - without enabling all SSH session debugging?

Stated another way, I can selectively turn on regular FTP debugging with a logical name such as TCPIP$FTP_EXTLOG (extended logging). Is there a corresponding logical name for SecureFTP?

Also, if I have to resort to debug mode again, maybe I don't quite need debug level 99. Is there any documentation anywhere short of taking multiple logs by trial and error to show what is brought into play by various debug levels?

[Richard Whalen]

MultiNet and TCPware can do this. I added the code to check a logical to enable specific debug levels and open the logging file, so I have no idea if there is something similar in TCP/IP services.

[Wim Van den Wyngaert]

May be try to find the .com that is executed to start the session for the user. And add
a test on the user and give debug when matched.

Wim without VMS node

[Richard W Hunt]

Wim, tried a couple of variants of that. Here's what I see happening:

1. Network driver detects incoming connection on port 22, triggers a startup of TCPIP$SSH.

2. The session runs file SYSDISK:[TCPIP$SSH]TCPIP$SSH_RUN.COM, which triggers the SSH "daemon" image.

3. The daemon picks up the traffic, establishes the session, exchanges pleasantries with the client, and eventually authenticates. This is the first time that the system knows who it is talking to.

4. The daemon creates an interactive session tied to the mailbox it creates to act as the PseudoTerminal for that session. The daemon will from that point forward decrypt the traffic and feed it to the PTY.

Unfortunately, I need to be able to set the debug flags in step 2 because the SSH_RUN script is the place where that can be set. But I don't know who is running until step 3. And the error I encountered didn't occur until well into step 4.

My workaround is working (for now) so I'm content to let that sleeping dog lie for a while longer. When I finish my upgrade project, I'll be on TCPIP 5.6 + current ECO under VMS 8.3, so maybe the problem will go away. If not, I've still got the workaround in-hand for later use.

I'll leave this open in case someone else has any brainstorms, but at the moment I'm not seeing the path I need to take.