Recently I installed PAM & all the necessary packages needed to enable ssh authentication via AD on my RHEL 7.5 machines.
When I try to SSH using "ssh user@domainname@hostname" it asks for my password and as soon as I type my password, I get the error: Connection closed by UNKNOWN port 65535.
This happens on several machines running RHEL 7.5. sssd is used to bind to AD, there are no firewalls, system time is in sync with AD server, appropriate groups are added to permitted_groups, and the account is not locked out. Tailing the /var/log/secure shows the errors below:
sshd[12752]: reprocess config line 145: Deprecated option RhostsRSAAuthentication
sshd[12752]: pam_krb5[12752]: account checks fail for 'user@domainname': user disallowed by .k5login file for 'user@domainname'
sshd[12752]: Failed password for user@domainname from ip port 53166 ssh2
sshd[12752]: fatal: Access denied for user user@domainname by PAM account configuration [preauth]
I have restarted sssd and sshd without any luck.
Any help will be appreciated.
Best Answer
The super-unhelpful ssh error
Connection closed by UNKNOWN port 65535
can be reported when yourssh
client in a couple of different situations when the remotesshd
cannot be reached at all because of something happening "in the middle".This can be extra-tricky to debug because in some cases the remote sshd has no idea that anyone is ever tried to connect to it.
(Aside 65535 is "special" number to computer folks as it is
2^16 - 1
, aka0xFFF
-- the maximum unsigned 16 bit integer (also the max port number))Case A -- (From @doug 's original question) - In this case the remote sshd got the incoming connection and delegated auth down to Linux libraries for PAM (Pluggable Authentication Modules). PAM hands off to KRB5 or SSS and that fails. So all the poor remote sshd gets is a big NOPE from PAM. ...it never got into it's "normal" protocol parsing and error checking that would let it return a more helpful error message.
(It's possible that old Kerberos config options like gssapiauthentication might behave similarly)
Case B -- In our case we saw this when network firewalls prevented connections from the dev/test machines to staging/production machines. Depending on your network, you might be able get more diagnostics info with
tcping $remote_hostname 22
, or (less helpful): UDP network tests likeping $remote_hostname
,traceroute $remote_hostname
, or the IPv6 versions of those commands. Your local network engineers can help confirm & fix.The giveaway in this case is that
ssh -vvv $remote_hostname
gets to this point:...pauses for 60s (or whatever timeout), then:
Case C -- Some kinds of failures of the
ProxyCommand
that your localssh
delegates to can also fail in unhelpful ways. Check for any "proxy*" or "tunnel*" related options in the output of: