SSH logins not working for any user but system - VMS 8.3

[Lou Palladino_1]

Hi
Just installed OpenVMS 8.3. No one can login via SSH except "system". It is pretty much a default install.
Am I missing a config option? Audit log shows only:

%%%%%%%%%%% OPCOM 7-MAY-2009 07:51:12.04 %%%%%%%%%%%
Message from user AUDIT$SERVER on VMS02
Security alarm (SECURITY) and security audit (SECURITY) on VMS02, system id: 113
57
Auditable event: Network login failure
Event time: 7-MAY-2009 07:51:12.03
PID: 000004B0
Process name: TCPIP$S_BG13458
Username: TCPIP$SSH
Remote node fullname: SSH_PASSWORD:SOURCE-HOST.DOMAIN
Remote username: PALLADINOL(LOCAL)
Status: %LOGIN-F-NOTVALID, user authorization failure

[marsh_1]

hi,

what output do you get using the -v option to connect ?

hth

[marsh_1]

hi,

also have a read of the ssh manual so you can check your settings in the ssh config files :-

http://h71000.www7.hp.com/doc/83final/ba548_90007/ba548_90007.pdf

hth

[Lou Palladino_1]

lpalladino@lpalladino-desktop:~$ ssh -v -l palladinol vm02
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to vm02 [10.113.88.117] port 22.
debug1: Connection established.
debug1: identity file /home/lpalladino/.ssh/identity type -1
debug1: identity file /home/lpalladino/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/lpalladino/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH Secure Shell OpenVMS V5.6 VMS_sftp_version 2
debug1: no match: 3.2.0 SSH Secure Shell OpenVMS V5.6 VMS_sftp_version 2
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'vm02' is known and matches the DSA host key.
debug1: Found key in /home/lpalladino/.ssh/known_hosts:244
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/lpalladino/.ssh/identity
debug1: Offering public key: /home/lpalladino/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/lpalladino/.ssh/id_dsa
debug1: Next authentication method: password
palladinol@vm02's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
palladinol@vm02's password:

[Lou Palladino_1]

Yep - gone through the manual and made a few changes... Max # of logins is 50, no user or host restrictions, etc.

[Wim Van den Wyngaert]

DELETE/INTR * ?

case sensitive user name ?

Any audit alarms (but enable file access failre first).

Is VMS to VMS working ?

Wim

[marsh_1]

hi,

are you able to login over the network using telnet for example ?

[Hoff]

The ssh bits have a fairly long and complex and obscure configuration requirement that needs to be carefully and completely followed, and errors in the file or directory protections and in the contents of the various user-local and server-local configuration files (all) need to be observed.

Read through the TCP/IP Services manual (again) and confirm the whole process has been followed completely, from the ssh daemon startup on through to the per-user ssh2 files. It is easy to miss a step.

Do load the current ECOs for OpenVMS and for TCP/IP Services. This as a general rule.

And try using the:

ssh PALLADINOL@vms02.example.com

syntax here, as well.

[Lou Palladino_1]

Thanks for everyone's response. The issue is fixed - here is what is was.

I was following Wim's test of VMS to VMS, just SSH'ing back to myself on the same box. It connected, and prompted me to change the password (since it was pre-expired). I changed the password, then tried from a *NIX system, and I could login fine.

So the issue is that the SSH connections coming from *NIX hosts or terminal emulators on Windows boxes are not able to process the pre-expiring password process? While this doesn't quite make sense, it is what I saw.

Does this make sense to anyone else?

[Volker Halle]

Lou,

please have a look at this thread:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?&threadId=1246613

Hope this helps,

Volker.

[marsh_1]

hi,

from the previously mentioned ssh manual :-

The client user login is rejected if:
49
â ¢ The connection is from a different SSH implementation to an OpenVMS system and the
AllowVmsLoginWithExpiredPw parameter is set to no in the server configuration file.

[Richard W Hunt]

Adding to the stuff previously mentioned about allowing non-VMS logins with expired passwords, you might also need to make one more mod to the SSHD2_CONFIG file. Allow kbd-interactive (keyboard-interactive?) authentication because that allows your emulator to become involved in a forced-update of a password.

We use a Windows version of Attachmate Reflection a lot. That little change seemed to help at our site.