When connecting via SSH using an Ubuntu 18.04 client, the ConfD ssh server closes the connection after the connection has been established. This does not appear to be due to failure of cipher/KEX negotiation since the connection is established, then closed by the server. And it does not appear to be due to a firewall, as an Ubuntu 14 client works fine.
Enabling the confdLog and developerLog debugging on ConfD doesn’t provide any additional information. Is anyone aware of a possible cause for Ubuntu 14 working but Ubuntu 18 failing to connect?
This rings a bell, It’s not a general issue with Ubuntu 18.04, though. I use its ssh-client to connect to ConfD all the time.
What’s the ssh version and ConfD version?
What do you get with ssh -vvv ?
I ran into something similar the other day. To see if it’s the same issue, make sure that you start ConfD with old PEM style formatted keys and not the new OpenSSH key format. If you check the first line of the SSH host keys configured in ConfD, you should have
-----BEGIN RSA PRIVATE KEY-----
NOT
-----BEGIN OPENSSH PRIVATE KEY-----
If you have the latter, ConfD silently starts and you can connect with your SSH client. You just can’t login because no host key is returned, and the client disconnects. If you had the same situation as me, it is probably because your ssh-keygen is new and the default format has changed. To work around this, use the old format to generate the host keys, like this:
ssh-keygen -v -f ssh_host_rsa_key -N “” -t rsa -m PEM
ssh-keygen -v -f ssh_host_dsa_key -N “” -t dsa -m PEM
HTH!
I also thought of this known issue (hopefully ConfD will be taught to understand the OpenSSH format, or at least the installer to use the -m PEM, but it seems neither has happened yet). But I got the impression that @judegeorge got a working connection to a given ConfD instance with one version of client and not with another, while if a ConfD instance has a host key in OpenSSH format, no clients can get a working connection to it. Perhaps @judegeorge will provide some additional info to clarify.
I think you’re right, @per. I missed that @judegeorge said it worked for one client but not another. Different issue then.
Enabling the confdLog and developerLog debugging on ConfD doesn’t provide any additional information
I have noticed this as well, and would be interested to know if there is a way to get more SSH server logs from ConfD somehow. Could be helpful with this issue as well, no matter what the root cause is.
Thank you, everyone, for your responses. It turns out that our customer is using a product build which is using a very old ConfD version, possibly 6.0.3 or even 5.2.1.
In the failure case, I don’t have the full output of ssh -vvv, but it did include:
channel 0: free: client-session, nchannels 1
The ssh-client debug data shows that ciphers/kex/macs are negotiated and agreed upon…and there’s a connection being opened:
(client-side)
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
…but then immediately
“Connection to [IPADDR] closed by remote host.”
They enabled the confdLog and developerLog, but the only information regarding this connection attempt was:
bash-4.1# Apr 16 15:28:53 2019-04-16 15: 28:53,646 [Thread-0] WARN EventLog.confd- AuditNotification[logno=107, user=admin, usid=0, msg=“logged in over ssh from [IPADDR] with authmeth:password”]
Because they are using such an old version, we are unlikely to try to address this problem further and are encouraging them to upgrade, which should hopefully solve the problem. We have tested with a product using a newer version of ConfD (currently 6.4.3) against Ubuntu 18.04 and are not seeing the problem occur with this version.