I saw an "Illegal users from:" entry in my Logwatch email this morning from some IP address that I did not recognize. This is unusual, first time in a long time since I closed port 22 on my firewall. Trying to dig deeper I grep'ed the IP address in /var/log and found the following:

auth.log:Jul 25 18:28:56 linux2 sshd[2013]: Invalid user ubnt from 185.212.149.205 port 20113

What is bothering me is that sshd is not listening on port 20113! I don't understand how sshd can be reporting a login attempt from a port it is not listening on?

My question is: How can this happen???

Some background:

My firewall blocks (stealths) port 20113 (and port 22) as confirmed by "ShieldsUP!" (grc.com).

sshd is configured to listen on port 22 for local traffic (192.168.254.0/24) and one high numbered port which is port forwarded to my Linux system for my access when traveling.

No one is listening on port 20113 as confirmed by netstat -nl.

Attempting to ssh into the system using -p 20113 results in "Connection refused"

Linux version: Ubuntu 18.04.5 LTS

Router: Frontiern Communications Arris NVG443B Version: 9.3.0h3d36

Additional Question: Is there a bug in reporting the port number in sshd? When investigating the above I connected to my Linux system with ssh and specified my external port number. Then after disconnecting I looked at my auth.log file and found:

Jul 26 10:13:12 linux2 sshd[12546]: pam_unix(sshd:session): session opened for user glenn by (uid=0)
Jul 26 10:13:12 linux2 systemd-logind[1478]: New session 136 of user glenn.
Jul 26 10:13:16 linux2 sshd[12683]: Received disconnect from 192.168.254.2 port 46772:11: disconnected by user
Jul 26 10:13:16 linux2 sshd[12683]: Disconnected from user glenn 192.168.254.2 port 46772
Jul 26 10:13:16 linux2 systemd-logind[1478]: Removed session 136.
Jul 26 10:13:16 linux2 sshd[12546]: pam_unix(sshd:session): session closed for user glenn

The port referenced (46772) is NOT one of the ports that sshd listens on!
If sshd garbles port numbers when logging it could explain my first question.

Unless that is the source port and not the destination port. Source ports are random. I am not an sshd log expert by any means though. Assuming 185.212.149.205 is the "attacker"?

To elaborate TCP communications happens on two ports i.e. the source and destination. The client sends data in this case to your ssh port and receives data as posted on a random high port. To see this in action login in to your server from another computer on the LAN or the server itself. With however you have ssh configured as an example from my system.

ssh -p XXXXX -i key_name username@IP_address

As root from the output of the netstat command which may or may not be installed by default.

netstat -np | grep ssh
If you compare the foreign address port with your ssh logs you will find they will match like:
Changing ports will not keep the current cyber criminals from finding your system. Securing your system is a multi-step process.

2 members found this post helpful.

The port number shown in the sample log file entry, port 46772, was the source port connecting from address 192.168.254.2. Offhand I can't think of why the source port would be relevant in logging, aside for symmetry with the destination port, because it is mostly random. But it's there.

Indeed. The services are generally found with a quick scan. With so much cheap hosting on fat pipes these days you can scan all possible ports on all known IPv4 addresses in a few hours. The same goes for the IPv6 network segments alloted so far. I presume at least some groups of attackers even share uptodate lists of services they have identified.

For hardening the system, using either SSH keys or SSH certificates and disabling password authentication is considered an established best practice. Same for completelyt disabling remote login for root.

2 members found this post helpful.

In addition to Turbocapitalist's excellent closing comments, consider also using "OpenVPN" as your "moat" line of defense, leaving "ssh" as the "portcullis" which can only be reached when you (find and ...) cross the drawbridge. Your "sshd" daemon does not listen to the public-facing ports and is in fact firewalled away from them. It can only listen to the virtual addresses represented by those who have passed the VPN.

For this layer, use unique 4096-bit self-signed digital certificates which are unique to each user – and therefore, individually revocable. (But, unlike a ssh user adding to authorized-keys, they can't do this themselves. As a further defense, use tls-auth, which uses a second certificate to "tell the OpenVPN server to even answer the phone" when somebody calls wanting to connect.

At the portcullis (ssh ...), as Turbocapitalist recommends, "there is no login: prompt." Either you possess the additional certificate which sshd requires, or you are S.O.L.

When you combine these two forms of defense, authorized users pass right through with little inconvenience, while unauthorized users can't even find the drawbridge. And, when (say ...) "someone leaves the company," you can remove their access without impacting anyone else.

1 members found this post helpful.

LQ Responders,

Thanks for all the useful replies!

I don't know why I did not think that sshd would be logging the source port instead of the destination port for an incomming login request. Head Slap Moment :-)

After reviewing your replies, and using WireShark, I have confirmed that sshd is in fact reporting the source port in auth.log.

For someone like me who has sshd listening on multiple ports, having the destination port listed would be more useful. If the destination port is 22, I know the request did NOT come through one of my router/firewalls. If the destination port is other than 22, I can tell which port forwarding router/firewall the request did come from. The source port does not help me track down the path by which a bogus login attempt reaches my system. However, that's something that I should take up with the authors of sshd.

Finally, on your recomemdations, and after fiddleing around with the poorly documented Android "ConnectBot" public/private key pair process, I have been able to disable password authentiction on my Linux systems.

Thanks again,
Glenn