lecture de /etc/ssh/sshd

Eric Masson

23/01/2021 à 17:49

Thomas writes:
'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

23/01/2021 à 18:37

In article ,
Eric Masson wrote:

Thomas writes:
'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

23/01/2021 à 19:14

Thomas writes:
'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é"

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:

'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é"

Vous avez filtré cet utilisateur ! Consultez son message

Christophe PEREZ

23/01/2021 à 20:23

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

23/01/2021 à 20:27

In article ,
Eric Masson wrote:

Thomas writes:
'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/

In article <fk5udh-hot2.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:

'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/

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
Eric Masson wrote:

Thomas writes:
'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

24/01/2021 à 13:09

Thomas wrote:

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

24/01/2021 à 13:11

Christophe PEREZ wrote:

# 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

24/01/2021 à 13:19

Marc SCHAEFER writes:
'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 <http://www.le-gnu.net> -+- Délit de sale liste -+-

Thomas

17/02/2021 à 00:25

In article <rujo25$dru$,
Marc SCHAEFER wrote:

Thomas wrote:
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/

lecture de /etc/ssh/sshd_config

9 réponses

lecture de /etc/ssh/sshd_config

9 réponses

Veuillez sélectionner un problème