[Info-vax] stumped by SSH

[Jan-Erik Soderholm]

Den 2016-02-06 kl. 17:34, skrev Phillip Helbig (undress to reply):
> In article <n94rpv$o9p$1 at dont-email.me>, Simon Clubley
> <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>
>>> ssh -V says:
>>>
>>> local:  3.2.0 on Alpha
>>> remote (linux): OpenSSH_6.7p1
>>
>> So now we know the remote system is a non-VMS box, you need to up the
>> debugging level on the VMS SSH client and see if the debugging messages
>> give you any clues.
>
> How can I do that?
>
>> You also have not said yet whether both the working and non-working
>> accounts are on the same Linux box.
>
> Working and non-working refer to VMS accounts.  Some VMS accounts work
> and some don't, no matter from which account (local or remote) one tries
> to log in.
>
>> There was an issue where increased
>> SSH security defaults in recent Linux versions means that the VMS TCP/IP
>> services client is not considered secure enough and hence connections
>> from the VMS client are rejected.
>
> I know about this problem, but it cannot explain why I can log in
> (locally or remotely) to some VMS accounts but not to others.
>
>> I am now seriously confused. Is the remote SSH server a VMS box or
>> a Linux box ?
>
> Local: VMS cluster.  Remote: Linux.

I think that Simon implied that:

"Local" is where you are trying to start a SSH session *from*.
That is, the envoronment where you are when issuing the SSH command.
Or in other words, the "SSH client".

"Remote" is where you are trying to connect *to*.
Where the "SSH server" is running.

If we do not agree on that, this will be realy weird... :-)

Jan-Erik.




   Some VMS accounts cannot be logged
> in to via SSH, neither locally nor remotely.  Telnet works locally and
> remotely and SET HOST/LAT works locally.  So, it is not a problem with
> the account (wrong password, etc).  Nor is it a problem with SSH per se,
> as some VMS accounts work fine.
>