Meaning of “Connection closed by xxx [preauth]” in sshd logs

Question

We have a Windows batch script, which connects automatically to a linux server via PLINK (putty). There is NO public private key authentication, the user and the password are in the script.

On our linux server we have several sshd log entries (/var/log/messages):

sshd[7645]: Connection closed by xxx [preauth]

What could be the cause for such a message?
"preauth" supposably means "pre authentication"?

Sometimes in the entry, "closed by" has the ip address of the windows client, another time there is the ip address of the linux server in "closed by". Does anybody know the differency betweend client ip address and host ip address in the message?

Answer 1

The sshd server will disconnect if the client doesn't try to authenticate in a certain period of time, as documented in the -g option.

 -g login_grace_time
         Gives the grace time for clients to authenticate themselves
         (default 120 seconds).  If the client fails to authenticate
         the user within this many seconds, the server disconnects
         and exits.  A value of zero indicates no limit.

So I suspect if you see the server IP in the logs with this message, the connection was closed because no authentication attempt occurred within this grace time. When you see the client IP, it means the user closed their client (or the script terminated) without making an authentication attempt.

Answer 2

In my case, these messages appeared in /var/log/secure when I was experiencing Host key verification failed. errors on the ssh client side. This is one of the cases that would result in a connection without a login attempt.

Answer 3

I had a very similar problem to yours (though I was using public key).

It turns out my problem, and possibly yours, was caused because my home directory was a NFS mount, and selinux (on CentOS 7) was throwing up some errors (which were quite hard to track down). The fix was simple though.

setsebool -P use_nfs_home_dirs 1 

Answer 4

I had the same problem, I solved it like this:

On the ssh server, I uncommented, and put at yes the following values in /etc/ssh/sshd_config

 RSAAuthentication yes
 PubkeyAuthentication yes

And then:

sudo service sshd restart

Answer 5

Another source of these kind of messages is ssh-keyscan. It just grabs server host keys and disconnects without doing any authentication.

Answer 6

One source of these messages is https://sshcheck.com/ which displays possible weakness on your ssh server.

It causes about 4 of these messages sequentially.

Answer 7

The issue may be faced when using an outdated SSH server and very updated SSH clients.

We solved this using

ssh-keygen -t ed25519 -C "[email protected]"

to generate a new SSH key.

Add following into /etc/ssh/ssh_config

HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

Answer 8

I met the same situation, because of the iptables INPUT rule was DROP, but ACCEPT the ansible host, but there are not have the rule iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

The error log "Nov 3 01:34:50 debian sshd[29378]: Connection closed by 10.17.64.13 [preauth]" was wrote in "/var/log/auth.log" at the client machine after the command ansible all -m ping was ran in the ansible host.

Because the ping packet had receive by the client but not return to the ansible host.

Answer 9

In my case there has been some DoS attack on my machine. Server reached limit of simultanously open files and could not open authorized_keys file to verify my identity.

VFS: file-max limit XXXXX reached messages in dmesg appeared informing about problem after I finally managed to log in.

Answer 10

I was mounting Apache home directories using sshfs (with publickey auth), located on my server under /var/www (on Fedora Server with SELiunx enabled), and it appeared that the source of the issue was incorrectly set security context for home directories. The final fix was simple but hard to figure out, as there was nothing relevant shown by journalctl -xe command output.

Fix:

cd /var/www
chcon -R -t httpd_sys_content_t *

Answer 11

Mine is probably the stupidest.

I added an SSH key to the Google Cloud Platform VM, and it picked the username and saved the key under it, while I thought it was merely a metadata key, and was attempting to connect with the standard username "admin".

Logging in via the web SSH and manually looking for the right .ssh/authorized_keys file has helped me reveal the issue. Hope this helps someone coming from Google search

Answer 12

There's gazillion possible reasons — as you can see in this thread. Another one:

• extra = character in authorized_keys.

Somehow, my ed25519 .pub file had contained an extra b64 padding like this:

───────┬───────────────────────────────────────────────────────────────────────────────────────────────
       │ File: .ssh/acme/acme-aws.key.pub
───────┼───────────────────────────────────────────────────────────────────────────────────────────────
   1   │ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHVz0kRGRITW0/GqAJ89Xa/UlrZpkbQHkUE7WVG55VBH= [email protected]
───────┴───────────────────────────────────────────────────────────────────────────────────────────────

Naturally, I pasted this into authorized_keys as-is. This used to work no problem.
Bizarrely though, this time the server kept failing to match it.

