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.

was connected to a server via ssh through port 22, and decided to kill all the users connected with the root user with the following command:

pkill -9 -u root

Now when I try to log in by root@190.169.94.56, I get the message:

ssh: connect to host 190.169.94.56 port 22: Connection refused

I make sure that SSH is indeed running on the port 22. On the server machine, I run:

 netstat -untap | grep 190.169.94.56
    (Not all processes could be identified, non-owned process info
    will not be shown, you would have to be root to see it all.)
    tcp        0      0 190.169.94.9:41267      190.169.94.56:22        ESTABLISHED 29673/ssh

I did ping the server 190.169.94.56 and responds correctly:

ping 190.169.94.56
PING 190.169.94.56 (190.169.94.56) 56(84) bytes of data.
64 bytes from 190.169.94.56: icmp_seq=1 ttl=64 time=0.524 ms
64 bytes from 190.169.94.56: icmp_seq=2 ttl=64 time=0.454 ms
64 bytes from 190.169.94.56: icmp_seq=3 ttl=64 time=0.423 ms
64 bytes from 190.169.94.56: icmp_seq=4 ttl=64 time=0.419 ms
--- 190.169.94.56 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.419/0.455/0.524/0.042 ms

I tried change the port and i obtain the same result. How can I connect to it again? It's a Debian machine, in case that matters.

share|improve this question
1  
The listening sshd isn't running; the netstat step that you think proves it is, doesn't. Restart sshd. –  MadHatter Apr 10 at 16:10
    
@MadHatter I am currently connected to the server: 190.169.94.56 through another server: 190.169.94.9 using ssh, in which the server should restart sshd?. I can not login directly to the server: 190.169.94.56 without making a jump from 190.169.94.9. –  franvergara66 Apr 10 at 16:19
3  
You probably have killed the SSH daemon with your pkill, cause the sshd normally launches with the root user. The connection shown on your netstat is related to the one that is open and running. The ports that are ready and Listening for new connections will look like this: tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9626/sshd . Restart/reload your ssh to get things back again. –  nwildner Apr 10 at 16:40

3 Answers 3

up vote 12 down vote accepted

To check if it is running, you would have to run netstat -tnpl | grep :22 and ps aux | grep sshd. SSHD keeps your connection open even if you stop it so that you don't lose control over the server if you make, for example, a mistake in sshd_config before restarting it.

EDIT:

I confess that only now I saw your pkill -u root -9 command. This is VERY wrong and I would tell you to actually reboot your server because you killed important system processes (like the log daemon and so on).

share|improve this answer

If your goal was only to disconnect all connected users with root user, then pkill is the wrong command. pkill stops every process owned by the specified user, it does not restrict itself to logged in users only.

You should check running processes with @Florin Asavoiae's commands on the server that refuses connections, and then use /etc/init.d/ssh start to start the sshd.

If you can create new SSH connections to 190.169.94.56 via an intermediate server, then there is some other issue going on, maybe a firewall blocking traffic.

share|improve this answer

There's two different kinds of sshd that run on a Linux system: there is a "master" sshd running as root which listens for new connections, and there is the user level sshd which runs as the user id and which the master sshd forks off when the connection is established and the user is authenticated. What you did with your pkill command was to kill the master sshd but not kill your already running user-level sshd. To fix this, you switch user (su) to root on the host where you ran the pkill, and issue the following: service sshd restart

share|improve this answer

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.