When monitoring SSH (tcp/22), the monitored server logs "key_exchange_identification" errors. #3439

New issue

Closed

opened 2026-02-28 03:29:30 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-28 03:29:30 -05:00

Owner

Originally created by @di-org on GitHub (Jun 29, 2024).

N/A

🛡️ Security Policy

I agree to have read this project Security Policy

Description

After setting up a "TCP Port" monitor for a hardened SSH service (tcp/22), every check is logged with an error for the key exchange, and though the service does show as up - it leaves behind a lot of log entries of connection errors:

---log---
Jun 29 20:30:53 ociph01 sshd[633660]: error: kex_exchange_identification: Connection closed by remote host
Jun 29 20:30:53 ociph01 sshd[633660]: Connection closed by 199.xxx.xxx.xxx port 52688
---log---

(to note, the masked IP is my Uptime-Kuma server host)

👟 Reproduction steps

Add the following lines to the monitored server's /etc/ssh/sshd_config file, and restart OpenSSH (My host is running Ubuntu 22.04):

Ciphers aes256-ctr
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms ecdh-sha2-nistp521

Monitor /var/log/auth.log for the error messages with the source IP of the Uptime-Kuma server. To note, the Key Exchange error does not have the IP of the offending host, but it is immediately followed by a "Connection closed" message from the source server.

👀 Expected behavior

There are a couple of options:

If it is just purely a "is this port open" check, it should not try to negotiate any ciphers, KEX or MAC algorithms.
If, based on the port being tcp/22, it actually attempts a cipher negotiation, that an SSH library would be used which supports all modern cipher, KEX and MAC algorithms.

For #1, if I use a port scanner such as NMAP, when I test only to see if tcp/22 is open, there are no error messages logged because it doesn't attempt to negotiate SSH. I would expect uptime-kuma to only test if it returns a SYN-ACK, if it is looking to see of a port is open, and then send a FIN packet back to close the connection.

The alternative would be a full TCP handshake (if running as an unprivileged user), but still hang-up before an SSH negotiation occurs - standard practice for a port scanner (unless specifically testing functions that require negotiating the encryption protocols, such as bute-forcing, listing supported algorithms, authentication methods, etc).

For #2, if uptime-kuma is attempting things like cipher, KEX and MAC negotiations, it should be able to support all implemented encryption algorithms - in this case, the Key Exchange Algorithm "ecdh-sha2-nistp521".

😓 Actual Behavior

(to note, the masked IP is my Uptime-Kuma server host, and otherwise is not making connections to TCP/22 to host "ociph01")

🐻 Uptime-Kuma Version

Version: 1.23.13

💻 Operating System and Arch

Ubuntu 22:04 x64

🌐 Browser

Librewolf 127.0.2-2

🖥️ Deployment Environment

Runtime: Docker version 24.0.7, build 24.0.7-0ubuntu2~22.04.1

📝 Relevant log output

No response

Originally created by @di-org on GitHub (Jun 29, 2024). ### 📑 I have found these related issues/pull requests N/A ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description After setting up a "TCP Port" monitor for a hardened SSH service (tcp/22), every check is logged with an error for the key exchange, and though the service does show as up - it leaves behind a lot of log entries of connection errors: ---log--- Jun 29 20:30:53 ociph01 sshd[633660]: **error: kex_exchange_identification: Connection closed by remote host** Jun 29 20:30:53 ociph01 sshd[633660]: Connection closed by 199.xxx.xxx.xxx port 52688 ---log--- (to note, the masked IP is my Uptime-Kuma server host) ### 👟 Reproduction steps Add the following lines to the monitored server's /etc/ssh/sshd_config file, and restart OpenSSH (My host is running Ubuntu 22.04): Ciphers aes256-ctr MACs hmac-sha2-512-etm@openssh.com KexAlgorithms ecdh-sha2-nistp521 Monitor **/var/log/auth.log** for the error messages with the source IP of the Uptime-Kuma server. To note, the Key Exchange error does not have the IP of the offending host, but it is immediately followed by a "Connection closed" message from the source server. ### 👀 Expected behavior There are a couple of options: 1. If it is just purely a "is this port open" check, it should not try to negotiate any ciphers, KEX or MAC algorithms. 2. If, based on the port being tcp/22, it actually attempts a cipher negotiation, that an SSH library would be used which supports all modern cipher, KEX and MAC algorithms. For #1, if I use a port scanner such as NMAP, when I test **only** to see if tcp/22 is open, there are no error messages logged because it doesn't attempt to negotiate SSH. I would expect uptime-kuma to only test if it returns a SYN-ACK, if it is looking to see of a port is open, and then send a FIN packet back to close the connection. The alternative would be a full TCP handshake (if running as an unprivileged user), but still hang-up before an SSH negotiation occurs - standard practice for a port scanner (unless specifically testing functions that require negotiating the encryption protocols, such as bute-forcing, listing supported algorithms, authentication methods, etc). For #2, if uptime-kuma is attempting things like cipher, KEX and MAC negotiations, it should be able to support all implemented encryption algorithms - in this case, the Key Exchange Algorithm "ecdh-sha2-nistp521". ### 😓 Actual Behavior ---log--- Jun 29 20:30:53 ociph01 sshd[633660]: **error: kex_exchange_identification: Connection closed by remote host** Jun 29 20:30:53 ociph01 sshd[633660]: Connection closed by 199.xxx.xxx.xxx port 52688 ---log--- (to note, the masked IP is my Uptime-Kuma server host, and otherwise is not making connections to TCP/22 to host "ociph01") ### 🐻 Uptime-Kuma Version Version: 1.23.13 ### 💻 Operating System and Arch Ubuntu 22:04 x64 ### 🌐 Browser Librewolf 127.0.2-2 ### 🖥️ Deployment Environment - Runtime: Docker version 24.0.7, build 24.0.7-0ubuntu2~22.04.1 ### 📝 Relevant log output _No response_

deekerman

2026-02-28 03:29:30 -05:00

closed this issue
added the
A:monitor

help
labels

deekerman commented

2026-02-28 03:29:34 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 29, 2024):

I think I am missing something.
We are not doing a ssh keyexchange via the TCP Port monitor (nor should we).
=> the log is accurate that the connection is closed during that part.

For the behaviour: we are using https://www.npmjs.com/package/tcp-ping

as soon as connection gets accepted, it's dropped and a new measure is conducted immediately

You can try if #4806 changes this via https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

@CommanderStorm commented on GitHub (Jun 29, 2024): I think I am missing something. We are not doing a ssh keyexchange via the TCP Port monitor (nor should we). => the log is accurate that the connection is closed during that part. For the behaviour: we are using https://www.npmjs.com/package/tcp-ping > as soon as connection gets accepted, it's dropped and a new measure is conducted immediately You can try if #4806 changes this via https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests