Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a server running centOS 5; GLAMP. This is a local only setup--no outside access.

netstat reveals an ESTABLISHED ssh connection from a machine on the LAN. This machine is running XP, and has nothing on it that utilizes SSH:

# netstat | grep tcp
tcp        0      0 dev.test.local:ssh ::ffff:192.168.1.11:51486 ESTABLISHED 

Things I've tried:

  • added a rule to iptables to deny all from this machine
  • restarted networking, apache, sshd, and the whole machine eventually
  • temporarily changed IP of offending machine (can't permanently; people need it)
  • hping

An interesting note: while I was investigating hping to try and nuke the connection, I noticed that the machine would not respond to hping - 100% packet loss. However, normal ping works as expected. As such, hping -F host does not work because for some reason, hping does not reach the host.

This is all in an effort to try and decipher why all of a sudden apache seems so slow. There was a network change recently, but nothing that should have affected this part of the LAN. I don't know that this is part of the issue, but is a variable I need to eliminate.

Any ideas on how I can kill this connection?


UPDATE;

OK, it turns out I can't kill it, because it is my shell! However, it is not reflecting my proper IP address for some reason. When I fist connect, though, it says my last login was from the correct IP address, but netstat reveals the incorrect address:

Last login: Thu Oct 27 10:42:25 2011 from 192.168.1.17
# netstat | grep tcp
tcp        0      0 dev.test.local:ssh ::ffff:192.168.1.11:53461 ESTABLISHED 

Here is tail of /var/log/secure

Oct 27 10:42:25 dev sshd[6169]: Accepted password for root from 192.168.1.17 port 53428 ssh2
Oct 27 10:42:25 dev sshd[6169]: pam_unix(sshd:session): session opened for user root by (uid=0)
Oct 27 10:45:08 dev sshd[6169]: Received disconnect from 192.168.1.17: 11: disconnected by user
Oct 27 10:45:08 dev sshd[6169]: pam_unix(sshd:session): session closed for user root
Oct 27 10:45:24 dev sshd[6208]: Accepted password for root from 192.168.1.17 port 53461 ssh2
Oct 27 10:45:24 dev sshd[6208]: pam_unix(sshd:session): session opened for user root by (uid=0)
share|improve this question
add comment

3 Answers 3

up vote 1 down vote accepted

How about modifying /etc/ssh/sshd_config. For example you can choose the IPs allowed to login using ListenAddress or you can limit logins by AllowGroups and AllowUsers. You can see past logins by using wtmp or by looking at /var/log/secure.

share|improve this answer
    
I've updated my question. Secure log pointed me in the right direction, thanks. –  stormdrain Oct 27 '11 at 14:43
add comment

First of all, confirm that this is actually an ssh connection:

netstat -antp | grep ESTABLISHED | grep :22

You should see an additional column in the netstat output showing the application name connected to that TCP Session. If it's not /usr/sbin/sshd then this may not be an ssh session at all. You should investigate whichever application it is which is holding the TCP Session open.

If it is an ssh session, temporarily stop the ssh daemon:

/sbin/service sshd stop

(I'm not a CentOS user, if that gives an error indicating that the sshd service does not exist, try /sbin/service --list to identify the correct name to use).

Check the netstat output again and see if the connection is still open. If it is, ensure that the sshd daemon has stopped:

ps -A | grep -i ssh

Ensure there are no sshd processes running, then recheck the netstat output. If there are still sshd processes, try:

killall -KILL sshd

And again, recheck your netstat output.

This should allow you to close things down temporarily at the server side.

You can more permanently prevent connections at the server side by either stopping and disabling the sshd service if it's not required, or by altering your sshd configuration to allow connections only from specific IP Addresses or IP Address Ranges.

However, you should also attempt to identify the machine which has made the connection to your server in the first place, and ensure that it doesn't have any ssh related software such as PuTTY installed which may be being used to initiate the connection.

share|improve this answer
    
Yeah, it's strange. I'm running OSX on this machine (192.168.1.17) and using terminal to ssh into the centOS box. That is the only access I have to it; it is a datacenter. netstat -antp reveals 6208/1 in the extra column (whatever that means). –  stormdrain Oct 27 '11 at 15:00
add comment

UPDATE

sshd show the IP address of the last login but netstat print the current.


Run the following command as root:

echo "sshd: 192.168.1.11" >> /etc/hosts.deny
share|improve this answer
    
The problem seems to be that centOS box is doing something that is aliasing .17 to .11 I'm connecting from .17 which shows up in netstat as .11 and in secure log as .17: 11: If I do as you suggest, I won't be able to connect anymore. –  stormdrain Oct 27 '11 at 15:35
    
The command I said is answered for your original question. I would suggest your sniffing some packets from .11 and open with Wireshark to see what does it say: tcpdump -vv -s0 tcp port 22 and dst 192.168.1.11 -w /tmp/sshfrom11.pcap. –  quanta Oct 27 '11 at 15:42
    
If I run it only connected from my OSX box (which shows as .11 in netstat and aliased in secure.log as .17: :11) it captures nothing. Perhaps the issue is with netstat itself. who shows correct info, as does the login message (last login from..). Netstat is incorrect and I'm not sure what the .17: :11 is in secure.log –  stormdrain Oct 27 '11 at 16:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.