lecture de /etc/ssh/sshd_config

Le
Thomas
bonjour :-)


j'ai failli me faire avoir parce que je ne comprenais pas pourquoi mon
serveur continuais d'accepter les mdp,
en fait ça a été résolu avec un redémarrage


dans mes souvenirs, la config était relue Í  chaque nouvelle connexion,

est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit
relue, ou est ce qu'il suffit d'attendre un certain délai ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Eric Masson
Le #26566055
Thomas 'Lut,
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle
soit relue, ou est ce qu'il suffit d'attendre un certain délai ?

man sshd
/signal
sshd can be configured using command-line options or a
configuration file (by default sshd_config(5)); command-line
options override values specified in the configuration file. sshd
rereads its configuration file when it receives a hangup signal,
SIGHUP, by executing itself with the name and options it was
started with, e.g. /usr/sbin/sshd.
Bref, man est ton ami...
--
CQ> Pourquoi chercher des ténors derrière les barreaux,
CQ> ils ont été libérés, non ? Mais que fait la DDT ?
Le DDT, c'est pour éradiquer les moustiques, pas les ténors.
-+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
Thomas
Le #26566062
In article Eric Masson
Thomas 'Lut,
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle
soit relue, ou est ce qu'il suffit d'attendre un certain délai ?

man sshd
/signal
sshd can be configured using command-line options or a
configuration file (by default sshd_config(5)); command-line
options override values specified in the configuration file. sshd
rereads its configuration file when it receives a hangup signal,
SIGHUP, by executing itself with the name and options it was
started with, e.g. /usr/sbin/sshd.
Bref, man est ton ami...

͠ condition de savoir o͹ chercher : je ne suis pas encore au point l͠
dessus, et je fais de mon mieux :-)
$ /usr/sbin/sshd
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key
alors
- il accepte d'être lancé sans être root, ouf !
- je suppose que le pb est que je ne lui au pas donné exactement les
mêmes options qu'au démarrage,
mais dans ce cas, comment les connaitre ?
j'ai fait
cat /etc/init.d/ssh
mais je n'arrive pas Í  le déchiffrer :
y a t il un moyen de les retrouver simplement, qui nous garantisse de ne
pas faire d'erreur ?

parallèlement Í  ça, j'aimerais comprendre pourquoi sshd ne relis pas la
config Í  chaque nouvelle connexion,
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
il me semble que ça n'est pas très couteux, de juste vérifier la date de
modification d'un fichier
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Eric Masson
Le #26566064
Thomas 'Re,
͠ condition de savoir o͹ chercher : je ne suis pas encore au point l͠
dessus, et je fais de mon mieux :-)

Ça s'apprend, man ${nom_commande} est un bon point de départ.
La manpage explique qu'envoyer le signal HUP Í  sshd provoque son redémarrage
avec les arguments utilisés pour son lancement.
man signal donne quelques infos sur ce qu'est un signal (étonnant, non
?) et la section see also donne d'autres références de pages man, parmi
lesquelles kill
En cas de doute une recherche complémentaire sur signal, kill via un
moteur de recherche donne des éléments complémentaires.
Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par
la page man initiale.
mais dans ce cas, comment les connaitre ?

Dépend de la distribution utilisée, se renseigner sur le système d'init
de celle que l'on utilise est un bon début.
La commande service est sjmsb présente, quel que soit le système d'init
utilisé, donc Í  nouveau man service donnera des infos intéressantes.
Dans le cas présent, sudo service sshd restart force le redémarrage de
sshd en lui passant les arguments requis.
parallèlement Í  ça, j'aimerais comprendre pourquoi sshd ne relis pas
la config Í  chaque nouvelle connexion

Parce que ses développeurs considèrent probablement que cela n'a pas
d'intérêt.
alors que, si je me souviens bien, c'est qqch qu'il faisait avant

Non.
il me semble que ça n'est pas très couteux, de juste vérifier la date de
modification d'un fichier

Il te semble mal. sshd est un programme complexe dont la sécurité doit
être maximale, insérer du code pour forcer la relecture d'un fichier de
configuration et donc augmenter la surface d'attaque n'est pas l'idée du
siècle.
--
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort

Il m'arrive de toucher, mais dans ces moments la, je pense pas trop a
linux.
-+- ST in Guide du linuxien pervers : "Linux c'est une affaire de doigté"
Christophe PEREZ
Le #26566068
Le Sat, 23 Jan 2021 19:14:06 +0100, Eric Masson a écrit :
La commande service est sjmsb présente, quel que soit le système d'init
utilisé, donc Í  nouveau man service donnera des infos intéressantes.

Je lis tout ça un peu en diagonale, mais lÍ  j'avoue que je suis resté
perplexe.
# man service
Aucune entrée de manuel pour service
# service
-su: service : commande introuvable
Thomas
Le #26566067
In article Eric Masson
Thomas 'Re,
͠ condition de savoir o͹ chercher : je ne suis pas encore au point l͠
dessus, et je fais de mon mieux :-)

Ça s'apprend, man ${nom_commande} est un bon point de départ.

on me l'a déjÍ  dit, mais c'est pas tjr suffisant
(je n'ai pas la même expérience que toi pour savoir o͹ et comment
chercher, comprendre ce que je lis, etc ...)
La manpage explique qu'envoyer le signal HUP Í  sshd provoque son redémarrage
avec les arguments utilisés pour son lancement.

ah désolé, j'avais compris de travers,
je croyais que "executing itself with the name and options it was
started with" représentait un moyen d'envoyer le "hangup signal" au sshd
original,
d'o͹ une question inutile Í  la suite, désolé
Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par
la page man initiale.
Dans le cas présent, sudo service sshd restart force le redémarrage de
sshd en lui passant les arguments requis.

merci bcp de me donner les commandes toutes prêtes, ça pourrais servir
un jour ou l'autre (ou Í  d'autres ?) :-)
mais je pense que je ne vais pas aller jusque lÍ  pour l'instant :
mon métier c'est le développement, pas l'administration, et je souhaite
autant que possible en rester Í  une utilisation suffisamment simple
parallèlement Í  ça, j'aimerais comprendre pourquoi sshd ne relis pas
la config Í  chaque nouvelle connexion

Parce que ses développeurs considèrent probablement que cela n'a pas
d'intérêt.

il me semble que quand /etc/ssh/sshd_config est modifié, il n'y a pas de
cas o͹ on souhaiterais que sshd reste avec l'ancienne config un certain
temps
c'est différent, l'absence d'utilité et le pb de sécurité
alors que, si je me souviens bien, c'est qqch qu'il faisait avant

Non.

ok, alors je confond peut être avec la config par utilisateur
il me semble que ça n'est pas très couteux, de juste vérifier la date de
modification d'un fichier


(je pensais surtout au cout en ressources pour un serveur tres sollicité)
Il te semble mal. sshd est un programme complexe dont la sécurité doit
être maximale, insérer du code pour forcer la relecture d'un fichier de
configuration et donc augmenter la surface d'attaque n'est pas l'idée du
siècle.

dis moi si je dis une bêtise,
il me semble que
- si un pirate arrive Í  faire fonctionner sudo, il a les moyens de
redémarrer sshd de toutes les manières possibles,
- si non, il n'existe aucune possibilité pour lui de modifier
/etc/ssh/sshd_config
donc, quel genre de faille pourrais se glisser entre les 2 ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Marc SCHAEFER
Le #26566098
Thomas
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit
relue, ou est ce qu'il suffit d'attendre un certain délai ?

systemctl reload ssh # recommandé
et ne pas oublier que dans le monde systemctl, certains fichiers dans
/etc/default ne sont relus qu'avec un systemctl daemon-reload ou
approchant ...
Marc SCHAEFER
Le #26566096
Christophe PEREZ
# man service
Aucune entrée de manuel pour service
# service
-su: service : commande introuvable

service est encore disponible sur Debian stable, mais c'est une couche
d'émulation Í  systemctl
Eric Masson
Le #26566100
Marc SCHAEFER 'Lut Marc,
service est encore disponible sur Debian stable, mais c'est une couche
d'émulation Í  systemctl

Les quelques machines linux que j'utilise sont effectivement des Debian
et service est juste une couche de compatibilité systemctl, nous sommes
d'accord.
--
Tout neuneu que je suis en usenautique, je me permets de signaler aux
décideurs qu'ils sont en infraction. J'ai entendu parler de black lists
Sont-elles déclarées Í  la CNIL? Probablement pas. C'est un délit!
-+- Simon in
Thomas
Le #26568033
In article Marc SCHAEFER
Thomas
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit
relue, ou est ce qu'il suffit d'attendre un certain délai ?

systemctl reload ssh # recommandé
et ne pas oublier que dans le monde systemctl, certains fichiers dans
/etc/default ne sont relus qu'avec un systemctl daemon-reload ou
approchant ...

merci :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Poster une réponse
Anonyme