2

I've tried to find out why I had some strange connections on my secure log file. Something like this :

Apr 23 11:35:43 li192-61 sshd[11651]: Did not receive identification string from 127.0.0.1
Apr 23 11:35:49 li192-61 sshd[11661]: Connection closed by UNKNOWN

I had many of these connections, each minute precisely. So I used the netstat command as netstat -ta --numeric-ports --program | grep 22 to get more info. I got this (I removed my own ssh connection) :

tcp        0      0 localhost:56145             localhost:22             TIME_WAIT   -

Next I tried to find which one is using this port, so I used lsof -i :22 and I got nothing except my own connection.

After I launched netstatcommand again, I got this :

tcp        0      0 localhost:45979             localhost:22             TIME_WAIT   -

A new port is using as remote destination from localhost through port 22. It's the same thing each minute.

I have no more ideas right now. So this my question :

Is there a way to get all process which are using ssh connection or get all process which are attempting to connect to a specific port (e.g: 45979) ?

Thank you for your time !

alexgindre
  • 25
  • 1
  • 6

3 Answers3

1

If you look at the netstat headers:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name

You'll see that the high "random" port is the local address. A program that established an outgoing connection requires a port on which to receive answers from the remote server. It receives a port in a high range for this.

What you are seeing are SSH connections from a local application/script to the localhost.

However it appears that the connection can not be established for some reason. The application does not properly authenticate itself.

So you are not looking for an application that connects to port 45979 but one that is conecting to port 22 on localhost. Most likely simply ssh localhost.

Check the times at which the connections are made then check your cron schedule and/or cron logs for those times.

Bram
  • 1,121
  • 6
  • 9
1

Correlate the process IDs of all these bogus connection attempts with the ones you're using youself; the process ID of your own connection should not change.

If it does, some setting is causing your connection to re-connect again and again (this is possible in SSH without loss of connectivity)

adaptr
  • 16,479
  • 21
  • 33
  • Indeed, my connection's PID doesn't change. When I used `netstat -nep --tcp`, I got this (I deleted all no needed values) : `tcp 0 24832 ::ffff:178.79.136.61:22 ::ffff:82.247.13.79:55835 ESTABLISHED 0 202122006 18182/sshd |tcp 0 0 127.0.0.1:55662 127.0.0.1:22 TIME_WAIT 0 0 -`. Each time a launched the command, I have got the same PID for my connection unlike the bogus ones. – alexgindre Apr 23 '12 at 11:04
1

There is a post here which suggests that this type of thing results when you have 2 competing sshd processes trying to bind to the same port.

You might want to get a local console, and run service sshd stop and then check ps -ef | grep sshd for any rogue sshd servers that are not under the control of the service wrapper.

Community
  • 1
Tom
  • 10,886
  • 5
  • 39
  • 62
  • As you suggest, I logged my self through local console, stopped sshd and launched `ps ax | grep "ssh" | grep -v "grep"`. I got nothing. But since that, I have no more connection from localhost. – alexgindre Apr 23 '12 at 10:46
  • I also used `netstat -lep --tcp` and nothing is listen on port 22. – alexgindre Apr 23 '12 at 10:53
  • in the netstat output, you are getting a "-" dash instead of the process id/name because the connection has been closed eg `TIME_WAIT - ` hence you might want to be a bit more aggressive with the "netstat -antp" and try and catch the output while its still connected. e.g. looking for an `ESTABLISHED` – Tom Apr 23 '12 at 11:31
  • there are more sophisticated ways to trap the process like using auditd with a socket() watch like described here - http://serverfault.com/a/193088/47650 but that is quite heavy weight for something like this – Tom Apr 23 '12 at 11:36
  • actually there is a tcpdump command to trap the process also described here http://serverfault.com/a/192920/47650 – Tom Apr 23 '12 at 11:37
  • Thank you @tom, I finally found where those connections come from. It's our monitoring tools (Zabbix) which check if the ssh connection is still possible. It's a custom task, I will modify it. – alexgindre Apr 23 '12 at 12:47