sshd[825773]: debug2: userauth_pubkey: valid user ubuntu querying public key ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHVz0kRGRITW0/GqAJ89Xa/UlrZpkbQHkUE7WVG55VBH [preauth]
sshd[825773]: debug1: userauth_pubkey: publickey test pkalg ssh-ed25519 pkblob ED25519 SHA256:6I/LPlQEYs7pDIr8zjy/q2LtzzXRUC1E8V5RB8fQf5k [preauth]
sshd[825773]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
sshd[825773]: debug1: trying public key file /home/ubuntu/.ssh/authorized_keys
sshd[825773]: debug1: fd 5 clearing O_NONBLOCK
sshd[825773]: debug2: /home/ubuntu/.ssh/authorized_keys:1: check options: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDDNanyt0YmYPGOyHV9D/+rHgdL9QQWof0P1UQ6Yz8dT/4/JXbvSGzaJKbRsuRGpRE4n2k8Bcy2CC7PqKps/UZD+LELWbfT+LW+SQ3db5NZ2FL6U15jdzhf9tMnEMy/ci3tXPi3Uy7rQgrIAiT/5gJpDJBP6kZLtSvdAtRjuvWIhrXsxXox1aXxLzY23XmAtFEgbRyDrtrWZokEfZqbokkU5NogFu675IByxQKujlgCYSslS920gG7Xh1bfX2zjlUGkSrtajdOcEa7O2lEG5U+AZyXFCGDbM76QFkVLJhZr+mYMnfimUuu92tN588K+SHopYkgksfmcWFfECrcHB9ww4Ew+i6nbvIJGIcpCgpBintJHq6gDCWqOXmseij8edEkSOxtHb+JfT//EFkr
sshd[825773]: debug2: /home/ubuntu/.ssh/authorized_keys:1: advance: 'AAAAB3NzaC1yc2EAAAADAQABAAACAQDDNanyt0YmYPGOyHV9D/+rHgdL9QQWof0P1UQ6Yz8dT/4/JXbvSGzaJKbRsuRGpRE4n2k8Bcy2CC7PqKps/UZD+LELWbfT+LW+SQ3db5NZ2FL6U15jdzhf9tMnEMy/ci3tXPi3Uy7rQgrIAiT/5gJpDJBP6kZLtSvdAtRjuvWIhrXsxXox1aXxLzY23XmAtFEgbRyDrtrWZokEfZqbokkU5NogFu675IByxQKujlgCYSslS920gG7Xh1bfX2zjlUGkSrtajdOcEa7O2lEG5U+AZyXFCGDbM76QFkVLJhZr+mYMnfimUuu92tN588K+SHopYkgksfmcWFfECrcHB9ww4Ew+i6nbvIJGIcpCgpBintJHq6gDCWqOXmseij8edEkSOxtHb+JfT//EFkr2LpnVE+Qg7TcSf
sshd[825773]: debug2: /home/ubuntu/.ssh/authorized_keys:2: check options: 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHVz0kRGRITW0/GqAJ89Xa/UlrZpkbQHkUE7WVG55VBH= [email protected]\n'
sshd[825773]: debug2: /home/ubuntu/.ssh/authorized_keys:2: advance: 'AAAAC3NzaC1lZDI1NTE5AAAAIHVz0kRGRITW0/GqAJ89Xa/UlrZpkbQHkUE7WVG55VBH= [email protected]\n'

Read the log, paying attention:

• the server does receive the key I'd configured (which implies the client did send it):

  "valid user ubuntu querying public key ...55VBH [preauth]"

• proceeds to scan authorized_keys; skips an ssh-rsa key; skips the ed25519 key too;
• the skipped key ends on ...55VBH=. Due to the extra trailing =, this fails to match.

Removing the = padding in authorized_keys to match perfectly what ssh-keygen -y -f the.key said — resolved the issue for me.

---

In general, so much can go wrong (and normal, too) resulting in this log — you'd be exercising luck trying to find advice with an expectation to see a-la "run sudo magic and it'll get fixed".

What's guaranteed to help — is enabling debug logs and inspecting them carefully. Yes, even 1 character difference matters.

On the client: ssh -v / ssh -vv / ssh -vvv will produce progressively more detailed debug logs.

On the server: edit /etc/ssh/sshd_config remembering to sudo systemctl restart ssh afterwards:

# …
LogLevel DEBUG
#LogLevel DEBUG2
#LogLevel DEBUG3

The server logs will be in journalctl -u ssh.service -f.

Answer 13

I encountered an issue where I couldn't establish an SSH connection to my server despite having the correct configurations in place. After trying various solutions, I finally found a workaround that worked for me.

I resolved the problem by explicitly specifying the private key during the SSH connection attempt. Here is the command I used:

$ ssh -i "~/.ssh/id_rsa" [email protected]

In the command above, the -i option is used to provide the path to the private key (~/.ssh/id_rsa). By explicitly specifying the correct key, I was able to successfully establish the SSH connection.

During the connection attempt, I was prompted whether I wanted to save the key for permanent use, to which I responded with 'yes'. This allowed me to avoid the previous authentication issues I encountered.