[Info-vax] stumped by SSH

[Neil Rieck]

On Sunday, February 7, 2016 at 10:50:44 AM UTC-5, Neil Rieck wrote:
> Caveat: This response has nothing to do with SSH OR SSH2.  
> After some restless sleep, I recalled a catch-22 situation related to creating captive accounts on OpenVMS-7.x and higher. The problem happens when a password is set during account creation which must be changed during the first login. IIRC, when someone first logs into a captive account on Alpha, the password is flagged as expired (but requires the user to change it immediately) but the password never gets written back to SYSUAF. IIRC, the only way to get around this was to set up the account without the captive flag enabled (but also making sure the password would never expire, etc.), then login into the account once (where you are always prompted to change the password), then finishing by setting the captive flag.
> 
> Neil Rieck
> Waterloo, Ontario, Canada.

Continuation...
Everyone in this newsgroup already knows that all fault analysis depends on sectionalization so we begin by dividing OpenVMS from SSH/SSH2. Once you are able to interactively log into OpenVMS without the captive bit enabled, try logging in via SSH/SSH2. If this fails then you know that the config file associated with the server is not properly enabled. 

Personal Experience. I thought I was getting fairly proficient at setting up SSH/SSH2 server daemons on various corporate machines including OpenVMS-TCPware, Solaris-8, Solaris-9, and various Windows platforms. I found that enabling SSH2/SFTP on OpenVMS-TCPIP-Services was a tiny bit more difficult. I found that enabling SSH2/SFTP on OpenVMS-Multinet was a lot more difficult ( click: http://www3.sympatico.ca/n.riec/docs/openvms_notes_ssh2.html#humancaused ) 

As I mentioned in a previous post, once SSH/SSH2 is properly set up, people or computers will be able connect without a password because the public-private key takes on that role. But loss of control is the kind of stuff that keeps most system admins awake at night so it would appear that the newer SSH/SSH2 implementations install with almost everything disabled by default (and this is a good idea).

I even discovered an SFTP error "Disconnected; protocol error (Protocol error: packet too long" which sysadmins had been googling about for a couple of years but I traced to a problem in the config file where SSH/SSH2 was enabled but SFTP was not. (in TCPware both had been enabled by default; in MultiNet everything appears to be disabled by default) 

Although I wasted a lot of time (more than a few hours), I recall that the only way to debug this problem was to enable verbose debugging of both the server daemon.

p.s. so of course the error message was correct. The packet was too long because there was no place to put it. Anything larger than zero was too long :-) 

Neil Rieck
Waterloo, Ontario, Canada.