1

When I start the sshd process using systemctl the process starts successfully but is terminated ~5 seconds later. When I run the ExecStart command on the command line ssh runs without any issues.

Can anyone tell me why systemd might be sending a sigterm to sshd when started using systemctl?

I'm running SLES12-SP2.

Output of "systemctl status sshd" just after running "systemctl start sshd":

● sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2017-07-09 12:51:10 BST; 2s ago
  Process: 21727 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
 Main PID: 21734 (sshd)
    Tasks: 1 (limit: 8192)
   CGroup: /system.slice/sshd.service
           └─21734 /usr/sbin/sshd -D -ddd

Jul 09 12:51:10 Duke sshd[21734]: debug1: rexec_argv[2]='-ddd'
Jul 09 12:51:10 Duke sshd[21734]: debug3: oom_adjust_setup
Jul 09 12:51:10 Duke sshd[21734]: debug1: Set /proc/self/oom_score_adj from 0 to -1000
Jul 09 12:51:10 Duke sshd[21734]: debug2: fd 3 setting O_NONBLOCK
Jul 09 12:51:10 Duke sshd[21734]: debug1: Bind to port 22 on 0.0.0.0.
Jul 09 12:51:10 Duke sshd[21734]: Server listening on 0.0.0.0 port 22.
Jul 09 12:51:10 Duke sshd[21734]: debug2: fd 4 setting O_NONBLOCK
Jul 09 12:51:10 Duke sshd[21734]: debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
Jul 09 12:51:10 Duke sshd[21734]: debug1: Bind to port 22 on ::.
Jul 09 12:51:10 Duke sshd[21734]: Server listening on :: port 22.

Output of "systemctl status sshd" just around 5 seconds later:

● sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2017-07-09 12:51:12 BST; 2s ago
  Process: 21734 ExecStart=/usr/sbin/sshd -D -ddd $SSHD_OPTS (code=exited, status=0/SUCCESS)
  Process: 21727 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
 Main PID: 21734 (code=exited, status=0/SUCCESS)

Jul 09 12:51:10 Duke sshd[21734]: debug2: fd 3 setting O_NONBLOCK
Jul 09 12:51:10 Duke sshd[21734]: debug1: Bind to port 22 on 0.0.0.0.
Jul 09 12:51:10 Duke sshd[21734]: Server listening on 0.0.0.0 port 22.
Jul 09 12:51:10 Duke sshd[21734]: debug2: fd 4 setting O_NONBLOCK
Jul 09 12:51:10 Duke sshd[21734]: debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
Jul 09 12:51:10 Duke sshd[21734]: debug1: Bind to port 22 on ::.
Jul 09 12:51:10 Duke sshd[21734]: Server listening on :: port 22.
Jul 09 12:51:12 Duke systemd[1]: Stopping OpenSSH Daemon...
Jul 09 12:51:12 Duke systemd[1]: Stopped OpenSSH Daemon.
Jul 09 12:51:12 Duke sshd[21734]: Received signal 15; terminating.

Contents of /usr/lib/systemd/system/sshd.service:

[Unit]
Description=OpenSSH Daemon
After=network.target

[Service]
EnvironmentFile=-/etc/sysconfig/ssh
ExecStartPre=/usr/sbin/sshd-gen-keys-start
ExecStart=/usr/sbin/sshd -D -ddd $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=never

[Install]
WantedBy=multi-user.target

Note: I changed Restart to never from always so I could see the last messages from sshd. SSHD is terminated in both cases.

  • Try disabling selinux? – Nifle Jul 10 '17 at 14:10
  • Are you sure there isn't anything that literally runs systemctl stop sshd or otherwise asks systemd to stop that service? – grawity Jul 10 '17 at 14:35
  • @grawity not that I'm aware of. – BlooMeth Jul 10 '17 at 15:00
  • You could try checking if anything else is happening before the Stopping OpenSSH Daemon... by doing sudo journalctl -e. – xordspar0 Jul 10 '17 at 15:55
1

You added -ddd arguments to the sshd. Having a look into the manual page, where you find these arguments, you can notice the following:

-d

Debug mode. The server sends verbose debug output to standard error, and does not put itself in the background. The server also will not fork and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3.

So this does exactly what is expected.

If you wish to see the debug messages, use the LogLevel DEBUG3 option in sshd_config. It will not affect this behavior, but will log the messages.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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