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 ?
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 ?
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 ?
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...
Thomas <fantome.forums.tDeContes@free.fr.invalid> 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...
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 :-)
mais dans ce cas, comment les connaitre ?
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
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ
dessus, et je fais de mon mieux :-)
mais dans ce cas, comment les connaitre ?
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
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ
dessus, et je fais de mon mieux :-)
mais dans ce cas, comment les connaitre ?
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
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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 ?
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 ?
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 service
Aucune entrée de manuel pour service
# service
-su: service : commande introuvable
# man service
Aucune entrée de manuel pour service
# service
-su: service : commande introuvable
# 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
service est encore disponible sur Debian stable, mais c'est une couche
d'émulation Í systemctl
service est encore disponible sur Debian stable, mais c'est une couche
d'émulation Í systemctl
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 ...
Thomas <fantome.forums.tDeContes@free.fr.invalid> 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 ...
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 ...