100

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?

3
  • 1
    When observed in /usr/local/sbin/sshd -D -e, possible workaround: serverfault.com/a/211176
    – Ivan Chau
    Commented Oct 2, 2016 at 16:40
  • I am experiencing the same problem and in my case i have narrowed it down to the fact that the same key works from a ubuntu shell on an real ubuntu running as an VM and not from the ubuntu embedded into Windows 10 (AKA Windows Linux Subsystem). Haven't figured out why yet, but maybe this still helps someone Commented Jan 23, 2017 at 7:20
  • 2
    Check /var/log/secure with LogLevel DEBUG3 in /etc/ssh/sshd_config
    – Ivan Chau
    Commented Sep 9, 2019 at 7:02

13 Answers 13

41

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.

4
  • 1
    Can it be caused by e.g nmap scanning?
    – Qback
    Commented Mar 14, 2018 at 16:58
  • 1
    This is usually hack attempts. I see a lot from China, Russia, Japan, etc.
    – jjxtra
    Commented Jul 3, 2018 at 16:52
  • 13
    If the IP address in the message is the client's IP address it may indicate that the client is attempting to authenticate with the incorrect passphrase for their private key. Their client then fails to decode the key and disconnects without attempting authentication. Commented Aug 20, 2018 at 23:26
  • Another possibility, if the IP address in the message is the client's IP, the client may be disconnecting due to a host identification change. Commented Oct 3, 2020 at 20:37
20

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.

1
  • 3
    For me this was because the File Permissions on my private keys (client side) were too permissive. Fix: $ chmod 400 private-key.pem Commented May 19, 2021 at 9:28
11

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 
10

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
1
  • Word of caution: RSAAuthentication is deprecated now,
    – rkochar
    Commented Apr 27 at 16:33
7

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

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.

5

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
1
  • 1
    Thank you! That solved my seemingly random connection issues from NixOS/Arch over a CentOS jump host to some 5 years old, not updated Debian servers!
    – schoettl
    Commented Apr 24, 2023 at 9:04
2

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.

2

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.

2

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 *
2

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

2

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.

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .