Debian SSHD Missing privilege separation directory: /run/sshd

Bonjour @DidierM,



Il s'agit d'un problème connu qui est lié à la façon dont systemd gérer les services et les répertoires de données temporaires.

Néanmoins, votre clé devrait se trouver dans un autre répertoire pour que votre serveur OpenSSH fonctionne sans problème. Pouvez-vous nous montrer la conf de /etc/ssh/sshd_config ?

Bien à vous.

Bonsoir @adion
Je me rends compte que j'ai un problème similaire en Ubuntu Server 22.04
C'est délirant... tous les SSHD fonctionnaient bien.
Maintenant, je change le port (j'ai changé le port dans FirewallD), je force la clé ed25519, je veux forcer le login par clé...
et ça foire !

Mais la clé ed25519, ce n'est pas neuf.
ça fait des mois que ça tourne. Donc c'est autre chose.

En Ubuntu 22.04, j'ai mm SSHD qui ne démarre plus au reboot !
Je suis en train de regarder ça.

Si je le démarre manuellement, il tourne et crée /run/sshd

Si je fais "service sshd start" , il démarre correctement !

dans le serveur Ubuntu 22.04, j'ai ça dans les logs


Jan 23 23:50:24 ct822-drupal systemd[1]: Started Munin Node.
Jan 23 23:50:24 ct822-drupal systemd[1]: Reached target Multi-User System.
Jan 23 23:50:24 ct822-drupal systemd[1]: Reached target Graphical Interface.
Jan 23 23:50:24 ct822-drupal systemd[1]: Starting Record Runlevel Change in UTMP...
Jan 23 23:50:24 ct822-drupal systemd[1]: systemd-update-utmp-runlevel.service: Deactivated successfully.
Jan 23 23:50:24 ct822-drupal systemd[1]: Finished Record Runlevel Change in UTMP.
Jan 23 23:50:24 ct822-drupal systemd[1]: Startup finished in 7.694s.
Jan 23 23:51:41 ct822-drupal systemd[1]: Created slice Slice /system/ssh.
Jan 23 23:51:41 ct822-drupal systemd[1]: Started OpenBSD Secure Shell server per-connection daemon (14.48.124.183:61404).
Jan 23 23:51:42 ct822-drupal systemd[1]: ssh@0-51.123.123.123:22-14.48.124.183:61404.service: Deactivated successfully.
Jan 23 23:52:01 ct822-drupal CRON[1127]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)

remarque que mon SSH n'est pas sur le port 22...

"Desactivated successfully" ?

----------------------

# systemctl status ssh
○ ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:sshd(8)
man:sshd_config(5)

Je ne vois pas pourquoi SSHD ne démarre pas.
Surtout que si je le démarre manuellement, il tourne.

J'ai certainement un problème de config

j'ai dans sshd "**Port 1234**"

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

# 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.

Include /etc/ssh/sshd_config.d/*.conf

Port 1234
#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
LogLevel VERBOSE

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
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)
KbdInteractiveAuthentication 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 KbdInteractiveAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication 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 KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /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 /usr/lib/openssh/sftp-server

#Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

# Subsystem sftp /usr/lib/ssh/sftp-server

# Subsystem sftp internal-sftp

Subsystem sftp /usr/lib/openssh/sftp-server -f AUTHPRIV -l INFO

GatewayPorts no
AllowTcpForwarding yes
LoginGraceTime 30
KeepAlive yes
Protocol 2

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server

Tout semble simple, et pourtant SSH ne démarre pas tout seul au reboot.

Vu que sshd ne démarre pas au reboot, je vérifie :

systemctl is-enabled ssh
**enabled**

Trop simple...

Bonjour,

question qui tue, mais est-ce que "/etc/ssh/ssh_host_ed25519_key" existe bien ?
Idem avec "/etc/ssh/ssh_host_ed25519_key.pub" ?

Perso un "sshd -t" sur le fichier de base à la fin d'une install de Debian ==> 0 erreur
Après perso je change pas de port, je force pas la clé en ed25519 et j'autorise root à se connecter avec une clé, et la VM est accessible seulement depuis un VPN au niveau de SSH.

Cordialement, janus57

Bonjour @janus57

question qui tue, mais est-ce que "/etc/ssh/ssh_host_ed25519_key" existe bien ?
Idem avec "/etc/ssh/ssh_host_ed25519_key.pub" ?

Je vais vérifier, mais quand le dossier /run/sshd existe et que j'ai redémarré sshd, oui je peux me connecter avec ma clé ed25519...

Bonjour,

après c'est qu'une hypothèse, je modifie jamais le port du SSH et je force pas non plus le "HostKey" et mes clés SSH sont déjà en ed25519 depuis quelques années (3/4).

Cordialement, janus57

je force pas non plus le "HostKey" et mes clés SSH sont déjà en ed25519 depuis quelques années (3/4).

ce n'est que la désactivation des clés autres que ed25519.
Et ça fonctionne.
Impossible de faire SSH si on n'a pas une clé ed25519.
Franchement ça limite bien le nombre d'essais SSH venant des 4 coins de la planète.

Ce n'est pas cela le problème.

Oui probablement le port 1234...
Mais c'est étonnant d'avoir la possibilité de changer ce port, sauf que quand on le change on a des problèmes après le reboot...

Bonjour,

ce n'est que la désactivation des clés autres que ed25519.
Et ça fonctionne.
Impossible de faire SSH si on n'a pas une clé ed25519.
Franchement ça limite bien le nombre d'essais SSH venant des 4 coins de la planète.

en théorie il faudrait surtout utiliser "PubkeyAcceptedKeyTypes"

Sinon le meilleur moyen c'est de ne pas exposer le port 22, soit en autorisant l'accès que depuis un VPN (toute les VM derrière un FW central), soit avec du "port knocking".

Cordialement, janus57

il faudrait surtout utiliser "PubkeyAcceptedKeyTypes"

Je vais vérifier ce paramètre...
et je dois creuser les VPN !
Je ne maîtrise pas, simplement car je n'ai jamais vraiment utiliser les VPN...
Bon WE

il faudrait surtout utiliser "PubkeyAcceptedKeyTypes"

PubkeyAcceptedKeyTypes ssh-ed25519

# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

C'est certainement plus propre comme cela : Uniquement les clés de type ed25519 sont autorisées !

- ça ne résout pas le SSH qui ne tourne pas après reboot, car pas de fichier /run/sshd
mais il y a des bypass.

Je dois malgré tout **tester les VPN**

un client VPN depuis un pc Ubuntu ou Debian ?
qui tournerait aussi sur Mac ? (je connais pas du tout-

une conf VPN ?
Merci.
Bon après-midi

Wireguard a la hipe en ce moment (justifié visiblement, @janus57 peut en dire plus je crois).
OpenVPN sinon.

Je dois tester **Wireguard**, mais il semble très simple
bien plus que OpenVPN, avec bcp moins de lignes de codes, càd plus facile à tenir à jour et à vérifier.

Le seul problème semble être que Wireguard est en UDP.

Si tu es dans une entreprise, une organisation etc, qui a un Proxy web... et bien l' UDP ne passera pas.
Alors que OpenVPN peut se configurer pour passer un proxy.