After rebooting my server, I got an email with this contents:
Subject: OpenSSH restart failed
Body: OpenSSH can not be restarted. Please check config:
But I can ssh into the server just fine (thankfully). I’m hesitant to restart it again, as I’m not sure what would have caused this error.
You would need to check your log files, example syslog. Currently you provided us to less informations for any other answer 
.
Will look into those for sure. Honestly, I was just relaying what was presented to me, and due to its lack of information, I wasn’t sure what to do with it.
I looked in syslog, auth.log, a bunch of logs in Hestia’s folder, but there was nothing that seemed related.
Is the issue reproducable? Does it occur on every restart?
Apparently it does.
One time, immediately after reboot, I ran service ssh status and got this in the log output:
I suppose it’s worth noting that I might have changed the sshd_config file prior to Hestia’s update. I typically make a couple changes to make it more secure (turning off password login/no root login/etc), but everything continues to work like normal. I just get this email that is concerning.
the error message you posted initially suggest that there is/was something off with your config, sadly you cut out the interesting part after please check config: …
could be as little as a typo or whatever 
I didn’t cut anything off. What’s quoted is literally everything in the email. (Which is why I’m so confused)
oh okay… still probably want to recheck your config. if it otherwise works if you restart it manually maybe it was a one off and you meanwhile fixed something without even noticing
It’s not one off, it occurs with every reboot.
While it only emails me when I restart the server, I am also able to restart the ssh service completely fine as well.
In the event someone can see something that’s potentially an issue, this is the config (edited for privacy/security):
# $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 1m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp internal-sftp
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
DebianBanner no
# Hestia SFTP Chroot
Match User __censored___
ChrootDirectory %h
X11Forwarding no
AllowTCPForwarding no
ForceCommand internal-sftp
okay I think I saw a similar mail somewhere too, but can’t remember when or which server.
what system/OS and version are you using?
anything special in your system config (like a seperate partition mounted for /home)?
are you using quotas?
PS: my guess would be that it could be related to the chrooting stuff. I don’t see anything off in your config (and usually change even more things in my ssh config as well)
It’s Ubuntu 18.04. No quotas (at least, I don’t believe I set up quotas… how would I check?) and no separate home partition. I think the biggest thing I might have done that wasn’t part of the basic Hestia install was to setup a swapfile. I may have made slight tweaks a couple other server configs, but I don’t believe so. Most of the things I would have changed in the server configs I ended up finding a way to do at the unprivileged user level inside their home folder configs, which again were quite minimal, if at all.
I had assumed the way forward would be to find where Hestia would have generated that message and work backward from that to find the potential causes for the message. Since I’m not super familiar with the code, I had figured someone on this forum might have a better idea. Is that not practical?
Found the quota toggle - it’s off.
I’m not recalling where to find chroot settings. Any hints?
that’s what I want to do, hence I asked for further infos about the system. will try to reproduce the issue. as said I noticed a similar mail, but can’t find it anymore, to figure if it’s identical and which of my servers to look at… who’s the sender of that mail? cron?
will run some tests anyway. I don’t think it’s critical at all, maybe a thing with the order of services getting started etc.
will also search through hestia scripts to see if I can isolate that message.
I hadn’t thought to check “who” sent it! It says “Hestia Control Panel” - can cron be made that pretty?
here’s the (scrubbed), unedited, raw email (empty newlines kept intact):
Return-path: <root@controlpanel.__redacted__.com>
Envelope-to: __redacted(me)__@ __redacted__.tld
Delivery-date: Sat, 21 Mar 2020 04:13:18 -0500
Received: from root by __redacted(serverFQDN)__.com with local (Exim 4.90_1)
(envelope-from <root@ __redacted(serverFQDN)__ >)
id 1jFaBy-0000Bi-Bl
for __redacted(me)__@ __redacted__.tld; Sat, 21 Mar 2020 04:13:18 -0500
To: < __redacted(me)__@ __redacted__.tld >
Subject: =?utf-8?B?T3BlblNTSCByZXN0YXJ0IGZhaWxlZAo=?=
X-PHP-Originating-Script: 0:main.php
From: Hestia Control Panel <hestia@__redacted(serverFQDN)__>
X-Priority: 3 (Normal)
CC:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Mailer: Php/libMailv1.3
Message-Id: <E1jFaBy-0000Bi-Bl@controlpanel. __redacted(serverFQDN)__>
Date: Sat, 21 Mar 2020 04:13:18 -0500
OpenSSH can not be restarted. Please check config:
And I’d do a search too, but I’m not sure where to find the scripts to search through. (thank you for your assistance by the way!)
I found the mails in one of my backups and figured which server. running debian buster with hestia 1.1 on it - though it was running the release candidate before and the mails are from three weeks ago and earlier.
also yes, I could reproduce the issue by simply rebooting that box. system is fully updated.
I’ll dig into and see what I can find.
For what it’s worth, I did not update Hestia until days/weeks after the 1.1 release, so I was at no point running a prerelease.
yeah, I doubt it has a connection, that’s probably just the reason why I got this already some time back. I also rebooted that box earlier today already because of a hunch and did not get a mail about openssh…
I guess that something is trying to restart openssh very early, maybe even before the network is properly started or so and that makes it sometimes fail or whatever.
As said above I don’t think it’s critical as systemd obviously takes care and ssh gets started anyway. will keep you posted
Sounds good. On my end, I realized I had some apt upgrades to do, so I’ll try that and see if any magic happens.