Issue fatal: Timeout before authentication for [IP-ADDRESS] port 44745

[Compi]

Hello, I regularly get these when logged into the server console:

Port 44745 is unassigned so I can't be sure which service/port is being spoken to.

What are these exactly? It only happens on my Debian 12 machines.

 

[rgv]

+1

 

[FlexKleks]

Yes, exactly. I have too. Please help

 

[JVG]

Same thing happened on my new Debian 12 server. It definitely didn't happened on Debian 11.

It's my first try with Debian 12, is it a known OS related thing?.

 

[rgv]

This is getting on my nerves as well.


E.g.
2024 Mar 6 18:42:18 static fatal: Timeout before authentication for x.164.171.x port 57852


Product version: Plesk Obsidian 18.0.59.2
OS version: Debian 12.5 x86_64
Build date: 2024/02/29 10:00
Revision: 4d5def438d80f901f8ade594e9abb2c9ee467dd3

 

[JVG]

It seems to be the output of the auth.log errors. Why is showing in the console, i don't know. Maybe something related with journald, which seems to be the default logging service for Debian 12.

 

[Daveo]

Is there any way to stop this reporting in console, as I can confirm it happens only on freshly installed Debian 12.

It doesn't occur on systems updated to Debian 12.

 

[rgv]

Unfortunately, i could not find a solution so far.

I tried to adapt the journaling

> nano /etc/systemd/journald.conf ForwardToConsole=no ForwardToWall=no MaxLevelConsole=emerg MaxLevelWall=emerg > systemctl restart systemd-journald[ /ICODE] But it seems that these messages are considered "emergency" level and cannot be muted on Wall/Console at all. I could not find a solution to "downgrade" them at sshd. And yes, it is only a sshd authentification timeout. You can initiate it yourself by trying to login without entering a password or using a correct key and wait for 2m minutes.

 

[Daveo]

Found the following on journald.conf ...

MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=
Controls the maximum log level of messages that are stored in the journal, forwarded to syslog, kmsg, the console or wall (if that is enabled, see above). As argument, takes one of "emerg", "alert", "crit", "err", "warning", "notice", "info", "debug", or integer values in the range of 0–7 (corresponding to the same levels). Messages equal or below the log level specified are stored/forwarded, messages above are dropped. Defaults to "debug" for MaxLevelStore= and MaxLevelSyslog=, to ensure that the all messages are stored in the journal and forwarded to syslog. Defaults to "notice" for MaxLevelKMsg=, "info" for MaxLevelConsole=, and "emerg" for MaxLevelWall=. These settings may be overridden at boot time with the kernel command line options "systemd.journald.max_level_store=", "systemd.journald.max_level_syslog=", "systemd.journald.max_level_kmsg=", "systemd.journald.max_level_console=", "systemd.journald.max_level_wall=".

Does that help ?

 

[Nicson]

Hi, same Problem.
Is it possible this issue results from Plesk Key/Licence if one VM gets cloned on another Server?
I have 3 VMs
1st - original installed (no Problem, no Message)
2nd - cloned, new Key installed after clone (fatal: Timeout before authentication.... Message)
3rd - cloned, new Key installed after clone (fatal: Timeout before authentication.... Message)
?

 

[Nicson]

Hi, same Problem.
Is it possible this issue results from Plesk Key/Licence if one VM gets cloned on another Server?
I have 3 VMs
1st - original installed (no Problem, no Message)
2nd - cloned, new Key installed after clone (fatal: Timeout before authentication.... Message)
3rd - cloned, new Key installed after clone (fatal: Timeout before authentication.... Message)
?

so... finally also VM1 get the Messages...

 

[JVG]

Hi, same Problem.
Is it possible this issue results from Plesk Key/Licence if one VM gets cloned on another Server?
I have 3 VMs
1st - original installed (no Problem, no Message)
2nd - cloned, new Key installed after clone (fatal: Timeout before authentication.... Message)
3rd - cloned, new Key installed after clone (fatal: Timeout before authentication.... Message)
?

I don't think so. Mine is one fresh Debian 12.5 server and fresh Plesk installation and license.

 

[Hangover2]

We can confirm the same problem on our Debian 12 Plesk servers after a fresh install.
The minimal base system of Debian 12 is not affected. The same error messages are logged but not shown inside the terminal.
After Plesk is installed the warnings are printed in the console.

 

[Hangover2]

The anomaly is quite interesting and hard to catch.
Changes to printk of the kernel have also no effect even with the lowest values.

cat /proc/sys/kernel/printk
1        1        1        1

Everything with values of 0 (KERN_EMERG), 1 (KERN_ALERT) and 2 (KERN_CRIT) is printed in the terminal (we tested with logger on the command line).
Maybe we should make a bug report or this topic can be moved by @Peter Debik to the reports forum?

 

[Peter Debik]

Maybe we should make a bug report or this topic can be moved by @Peter Debik to the reports forum?

Feel free to report it as a bug. To me it looks like an operating system issue, though. It may be better to open a support ticket, because likely engineers will want to test it on an affected server anyway.

 

[rgv]

Workaround: I changed the ssh server port, at least to reduce the number of alerts:

nano /etc/ssh/sshd_config

#Port 22 -> change to an alternate port, e.g.
Port 8822

Then use these 3 commands to apply the new port

service sshd restart
/usr/local/psa/admin/sbin/modules/ssh-terminal/installer --update-configuration
systemctl restart plesk-ssh-terminal

Caveats:
- Make sure you test the new port with a new ssh session before you leave the existing ssh session
- Make sure you opened up the new port (TCP) within your Plesk Firewall
- Make sure you opened up the new port within any other system firewall and also with your hosting provider if they got an exteral firewall setup

 

[apochr]

If this is too annoying for you on a Debian 12, as it is for me:
Open /etc/syslog-ng/syslog-ng.conf.
In the "Log paths" section, comment out the line:

log { source(s_src); filter(f_crit); destination(d_console); };

Restart the syslog-ng service:

systemctl restart syslog-ng.service

This will of course silence ALL critical/fatal errors in the console, but for me this is not a problem. I've never needed that anyway.