Home / ubuntu / Questions / 850590
Accepted
jirislav
Asked: 2016-11-18 11:49:51 +0800 CST

Why is ssh session still active if I've "killed" the ssh server?

  • 772

I've right now encountered that after you have connected to Ubuntu 14.04 via ssh and you change the sshd_config into an invalid state so that service ssh reload will cause the server to stop listening but will not close active ssh sessions I have established.

To reproduce the steps I've made:

  1. Connect to ssh server:

    ssh host

  2. Change /etc/ssh/sshd_config into invalid state, e.g. set:

    GatewayPorts 0.0.0.0:62222

  3. Reload the server configuration 

    sudo service ssh reload

  4. Check that the ssh connection established in step 1) is still active and you can enter anything you want.

  5. Do not close the established connection and try to connect to the server once again from another terminal:

    ssh host

And in my case, I've got this message:

ssh: connect to host IP_ADDR port SSH_PORT: Connection refused

That means the ssh server does not listen to incoming connections anymore, but somehow magically still runs and handles my established connection.

I think this could sometimes come up really handy to someone to lock himself into an ssh session, so that nobody else can connect to the server for sure and still being able of executing anything the user wants.

So the question is: Is this desired behavior? What is the original purpose of such implementation?

btw, I've noticed that the ssh server is in that case being in kinda inconsistent state:

$ service ssh reload
reload: Job is not running: ssh
$ service ssh start
start: Job is already running: ssh

So, to resurrect the server I had to run:

service ssh reload

Probably important notes:

  1. The Ubuntu server was configured by Mail-in-a-Box v0.20 and no further changes were made.
  2. Server provider (DigitalOcean) have set up for me two more rules in sshd_config:
    • ClientAliveInterval 120
    • ClientAliveCountMax 2
networking

1 Answers

  1. Best Answer

    Because the users connections run in different processes. It is quite useful feature.

    • It prevents your from locking yourself out of your server with a bad configuration
    • It is much more fail-proof: Failure of a single (user) process does not kill all the other connection
    • It gives much better performance than a single process handling all the connections
    • It is much more secure: the users are really separated to different processes.

    This is common practice to write TCP servers this way. It is a bit different than Apache for example, which is spawning several workers, that are reused for subsequent connections.

    • 4