In which order is ssh checking an incoming request?

[hartings]

Hi, I posted my problem about someone logged into my server and changed the root password, see post here:

! Someone entered my system and changed root passwd - edited

Hi This. morning I read in the logwatch report from last night: A total of 1 possible successful probes were detected (the following URLs contain strings that match one or more of a listing of strings that indicate a possible exploit): /?file=php://filter/convert.base64-encode/resource=/etc/passwd HTTP Response 200 What can I do to lock-out such possible intruders? I did login via direct access to machine following the very clear procedure outlined here: How to Reset a Lost Root …

I am very greatful for all input I received and have also describedat at the end of that thread what I have done to prevent / make it much harder in the future.

I check my server and my logwatch files daily and I don’t understand what I see, typically:

sshd-session: Disconnected from invalid user David 182.93.50.90 port 39270 [preauth]: 1 Time(s)
...
sshd-session: Invalid user David from 182.93.50.90 port 39270: 1 Time(s)
...
sshd-session: Received disconnect from 182.93.50.90 port 39270:11: Bye Bye [preauth]: 1 Time(s)
...
sshd-session: User root from 103.163.118.115 not allowed because not listed in AllowUsers: 20 Time(s)

I see hundreds of similar lines, with different user names (expected), IP addresses (expected) and different ports (not expected…)
My ASUS router only forwards ssh requests through one specific port (not 22 ). Only a few other ports are being forwarded (to web-server and mail-server related ports, and of course ssh)
So how can a request via for instance port 39270 (which is not forwarded) reach the server?? Hundreds of ssh requests arrive at the server through ports that are not forwarded at all by the router. Am I missing something very important here?

I also have a list of allowed user(s) (in fact only one special user - not root- is allowed to use ssh).

I also have enabled the usage of ssh key with a passphrase. None of the ssh requests seem to have the right key, so why are those request registered? Aren’t they refused up front?

What I am trying to understand is:

• How can all those ssh requests get through the router and reach the server? Port forwarding is specified only for a limited number of ports for specific functions.
• in what order are the security measures applied when an ssh requests arrives at the server: user name, ssh key, passphrase?

Thanks for any info that could educate me and prevent problems!

[hortimech]

I am no expert here, but if someone from Macau is getting into your system on port 39270, then it looks like port 39270 is open on your ASUS router. I would ensure that no ports on the router are open (use a VPN if you must get through your router) and just allow SSH internally.

[iwalker]

@hartings

I see hundreds of similar lines, with different user names (expected), IP addresses (expected) and different ports (not expected…)

If the port is publicly available, and assuming 39270 is your SSH port, then you will see those kind of lines. They got disconnected, so never actually got an SSH session. They tried, and that is all.

If you don’t want those lines to appear, then you can do:

1. Restrict access by using a VPN - as suggested by @hortimech
2. Restrict SSH access to only specific public IP addresses that you use - could be hard if you don’t have static public IP’s to connect from.
3. Use fail2ban and enable that to ban and block people when they attempt and fail to connect. You will still see the lines, but they will get blocked and have to try from another IP at that point. I used to configure fail2ban to block SSH after 3 tries, and ban them for a month.

[hartings]

Hi Ian,

Thanks for the reply!
My problem is that my ssh port is not 39270 or any on the hundreds of port numbers that are in the logwatch file. How can they appear in the log of the server, when the router doesn’t forward those ports (like 39270) to the server?

I have checked the portforwarding list in the router and only a few basic ports (web, mail etc) are forwarded to the server. I don’t use DMZ or anything similar which could expose the server to all incoming requests. I don’t understand I can see a request on a port like 39270 on the server…
What am I missing here?

Thanks!

Den 15 september 2026 12:40:15 CEST, Ian Walker notifications@rockylinux.discoursemail.com skrev:

[iwalker]

On your ASUS router did you configure the DMZ option to redirect to your server? If so, then all ports will go to it. Otherwise difficult to tell, but if the ASUS router is before the server, then that port must be redirected somehow. Otherwise it’s simply not possible to connect otherwise.

Also, suggest checking on your Rocky server what ports are actually listening, eg:

netstat -tunlp

or the replacement command for it:

ss -tunlp

and post the results. Maybe a port is open here because the server was previously hacked and a process is providing remote access on that port. If UPNP is enabled on the ASUS router that can also cause problems. I always disable UPNP as it serves no purpose (I don’t like things happening automatically) - I configure things manually.

