How can I correctly check on what network interface SSH is listening on a Linux machine?

Question

I am not a system engineer or a network expert (I am more a software developer) and I have the following problem that I have to solve.

I am working on an Oracle Linux machine (basically it should be RedHat based).

I have to check on what network instances SSH is listen on this VM. I was using this link as reference: https://access.redhat.com/solutions/260463

It show how to use this command (this is the previous website example):

$ grep sshd netstat
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      0          12412      3522/sshd           off (0.00/0/0)

The problem is that if I try to replicate the same command on my machine I obtain this error message:

[root@zabbix-db ~]# grep sshd netstat
grep: netstat: No such file or directory

Why? What is wrong? What am I missing? How can I correctlu perform this check? and what is the exact meaning of this error (it speacks about a file that doesn't exist but, from my understanding I am grepping on the netstat output and not on a file)

Answer 1

it speacks about a file that doesn't exist but, from my understanding I am grepping on the netstat output and not on a file

No, you are in fact grepping a file named netstat.

To actually run "netstat" as a command, feeding its output to grep, you need to use a pipe:

netstat | grep sshd

Note that the default output of netstat will not actually show listening sockets at all – you need to specify -l (--listening) to include them in the output. Additionally, it won't mention the program name by default; that column is added by the -p (--processes) option. Finally, as you want to see the actual IP addresses, add -n (--numeric) to disable "reverse DNS" lookups.

netstat --listening --processes --tcp --numeric | grep sshd
netstat -l -p -t -n | grep sshd
netstat -lptn | grep sshd

…to only show listening TCP sockets, with their program names, without reverse DNS lookup.

The same applies to ss, which many Linux distributions now ship as an alternative to netstat:¹

ss -lptn | grep sshd

---

¹ There is nothing particularly wrong with 'netstat', but it comes as part of the "net-tools" package which itself is quite unmaintained and its other tools, such as 'ifconfig', have serious issues so the package as a whole is often no longer installed.

Answer 2

The general syntax for the grep command is:

grep target-pattern filename

so grep is not finding a file called 'netstat' - which is not surprising as it's a command.

There's a few ways to achieve what you want; for example, you can run netstat with some command elaborations and send the output through grep to only return matches for 'sshd':

netstat -plunt | grep sshd

On my (Debian) server, this gives:

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1571/sshd: /usr/sbi
tcp6       0      0 :::22                   :::*                    LISTEN      1571/sshd: /usr/sbi

Answer 3

I found the following an easier way to confirm connection route, using putty, and ifconfig.

1. open putty session from any other device via the interface to validate, for example ssh [email protected], once the session is open, run top.

2. open putty session from any other device via any other interface, for example ssh [email protected], note different network 1 vs. 2 in 3rd Octet. Now via ifconfig disable the interface using 192.168.2.250.

3. In the session in step 1, top should freeze, and ultimately the putty session will time out.

Developed this method to validate an issue where where specific protocols where failing over a 10GB network, for no apparent reason, and since Windows is completely useless at times tracking down SMB issues, needed something 100 percent Linux side. Given ping worked, ssh worked, but SMB fails... go figure. So the question then became, is SMB doing some weird routing? And thus, needed a method to test the 10GB NIC with a protocol other than SMB. Clearly, ping worked but that was to low level, so used SSH to validate that the issue is clearly a software/protocol stack issue impacting or specific to SMB, in my situation.

You can use telnet via any defined port, to validate in a similar manner as well.

Watching the above sequence via TCPDump or WireShark is interesting as well, but that maybe do deep into the weeds for a simple validation check of a given protocol, ssh in this case.