1

Here is the whole scenario:

  1. installed ssh apt-get install ssh
  2. created a new user (I know I didn't have to)
  3. logged into the system via ssh using the new user
  4. modified the /etc/ssh/sshd_config to allow root login
  5. issued the command systemctl status ssh
  6. it showed that service was running
  7. issued systemctl stop ssh (I know I could have used service cmd)
  8. I was still logged in via ssh! not sure how that works
  9. opened a new putty instance and tried to connect and it said service not accessible/timed out
  10. issued systemctl start ssh and tried logging in as user with new putty instance and it worked

I was wondering why it didn't tear down the first instance (new user log-in via ssh)? was it because when I initially logged in, the ssh accepted the connection on port 22 and opened a new web socket port (multi-thread) and assigned my connection to that port and was listening to another connection on port 22 and when I logged in after stopping the service it said timed out?

I'm sure ssh doesn't keep track of the random port it opens, would you say it could possibly be a bug (not broken). Shouldn't the c program also keep track on ssh and also take down instances when ssh service has been stopped. any thoughts?

Improve this question
2
  • Worth noting is that step 7 was correct, you should use systemctl and not service if you're using a distro with systemd. If you use the service command on a systemd distro it just calls systemctl and warns you: service httpd status: Redirecting to /bin/systemctl status httpd.service Commented Jan 20, 2017 at 16:44
  • Such an obvious bug in such an old project would have been squashed ages before you wrote this question. Commented Jul 10, 2019 at 6:52

1 Answer 1

Reset to default
8

This is intentional. When you connect to a system using SSH, the daemon on the target system spawns a new sshd process, or even two (one running as root, the other as the target user). The SSH session is handled by this new process, not the original one. From the manpage:

sshd listens for connections from clients. It is normally started at boot from /etc/init.d/ssh (or /etc/init/ssh.conf on systems using the Upstart init daemon). It forks a new daemon for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange.

When you stop the service, only the main daemon stops; the daemons which are managing sessions keep running. This is what enables you to restart the SSH server without losing your sessions — this is particularly handy when you get the configuration wrong and the server doesn't restart...

Improve this answer
1
  • thanks! i was wondering if this was intentional or a bug. many thanks! Commented Jan 20, 2017 at 16:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.