sshd "connection closed" in log with no "connect" message

David Aldridge
David Aldridge used Ask the Experts™
on
How can I get:

secure:Jul 20 11:11:24 DL140RH sshd[4822]: Connection closed by 88.84.133.135

in my /var/log/secure without there being any record of a connection?  I have grepped for it in secure .1 .2 .3 and .4.  There has been a reboot during secure.1 so it would have had to occur after that obviously.  I am running Centos 4.2 with the 2.6.9-78.0.22.ELsmp kernel.

Thanks!
David
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Author

Commented:
btw, my ssh server is set up to only accept keys; no passwords.
Top Expert 2007

Commented:
were you able to connect and login before? Any changes done recently ? do you have a firewall that might be resetting the connections?

Author

Commented:
I have no problem connecting at all.  That's the problem though, no one else should be able to connect because no one else has an account on that server and it only accepts keys and not passwords.  As a matter of fact, if they attempt to log in withouit a password, their IP address is added to iptables to -DROP.

I don't know who owns this 88.84.133.135 IP address.  I am wondering how I can get a "secure:Jul 20 11:11:24 DL140RH sshd[4822]: Connection closed by 88.84.133.135" when they should nevere be able to connect.
Acronis in Gartner 2019 MQ for datacenter backup

It is an honor to be featured in Gartner 2019 Magic Quadrant for Datacenter Backup and Recovery Solutions. Gartner’s MQ sets a high standard and earning a place on their grid is a great affirmation that Acronis is delivering on our mission to protect all data, apps, and systems.

Top Expert 2007

Commented:
It could be that someone from that ip is trying to connect to your system but unable to login then connection is dropped / closed

Author

Commented:
That's what I normally see, but on this one, there is no connect or connect attempt message.
Top Expert 2007

Commented:
is this the only attempt? Any chance that it was not logged properly? Do you see logs for the same ip address?

Author

Commented:
I have never come across an instance where sshd didn't properly log an attempt to connect to the "secure" log.  I suppose that's possible.  I have searched all of the logs (even logs from before the last reboot) and this is the only instance of that IP address appearing anywhere.

Author

Commented:
This one's driving me nuts.  I'll raise the ante as high as I can.
Most Valuable Expert 2015

Commented:
Add this to iptables before any ssh denies (if they are restricted):

iptables -A <YOUR INPUT RULE> -p tcp -m tcp --dport 22 -j LOG

check:

ls -al /tmp
last -100
grep 88.84.133.135 /var/log/*

Run chkrootkit to be sure your machine is good:

http://www.chkrootkit.org/download/

If you are not restricting ssh via iptables, I would recommend doing so.  If you are not running iptables, I would recommend doing so.

Author

Commented:
I'm running sshdfilter which seems to be doing a nice job of blocking hack attempts.  Here's what my iptables looks like right now (the ACCEPT has been changed to protect the innocent).  As you can see, it's added 2 IP addresses to be dropped since the last reboot.  How would I add your suggestion to my current configuration or is it even necessary since I'm only accepting keys and a passphrase?  I'll run the rootkit check as you suggested.  I'm really doubting anything is up like that because this is a fairly new server (3 months since OS install?) and I have never accepted passwords only externally:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  where I work.com  anywhere            tcp dpt:ssh
ACCEPT     tcp  --  myinternal network       anywhere            tcp dpt:ssh
SSHD       tcp  --  anywhere             anywhere            tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain SSHD (1 references)
target     prot opt source               destination
DROP       tcp  --  58.196.29.31         anywhere            tcp dpt:ssh
DROP       tcp  --  202.103.190.97       anywhere            tcp dpt:ssh
Most Valuable Expert 2015
Commented:
I doubt you're rooted, either.  It's just a precaution that I take when I see something that I don't like and can't explain.

I would put the 'log' in front of the initial ssh accept statements.

You can either rewrite iptables to insert that statement or stop iptables, add the log statement to /etc/sysconfig/iptables and start iptables.

Author

Commented:
I just think I'm going to have to write this one incident off as just an annomily and start logging everything as you suggest.  Thanks for the help.  I'll add LOG now.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial