SFTP hangs on connection...

[Bill Pedersen]

I am attempting to set up a connection between an OpenVMS I64 V8.4 system with TCPIP 5.7 ECO 2 and a remote environment.

All I get is a "hang". So, I attempted to use DEBUG to get information. Attached is the result of:

$ sftp "-D 99" okna@ftp.affiniscape.com

As I do not have the source I do not know what to think about the log file. I have verified that the system does respond to Putty/SSH from a PC and get the message that it can not allocate a PTY, which is expected since we only expect to connect for file transfer. That is better than what we get from VMS/SFTP or even VMS/SSH - which also hangs.

Thanks folk!

Bill.

[John Gillings]

Bill,

That trace looks to me like the SYLOGIN or LOGIN is doing a SET TERMINAL/INQUIRE (or equivalent). It shouldn't be doing that for a non-interactive process.

Simple first check is to put "$ EXIT" at the top of both LOGIN.COM and SYLOGIN.COM.

Please check the whole LOGIN sequence and make sure it's conditionalised for different process modes.

[Bill Pedersen]

As of now I am not certain what the remote site host is running. It has not presented anything to me which suggests OpenVMS as of yet.

It does appear to send control characters during the login with SSH, things like clear screen and such, as it supports interactive userid and passwords. But you would expect SFTP to handle this or SSH from VMS - which also hangs...

[John Gillings]

Bill,

>But you would expect SFTP to handle this
>or SSH from VMS

No, I wouldn't!

Remember with SSH or any of the S(ecure) protocols, there are at least 2 processes involved. One to supervise the connection and perform the encryption/decryption, and the other to do the actual requested work.

The supervisor process runs under a strict protocol, and I would NOT expect it to accept random control characters in the data stream. For an interactive worker process, yes, it's acceptable, but not for a non-interactive one.

Until you've eliminated the extraneous control sequences from the connection, and shown similar symptoms, you cannot discount them as irrelevant.

If it's an OpenVMS system, both SYLOGIN and LOGIN should test F$MODE() and avoid interactive operations for non-interactive processes.

[Bill Pedersen]

I fully agree as to eliminating the control characters if we can. My concern though is that Putty shows no issue here - handles it fine. SSH/SFTP on OpenVMS SHOULD be as good in how it handles exceptions.

I have tested SFTP against the local host. It works and makes a connection.

[Richard Whalen]

Though I do not have the source that HP used, I have worked with source that is similar. The SSHD (remote portion of the SSH protocol) image has some code to screen out unexpected stuff while looking for the start up of the SFTP server, but there is a limit to what it can do. In general it will handle a little bit of OUTPUT; SET TERM/INQUIRE does output, then looks for input, so it may be eating some of the data that is destined for the SFTP server image.

Since everything works on the local side, the best way to debug this is to get debugging information from the remote side. Telnet to port 22 reports

SSH-2.0-2.0

I don't know which implementation of SSH this is, so I don't know how to turn on debugging for it, or whether or not there is a separate mechanism for getting debug information from the SFTP server.

[Bill Pedersen]

Richard:

Thanks.

Currently the HP support staff is looking at the situation. A couple tcpdump traces were run and each showed an issue where it appeared that the local ssh/sftp process sent a "malformed" packet so both sides are waiting. There is also additional indication that the ssh/sftp process has exited unexpectedly. Since the packet would not be expected to complete the circuit both sides are now "waiting". Not too good of a protocol point in my estimation, but...

So I am waiting on HP's additional review and possible forwarding to TCP/IP Engineering.

Will keep folks advised.

Bill.

[Pim van Velzen]

You might check out (and/or post) the server logfile,
TCPIP$SSH_DEVICE:[TCPIP$SSH]TCPIP$SSH_RUN.LOG
containing the 'failed to allocate pty' message, for accompanying messages/error codes ...