VSI OpenVMS Forum

I installed the OpenSSH beta on an V8.4 IA64 system, but when I try to ssh to it it immediately closes the link. It doesn't even start the ssh daemon and no log is created. What am I doing wrong?

Hi,

If you mean HPE OpenVMS v8.4, the new OpenSSH for OpenVMS requires VSI OpenVMS I64 v8.4-2L1 or newer (or x86-64 v9.1-A).

No I mean VSI OpenVMS 8.4-2L1 on IA64, the latest, barring V9.

I can't figure out what the problem is. If I set OpenSSH as the service for port 22, any incoming connections to port 22 get dropped immediately without even starting the service command file. Outgoing connections from the ssh clients work fine, it's just the ssh server that is the problem; TCPIP$INETACP drops the connection without starting the service. Since that wasn't changed when the beta was installed there must be something wrong with the service definition.

Hi, So no new SSH$ROOT:[VAR]SSH$SSHD_STARTUP.LOG when you try to connect?

You may need to enable debug mode on the ssh client to get more info.

The service definition is typical:

$ ucx sh serv/full sshd22

Service: SSHD22
State: Enabled
Port: 22 Protocol: TCP Address: 0.0.0.0
Inactivity: 5 User_name: SSH$SSH Process: SSHD22
Limit: 10000 Active: 0 Peak: 1

File: SSH$ROOT:[BIN]SSH$SSHD_STARTUP.COM
Flags: Listen

Socket Opts: Rcheck Scheck
Receive: 0 Send: 0

Log Opts: None
File: SSH$ROOT:[VAR]SSH$SSHD_STARTUP.LOG

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0

On the OpenSSH VMS host, can you TELNET to port 22:

$ telnet vmshost 22
%TELNET-I-TRYING, Trying ... 10.10.10.10
%TELNET-I-SESSION, Session 01, host vmshost, port 22
SSH-2.0-OpenSSH_8.8 VSIe character is ^]

Press Ctrl\] to get the TELNET prompt; then enter QUIT.

By default the new SSH server requires modern cryptography.
I found this by doing ssh -v which told me the client system I was using [HPE OpenVMS V8.4] did not have the algorithms that the OpenSSH server was accepting.

I will have to alter the SSHD_CONFIG to allow for the dim and distant past supported by VMS V8.4

The service isn't getting far enough to grab the contents of SSHD_CONFIG. However the display of the service settings did the trick. For some reason when the service was migrated the /LIMIT was changed to 0 which explains why the listener immediately closed the connection. It had reached the limit of 0 service copies running! Changing the limit to 10000 and a quick ENABLE/DISABLE and it's now starting the service command file.

Now for the next problem. The client connects, is authenticated, and then the daemon closes the connection:

$ SET PROC/DUMP
$ sshd -i
[Wed Feb 16 08:56:28 2022] [auth] [info] (00002D6A) ssh$sshd.exe.1:Accepted publickey for <username> from nnn.nnn.nnn.nnn port 51199 ssh2: RSA SHA256:<hex>
rg
[Wed Feb 16 08:56:28 2022] [auth] [err] (00002D6A) ssh$sshd.exe.1:error: no more sessions
SSH$SSH job terminated at 16-FEB-2022 08:56:29.00


So I took a look at SSHD_CONFIG and it had set MaxSessions 0 during the migration for some reason. I commented that out to let it use the default value (10 I think), and it's now working. Connections work through both the original tcpip clients and the new openssh clients.

Is there any mention of Maxsessions in the migration log - ssh$root:[var]ssh$migration_<date>_<time>.log?

Or in the old SSHD2_CONFIG. file, is Maxconnections specified:

$ sea sys$sysdevice:[tcpip$ssh.ssh2]sshd2_config. maxcon

You're right, the original SSHD2_CONFIG file also has MaxConnections 0 uncommented in it. It's different than the config files across our other identical OpenVMS servers. I don't recall changing it and it doesn't seem to be obeyed under tcpip.

Update: Now I remember I copied that config file from another server that had been set up by someone else. Maybe they thought MaxConnections 0 meant unlimited. In any case, the original tcpip ssh daemon doesn't obey that setting, or we would have heard about it.