Euh, non
PermitRootLogin yes
va permettre de se connecter en root directement (sinon faut passer par un autre user qui a des
droits sudo)
Euh, non
PermitRootLogin yes
va permettre de se connecter en root directement (sinon faut passer par un autre user qui a des
droits sudo)
Euh, non
PermitRootLogin yes
va permettre de se connecter en root directement (sinon faut passer par un autre user qui a des
droits sudo)
Par ex, pour autoriser seulement certaines commandes prédéfinies pour le user foo, dans
son ~/.ssh/authorized_keys on peut mettre
command="/path/to/shell-foo.sh" ...la clé...
Par ex, pour autoriser seulement certaines commandes prédéfinies pour le user foo, dans
son ~/.ssh/authorized_keys on peut mettre
command="/path/to/shell-foo.sh" ...la clé...
Par ex, pour autoriser seulement certaines commandes prédéfinies pour le user foo, dans
son ~/.ssh/authorized_keys on peut mettre
command="/path/to/shell-foo.sh" ...la clé...
Le 23/06/15 à 22:13, a écrit :
Je me suis un peu trompé, on peut ne pas mettre de mot de passe,
via le fichier "/etc/shadow", mais c'est prendre un risque...
Lequel ? :
Je parlais bien de ne pas mettre de mot de passe (option
--disabled-password de adduser), pas de mettre un mot de passe vide.
Ça interdit la connexion par mot de passe, je vois pas en quoi ça pou rrait
représenter un risque :
Pour désactiver la connexion par mot de passe c'est :
PasswordAuthentication no
Faut évidemment accepter les clés avec
PubkeyAuthentication yes
Le 23/06/15 à 22:13, andre_debian@numericable.fr a écrit :
Je me suis un peu trompé, on peut ne pas mettre de mot de passe,
via le fichier "/etc/shadow", mais c'est prendre un risque...
Lequel ? :
Je parlais bien de ne pas mettre de mot de passe (option
--disabled-password de adduser), pas de mettre un mot de passe vide.
Ça interdit la connexion par mot de passe, je vois pas en quoi ça pou rrait
représenter un risque :
Pour désactiver la connexion par mot de passe c'est :
PasswordAuthentication no
Faut évidemment accepter les clés avec
PubkeyAuthentication yes
Le 23/06/15 à 22:13, a écrit :
Je me suis un peu trompé, on peut ne pas mettre de mot de passe,
via le fichier "/etc/shadow", mais c'est prendre un risque...
Lequel ? :
Je parlais bien de ne pas mettre de mot de passe (option
--disabled-password de adduser), pas de mettre un mot de passe vide.
Ça interdit la connexion par mot de passe, je vois pas en quoi ça pou rrait
représenter un risque :
Pour désactiver la connexion par mot de passe c'est :
PasswordAuthentication no
Faut évidemment accepter les clés avec
PubkeyAuthentication yes
* Faire très attention * car en cas d'erreur plus de connexion via ssh ! ! !
Ce qui m'est arrivé hier, connexion ssh out.
Solution :
avoir une console KVM (type Idrac) sur son serveur, indispensable,
si le serveur est distant, sinon on est bon à se déplacer dans le data center,
(prévoir doudoune sibérienne, bonnet et oreillettes anti-bruit).
* Faire très attention * car en cas d'erreur plus de connexion via ssh ! ! !
Ce qui m'est arrivé hier, connexion ssh out.
Solution :
avoir une console KVM (type Idrac) sur son serveur, indispensable,
si le serveur est distant, sinon on est bon à se déplacer dans le data center,
(prévoir doudoune sibérienne, bonnet et oreillettes anti-bruit).
* Faire très attention * car en cas d'erreur plus de connexion via ssh ! ! !
Ce qui m'est arrivé hier, connexion ssh out.
Solution :
avoir une console KVM (type Idrac) sur son serveur, indispensable,
si le serveur est distant, sinon on est bon à se déplacer dans le data center,
(prévoir doudoune sibérienne, bonnet et oreillettes anti-bruit).
Le mercredi 24 juin 2015 à 12:23, a écrit :
> * Faire très attention * car en cas d'erreur plus de connexion via ss h !
> ! ! Ce qui m'est arrivé hier, connexion ssh out.
> Solution :
> avoir une console KVM (type Idrac) sur son serveur, indispensable,
> si le serveur est distant, sinon on est bon à se déplacer dans le d ata
> center, (prévoir doudoune sibérienne, bonnet et oreillettes anti-br uit).
Non, la bonne approche lorsqu'on modifie une configuration SSH c'est de
garder une session ouverte sur la machine.
On redémarre le serveur SSH (ce qui n'interrompt pas les connexions
actives), on teste dans un autre terminal si on arrive toujours à se
connecter et tant qu'on n'arrive pas à établir une nouvelle connexion on ne
ferme pas la session ouverte.
Sébastien
Le mercredi 24 juin 2015 à 12:23, andre_debian@numericable.fr a écrit :
> * Faire très attention * car en cas d'erreur plus de connexion via ss h !
> ! ! Ce qui m'est arrivé hier, connexion ssh out.
> Solution :
> avoir une console KVM (type Idrac) sur son serveur, indispensable,
> si le serveur est distant, sinon on est bon à se déplacer dans le d ata
> center, (prévoir doudoune sibérienne, bonnet et oreillettes anti-br uit).
Non, la bonne approche lorsqu'on modifie une configuration SSH c'est de
garder une session ouverte sur la machine.
On redémarre le serveur SSH (ce qui n'interrompt pas les connexions
actives), on teste dans un autre terminal si on arrive toujours à se
connecter et tant qu'on n'arrive pas à établir une nouvelle connexion on ne
ferme pas la session ouverte.
Sébastien
Le mercredi 24 juin 2015 à 12:23, a écrit :
> * Faire très attention * car en cas d'erreur plus de connexion via ss h !
> ! ! Ce qui m'est arrivé hier, connexion ssh out.
> Solution :
> avoir une console KVM (type Idrac) sur son serveur, indispensable,
> si le serveur est distant, sinon on est bon à se déplacer dans le d ata
> center, (prévoir doudoune sibérienne, bonnet et oreillettes anti-br uit).
Non, la bonne approche lorsqu'on modifie une configuration SSH c'est de
garder une session ouverte sur la machine.
On redémarre le serveur SSH (ce qui n'interrompt pas les connexions
actives), on teste dans un autre terminal si on arrive toujours à se
connecter et tant qu'on n'arrive pas à établir une nouvelle connexion on ne
ferme pas la session ouverte.
Sébastien
Humm, avec cette méthode, on joue quand même avec le feu.
En plus le "Non," en début de ta réponse est trop péremptoire.
On croit avoir une autre connexion SSH en cours mais on a oublié
qu'on l'a fermée.
Un bon artisan a toujours de bons outils afin de pouvoir remédier
à toutes situations.
Ne choisis pas le métier de chirurgien ! :-)
Humm, avec cette méthode, on joue quand même avec le feu.
En plus le "Non," en début de ta réponse est trop péremptoire.
On croit avoir une autre connexion SSH en cours mais on a oublié
qu'on l'a fermée.
Un bon artisan a toujours de bons outils afin de pouvoir remédier
à toutes situations.
Ne choisis pas le métier de chirurgien ! :-)
Humm, avec cette méthode, on joue quand même avec le feu.
En plus le "Non," en début de ta réponse est trop péremptoire.
On croit avoir une autre connexion SSH en cours mais on a oublié
qu'on l'a fermée.
Un bon artisan a toujours de bons outils afin de pouvoir remédier
à toutes situations.
Ne choisis pas le métier de chirurgien ! :-)
Le mercredi 24 juin 2015 à 12:59, a à ©crit :
> En plus le "Non," en début de ta réponse est trop péremp toire.
Je te l'accorde et j'espère que tu ne m'en tiendras pas rigueur :
> On croit avoir une autre connexion SSH en cours mais on a oublié
> qu'on l'a fermée.
> Un bon artisan a toujours de bons outils afin de pouvoir remédier
> Ã toutes situations.
Si on lit successivement tes deux phrases (qui d'ailleurs se succède nt), tu
conviendras qu'il ne s'agit pas là d'un problème d'outil mais b el et bien
d'utilisation incontrôlée de l'outil.
Ajouter des sécurités ça peut être utile, je suis ent ièrement d'accord,
mais éviter de faire des erreurs c'est toujours mieux. Ces erreurs, on ne
pourra de toute façon pas les anticiper avant d'y avoir étà © confronté
En général, plantage, galère, rétablissent, comprà ©hension de l'erreur etâ¦
on ne fait plus jamais cette erreur (ou alors il y a un problème). A jouter
des outils pour pouvoir rattraper une erreur qu'on a commise par le pass é
au cas où on la commettrait de nouveau est donc a-priori inutile. En
revanche, modifier sa façon de faire pour ne pas la commettre de nou veau,
ça paye :
On part en H.S. là . Je ne cherche pas à te faire désinstal ler ta carte DRAC
ou ton KVM, je te laisse maître des solutions que tu envisages pour
sécuriser ton environnement de travail. C'était simplement mon point de vue
et je le partage ;-) :
> Ne choisis pas le métier de chirurgien ! :-)
Un chirurgien redémarre rarement des services SSH :-) :
Le mercredi 24 juin 2015 à 12:59, andre_debian@numericable.fr a à ©crit :
> En plus le "Non," en début de ta réponse est trop péremp toire.
Je te l'accorde et j'espère que tu ne m'en tiendras pas rigueur :
> On croit avoir une autre connexion SSH en cours mais on a oublié
> qu'on l'a fermée.
> Un bon artisan a toujours de bons outils afin de pouvoir remédier
> Ã toutes situations.
Si on lit successivement tes deux phrases (qui d'ailleurs se succède nt), tu
conviendras qu'il ne s'agit pas là d'un problème d'outil mais b el et bien
d'utilisation incontrôlée de l'outil.
Ajouter des sécurités ça peut être utile, je suis ent ièrement d'accord,
mais éviter de faire des erreurs c'est toujours mieux. Ces erreurs, on ne
pourra de toute façon pas les anticiper avant d'y avoir étà © confronté
En général, plantage, galère, rétablissent, comprà ©hension de l'erreur etâ¦
on ne fait plus jamais cette erreur (ou alors il y a un problème). A jouter
des outils pour pouvoir rattraper une erreur qu'on a commise par le pass é
au cas où on la commettrait de nouveau est donc a-priori inutile. En
revanche, modifier sa façon de faire pour ne pas la commettre de nou veau,
ça paye :
On part en H.S. là . Je ne cherche pas à te faire désinstal ler ta carte DRAC
ou ton KVM, je te laisse maître des solutions que tu envisages pour
sécuriser ton environnement de travail. C'était simplement mon point de vue
et je le partage ;-) :
> Ne choisis pas le métier de chirurgien ! :-)
Un chirurgien redémarre rarement des services SSH :-) :
Le mercredi 24 juin 2015 à 12:59, a à ©crit :
> En plus le "Non," en début de ta réponse est trop péremp toire.
Je te l'accorde et j'espère que tu ne m'en tiendras pas rigueur :
> On croit avoir une autre connexion SSH en cours mais on a oublié
> qu'on l'a fermée.
> Un bon artisan a toujours de bons outils afin de pouvoir remédier
> Ã toutes situations.
Si on lit successivement tes deux phrases (qui d'ailleurs se succède nt), tu
conviendras qu'il ne s'agit pas là d'un problème d'outil mais b el et bien
d'utilisation incontrôlée de l'outil.
Ajouter des sécurités ça peut être utile, je suis ent ièrement d'accord,
mais éviter de faire des erreurs c'est toujours mieux. Ces erreurs, on ne
pourra de toute façon pas les anticiper avant d'y avoir étà © confronté
En général, plantage, galère, rétablissent, comprà ©hension de l'erreur etâ¦
on ne fait plus jamais cette erreur (ou alors il y a un problème). A jouter
des outils pour pouvoir rattraper une erreur qu'on a commise par le pass é
au cas où on la commettrait de nouveau est donc a-priori inutile. En
revanche, modifier sa façon de faire pour ne pas la commettre de nou veau,
ça paye :
On part en H.S. là . Je ne cherche pas à te faire désinstal ler ta carte DRAC
ou ton KVM, je te laisse maître des solutions que tu envisages pour
sécuriser ton environnement de travail. C'était simplement mon point de vue
et je le partage ;-) :
> Ne choisis pas le métier de chirurgien ! :-)
Un chirurgien redémarre rarement des services SSH :-) :