[felfert]

@hartings

I see hundreds of similar lines, with different user names (expected), IP addresses (expected) and different ports (not expected…)

The port numbers in your list are the client ports from THEIR side, not YOUR port.

It is normal to see that many attempts if your machine is accessible from the internet. It also proves, that “hiding” your ssh behind some custom “hidden” port is generally useless, because they simply scan ALL possible ports and attempt brute-force if they find an SSH banner (regardless of the port number).

I run a public server with SSH running on port 22 and I have ~1483 attempts in the last 16 hours.
Never got hacked in , because I don’t allow passwords and combine pubkey auth with TOTP and (like you) use AllowUsers to limit possible users to very few real people.

Just an example log from my server this morning:

Sep 15 06:50:25 redacted.server.name sshd-session[913340]: Invalid user verification from 210.183.36.50 port 50908 
Sep 15 06:50:25 redacted.server.name sshd-session[913341]: Invalid user verification from 210.183.36.50 port 50912 
Sep 15 06:50:25 redacted.server.name sshd-session[913342]: Invalid user verification from 210.183.36.50 port 50924 
Sep 15 06:50:25 redacted.server.name sshd-session[913343]: Invalid user verification from 210.183.36.50 port 50928 
Sep 15 06:50:25 redacted.server.name sshd-session[913345]: Invalid user verification from 210.183.36.50 port 50964 
Sep 15 06:50:25 redacted.server.name sshd-session[913344]: Invalid user verification from 210.183.36.50 port 50954 
Sep 15 06:50:25 redacted.server.name sshd-session[913346]: Invalid user verification from 210.183.36.50 port 50978 
Sep 15 06:50:25 redacted.server.name sshd-session[913348]: Invalid user verification from 210.183.36.50 port 50988 
Sep 15 06:50:25 redacted.server.name sshd-session[913349]: Invalid user verification from 210.183.36.50 port 51000 
Sep 15 06:50:26 redacted.server.name sshd-session[913347]: Invalid user verification from 210.183.36.50 port 50962

In this example, the ports 50908-50962 are those used by the attacker (judging from the timestamps probably a multithreaded attempt)

Cheers
-Fritz

[mashcraft]

The wide range of port numbers you are seeing are the client ports. The log shows the client IP address and TCP Port. These might be from a NAT device like a local router or the actual IP and Port depending on your network configuration. The local IP address and TCP Port of your ssh daemon are known and not included in the log entry.

[hartings]

Thanks @iwalker! This was a very helpfull tip!
I ran the command and discovered a lot of ports with 5 digits numbers, which I didn’t enabled myself. It shows that these unexpected ports were related to an old version of Flex Media Player. I had installed it some years ago to test, but never really used it and then forgotten all about it …

I googled (Gemini) on possible exploits due to Flex and found serious warnings, some quite recently:

Major Vulnerabilities

• Recent Unspecified Flaws (September 2026): Plex issued an urgent advisory for server versions 1.43.2 and earlier due to critical security issues. Tens of thousands of internet-exposed instances remained unpatched. [1, 2]
• CVE-2025-34158 (August 2025): A critical improper input validation flaw with a maximum CVSS severity score. It allowed unauthenticated remote attackers to execute actions or access private data over the internet without user interaction. Over 300,000 exposed servers were left vulnerable. [1, 2]
• CVE-2020-5741: An older remote code execution vulnerability in Plex Media Server that saw active exploitation in the wild. [1]

So I disabled Plex Media Server immediately and also disabled the auto-enabling-on-boot.
Now the server only listens to ports I have included in the port-forwarding on the router!

I suspect Plex was responsible for the intrusion and change of root password I reported on earlier.

My second thought is to also follow your recommendation to disable UPnP in the router. This is indeed an uncontrolled security-bypass feature. I will first test if I loose some required “smart” functions, but otherwise I plan to block this router feature.

I learned a lot the hard way and as a consequence, made my ssh server MUCH more robust thanks to all help in this forum!

Many thanks again for your suggestions/help!

[DaveAtFraud]

When I had an open ssh port on my firewall I found moving ssh to some custom port at least eliminated all of the connection attempts from script kiddies. No delusion that someone scanning all ports wouldn’t find the ssh port. Just eliminated a few thousand fails from my logs so I could more easily see the important stuff.