sshd Received SIGHUP restarting
 

Hi, I have:
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial

grep -n 'Received SIGHUP; restarting' /var/log/auth.log
... more "Received SIGHUP; restarting" logs every 5 minutes
70881:Nov 4 12:35:15 adr-desktop sshd[1498]: Received SIGHUP; restarting.
70977:Nov 4 12:40:17 adr-desktop sshd[1498]: Received SIGHUP; restarting.
71022:Nov 4 12:45:20 adr-desktop sshd[1498]: Received SIGHUP; restarting.
71075:Nov 4 12:50:22 adr-desktop sshd[1498]: Received SIGHUP; restarting.

From where sshd receives this SIGHUP or why this happens?

No idea as you haven't listed any potential causes? Like cron jobs or monitoring daemons?

strace -o myfile -p 1498 (the PID of sshd; may need to apt install strace)
control-c this *after* that SIGHUP happens.
grep si_pid myfile (it's on 2nd line, for me)
ps lww -p ... (that si_pid=#)
hopefully, the 'culprit' is still running.
Two other (but extremely complex) ways here

Hm, strange but last one I get it:
71651:Nov 4 16:27:12 adr-desktop sshd[1498]: Received SIGHUP; restarting.
after doing this every 5 minutes at least last 3 days.

It might be an attack of some sort?

I see lots of Firewall Violations with epylog but I'm pretty sure no one cracked my server because I only permit certificate based ssh logins.

No: SIGnals can only come from 'INside the house=system' (not over net AsFarAsIKnow).
So, either 'you' are 'doing' it, or it's time to ERASE that whole disk :cry:

Please note such advice should only be given after a proper audit of the victim machine.

Agreed! (I had a feeling I shouldn't have used that word 'erase', sorry)
I doubt that it's a break-in; probably some obscure config change that did this...
'What changed'[?] (restarting a daemon with SIGHUP is 'normal'=ok)

Glad we're on the same page.


I don't see any "obscure config" option in 'man sshd; man sshd_config;'? Generically speaking daemons tend to like reopen file descriptors or reload configs on 'kill -HUP;' but since the OP didn't dig my hint about checking cron jobs or monitoring daemons we might never know.

I take the erase part as a joke, don't worry :D

I don't think it's a cron job:
grep -nri ssh /etc/cron/*
crontab -l | grep ssh
sudo crontab -l | grep ssh
.. all show nothing ...
and I have no more users on my system.

Besides, I modified nothing related to cron and suddenly yesterday the problem stopped.

By 'obscure' I meant: most any change (probably using root), even an assumed-unrelated 'innocent' action... (once you find it, you'll go 'doh!' :doh: )
An idea: check /etc for any file changed Nov 4 16:27-16:33 (by like this or maybe -newermt)
Also, maybe 'practice' that strace, via manual: echo $$;kill -1 1498 (should be safe to try)

Best wishes! (I'm glad I didn't scare you [to the death of that disk :D ] ;) )

I agree with your rationale and let's suppose I changed something:
what could possibly be so to force sshd (only sshd!) to restart exactly every 5 minutes (+/- 1 ... 5 seconds).

Doesn't seems to me like an unrelated/small/innocent change here or there in a forgotten file ...

It seems worth doing that `find /etc` (or a simpler: (2spaces between Nov and the 4, so had to use 'Go Advanced' 'code' tags, grrrr)
I share your increduility (whoa, what a word for that emotion ;) ). I was disappointed it disappeared!
And also the concern of 'what did that?' (yes, computing is 'predictable', not 'irrational'!)

sudo ls -latrR /etc|grep 'Nov 4 16:[23]' -> 2 spaces
sudo ls -latrR /etc|grep 'Nov 4 16:[23]' -> 1 space
... both yield empty result (1 or 2 spaces between Nov and the 4) ...

That's a 'vote' for: nothing [under /etc anyway] was changed [at the time it stopped].
At least we 'took a shot at low hanging fruit'. But it leaves the mystery as 'deeper'.
So, I guess: just keep an 'eye on things'... Best wishes...

It started to do it again:
Nov 8 08:10:43 adr-desktop sshd[1566]: Received SIGHUP; restarting.
...
Nov 8 11:42:41 adr-desktop sshd[1566]: Received SIGHUP; restarting.

I restarted the NAS and it stopped.

sudo ls -latrR /etc|grep -P "Nov 8 \d\d:"
drwxr-xr-x 2 root root 4096 Nov 8 11:05 bash_completion.d
-rw-r--r-- 1 root root 516 Nov 8 11:46 g15daemon.conf
drwxr-xr-x 6 root root 4096 Nov 8 11:48 vmware
drwxr-xr-x 2 root root 4096 Nov 8 11:05 completions
drwxr-xr-x 2 root root 4096 Nov 8 11:05 .
-rw-r--r-- 1 root root 1645 Nov 8 11:47 ISO-8859-15.acm
-rw-r----- 1 root root 2878 Nov 8 11:48 user.rules
-rw-r----- 1 root root 533 Nov 8 11:48 user6.rules
-rw-r--r-- 1 root root 41 Nov 8 11:42 resolv.conf
-rw-rw-r-- 1 root root 1750 Nov 8 11:51 couchpotato.service
drwxr-xr-x 2 root root 4096 Nov 8 11:05 .
-rw-r----- 1 root root 33 Nov 8 11:46 usbarb.rules
-rw-r--r-- 1 root root 920 Nov 8 11:47 config
drwxr-xr-x 6 root root 4096 Nov 8 11:48 .
drwxr-xr-x 2 root root 4096 Nov 8 11:48 dhcpd
drwxr-xr-x 6 root root 4096 Nov 8 11:48 ..
-rw-r--r-- 1 root root 417 Nov 8 11:48 dhcpd.leases
drwxr-xr-x 2 root root 4096 Nov 8 11:48 .
-rw-r--r-- 1 root root 18 Nov 8 11:48 nat.mac
drwxr-xr-x 2 root root 4096 Nov 8 11:48 dhcpd
drwxr-xr-x 6 root root 4096 Nov 8 11:48 ..
-rw-r--r-- 1 root root 1851 Nov 8 11:48 dhcpd.leases
drwxr-xr-x 2 root root 4096 Nov 8 11:48 .
drwxr-xr-x 6 root root 4096 Nov 8 11:48 ..
drwxr-xr-x 6 root root 4096 Nov 8 11:48 ..

I found nothing helpful ...