J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser
l'utilisateur root se connecter en ssh alors que la directive
PermitRootLogin no
du sshd_config n'empêche pas une fois loggé en utilisateur normal de
passer en root avec la commande su. Je comprends bien que c'est plus
difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais
j'aurais voulu savoir s'il y a d'autres raisons.
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser l'utilisateur root se connecter en ssh alors que la directive PermitRootLogin no du sshd_config n'empêche pas une fois loggé en utilisateur normal de passer en root avec la commande su. Je comprends bien que c'est plus difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais j'aurais voulu savoir s'il y a d'autres raisons.
Merci.
parce que tu pourrais toujours être en train de te loguer sur une machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre man in the middle). Et ainsi lui transmettre le mot de passe de root. Si par contre tu dois te loguer avant sous un compte normal, c'est plus compliqué pour le pirate de mettre sa machine à la place de celle que tu vises pour récupérer ton pass root.
patpro
In article <MPG.1cc60be95dbaab9f989727@news.free.fr>,
NonSenZ <anthonyatnonsenzdotorg@xxx.com> wrote:
Bonjour à tous,
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser
l'utilisateur root se connecter en ssh alors que la directive
PermitRootLogin no
du sshd_config n'empêche pas une fois loggé en utilisateur normal de
passer en root avec la commande su. Je comprends bien que c'est plus
difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais
j'aurais voulu savoir s'il y a d'autres raisons.
Merci.
parce que tu pourrais toujours être en train de te loguer sur une
machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre
man in the middle). Et ainsi lui transmettre le mot de passe de root.
Si par contre tu dois te loguer avant sous un compte normal, c'est plus
compliqué pour le pirate de mettre sa machine à la place de celle que tu
vises pour récupérer ton pass root.
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser l'utilisateur root se connecter en ssh alors que la directive PermitRootLogin no du sshd_config n'empêche pas une fois loggé en utilisateur normal de passer en root avec la commande su. Je comprends bien que c'est plus difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais j'aurais voulu savoir s'il y a d'autres raisons.
Merci.
parce que tu pourrais toujours être en train de te loguer sur une machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre man in the middle). Et ainsi lui transmettre le mot de passe de root. Si par contre tu dois te loguer avant sous un compte normal, c'est plus compliqué pour le pirate de mettre sa machine à la place de celle que tu vises pour récupérer ton pass root.
patpro
Stephane Catteau
patpro ~ patrick proniewski nous disait récement dans fr.comp.securite <news: :
parce que tu pourrais toujours être en train de te loguer sur une machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre man in the middle). Et ainsi lui transmettre le mot de passe de root. [...]
Je suis sceptique là, puisque ton affirmation n'est valable que si sshd est configuré pour accepter l'authentification par le biais de login. Or, d'une part ce n'est en soit pas la plus sûre des configurations, mais en plus si je ne m'abuse, "PermitRootLogin no" t'empèchera aussi de te logger sous root même si la clé publique que tu utilises est valide pour ce compte.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
patpro ~ patrick proniewski nous disait récement dans
fr.comp.securite
<news:patpro-8B5C91.19111612042005@news2-e.proxad.net> :
parce que tu pourrais toujours être en train de te loguer sur une
machine qui n'est pas la bonne, mais celle d'un pirate (attaque du
genre man in the middle). Et ainsi lui transmettre le mot de passe
de root. [...]
Je suis sceptique là, puisque ton affirmation n'est valable que si
sshd est configuré pour accepter l'authentification par le biais de
login. Or, d'une part ce n'est en soit pas la plus sûre des
configurations, mais en plus si je ne m'abuse, "PermitRootLogin no"
t'empèchera aussi de te logger sous root même si la clé publique que tu
utilises est valide pour ce compte.
--
"En amour, on plaît plutôt par d'agréables défauts que par des qualités
essentielles ; les grandes vertus sont des pièces d'or, dont on fait
moins usage que de la monnaie"
Ninon de Lenclos
patpro ~ patrick proniewski nous disait récement dans fr.comp.securite <news: :
parce que tu pourrais toujours être en train de te loguer sur une machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre man in the middle). Et ainsi lui transmettre le mot de passe de root. [...]
Je suis sceptique là, puisque ton affirmation n'est valable que si sshd est configuré pour accepter l'authentification par le biais de login. Or, d'une part ce n'est en soit pas la plus sûre des configurations, mais en plus si je ne m'abuse, "PermitRootLogin no" t'empèchera aussi de te logger sous root même si la clé publique que tu utilises est valide pour ce compte.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
Nicolas George
patpro ~ patrick proniewski wrote in message :
parce que tu pourrais toujours être en train de te loguer sur une machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre man in the middle). Et ainsi lui transmettre le mot de passe de root.
Non, ça ne marche pas : dès lors que c'est une machine à laquelle on s'est déjà connecté au moins une fois, ou dont on a récupéré le fingerprint de manière fiable, on a ceci :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 32:bb:b7:77:97:fe:d3:68:4d:a2:38:82:73:02:52:12. Please contact your system administrator. Add correct host key in /home/cigaes/.ssh/known_hosts to get rid of this message. Offending key in /home/cigaes/.ssh/known_hosts:89 RSA host key for aimlin has changed and you have requested strict checking. Host key verification failed. zsh: exit 255 ssh -p 1234 aimlin
patpro ~ patrick proniewski wrote in message
<patpro-8B5C91.19111612042005@news2-e.proxad.net>:
parce que tu pourrais toujours être en train de te loguer sur une
machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre
man in the middle). Et ainsi lui transmettre le mot de passe de root.
Non, ça ne marche pas : dès lors que c'est une machine à laquelle on s'est
déjà connecté au moins une fois, ou dont on a récupéré le fingerprint de
manière fiable, on a ceci :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
32:bb:b7:77:97:fe:d3:68:4d:a2:38:82:73:02:52:12.
Please contact your system administrator.
Add correct host key in /home/cigaes/.ssh/known_hosts to get rid of this message.
Offending key in /home/cigaes/.ssh/known_hosts:89
RSA host key for aimlin has changed and you have requested strict checking.
Host key verification failed.
zsh: exit 255 ssh -p 1234 aimlin
parce que tu pourrais toujours être en train de te loguer sur une machine qui n'est pas la bonne, mais celle d'un pirate (attaque du genre man in the middle). Et ainsi lui transmettre le mot de passe de root.
Non, ça ne marche pas : dès lors que c'est une machine à laquelle on s'est déjà connecté au moins une fois, ou dont on a récupéré le fingerprint de manière fiable, on a ceci :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 32:bb:b7:77:97:fe:d3:68:4d:a2:38:82:73:02:52:12. Please contact your system administrator. Add correct host key in /home/cigaes/.ssh/known_hosts to get rid of this message. Offending key in /home/cigaes/.ssh/known_hosts:89 RSA host key for aimlin has changed and you have requested strict checking. Host key verification failed. zsh: exit 255 ssh -p 1234 aimlin
Laurent Blume
NonSenZ wrote:
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser l'utilisateur root se connecter en ssh alors que la directive PermitRootLogin no du sshd_config n'empêche pas une fois loggé en utilisateur normal de passer en root avec la commande su. Je comprends bien que c'est plus difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais j'aurais voulu savoir s'il y a d'autres raisons.
Pour moi, c'est essentiellement une raison de comptabilité et responsabilité, plutôt que de sécurité pure. Ie, on sait *qui* fait le su en root. Ce qui ne serait pas le cas avec une connexion directe, quand le compte root est partagé.
Ce qui semble confirmé par le man d'OpenSSH, qui indique que le défaut est d'autoriser ces connexions root directes:
PermitRootLogin Specifies whether root can log in using ssh(1). The argument must be ``yes'', ``without-password'', ``forced-commands-only'' or ``no''. The default is ``yes''.
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser
l'utilisateur root se connecter en ssh alors que la directive
PermitRootLogin no
du sshd_config n'empêche pas une fois loggé en utilisateur normal de
passer en root avec la commande su. Je comprends bien que c'est plus
difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais
j'aurais voulu savoir s'il y a d'autres raisons.
Pour moi, c'est essentiellement une raison de comptabilité et responsabilité,
plutôt que de sécurité pure. Ie, on sait *qui* fait le su en root. Ce qui ne
serait pas le cas avec une connexion directe, quand le compte root est partagé.
Ce qui semble confirmé par le man d'OpenSSH, qui indique que le défaut est
d'autoriser ces connexions root directes:
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument
must be ``yes'', ``without-password'', ``forced-commands-only''
or ``no''. The default is ``yes''.
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser l'utilisateur root se connecter en ssh alors que la directive PermitRootLogin no du sshd_config n'empêche pas une fois loggé en utilisateur normal de passer en root avec la commande su. Je comprends bien que c'est plus difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais j'aurais voulu savoir s'il y a d'autres raisons.
Pour moi, c'est essentiellement une raison de comptabilité et responsabilité, plutôt que de sécurité pure. Ie, on sait *qui* fait le su en root. Ce qui ne serait pas le cas avec une connexion directe, quand le compte root est partagé.
Ce qui semble confirmé par le man d'OpenSSH, qui indique que le défaut est d'autoriser ces connexions root directes:
PermitRootLogin Specifies whether root can log in using ssh(1). The argument must be ``yes'', ``without-password'', ``forced-commands-only'' or ``no''. The default is ``yes''.
Ie, on sait *qui* fait le su en root. Ce qui ne serait pas le cas avec une connexion directe, quand le compte root est partagé.
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes droits que root, tout comme on peut avoir plusieurs administrateurs sous Windows ?
-- ;-)
VANHULLEBUS Yvan
NonSenZ writes:
Bonjour à tous,
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser l'utilisateur root se connecter en ssh alors que la directive PermitRootLogin no du sshd_config n'empêche pas une fois loggé en utilisateur normal de passer en root avec la commande su. Je comprends bien que c'est plus difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais j'aurais voulu savoir s'il y a d'autres raisons.
D'abord parceque sur un systeme ters propre et tres bien configure, tu ne feras pas "su", mais "sudo commande".
Ensuite, et surtout, a mon avis, parceque root est un compte bien connu. Donc si un attaquant fait une tentative de "brute force", voire une tentative d'attaque par mots de passe faibles, il tentera probablement sur le compte root, qui se trouve etre un compte qui existe a priori partout ET qui est potentiellement un compte utilisable pour se loguer (alors que la plupart des autres comptes "connus" sont des comptes de demons, marques comme tels, et sous lesquels on ne pourra pas se loguer).
Apres, les autres reponses possibles donnees me laissent un peu sceptique, mais je ne demande qu'a etre convaincu par une explication technique....
A +
VANHU.
NonSenZ <anthonyatnonsenzdotorg@xxx.com> writes:
Bonjour à tous,
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser
l'utilisateur root se connecter en ssh alors que la directive
PermitRootLogin no
du sshd_config n'empêche pas une fois loggé en utilisateur normal de
passer en root avec la commande su. Je comprends bien que c'est plus
difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais
j'aurais voulu savoir s'il y a d'autres raisons.
D'abord parceque sur un systeme ters propre et tres bien configure, tu
ne feras pas "su", mais "sudo commande".
Ensuite, et surtout, a mon avis, parceque root est un compte bien
connu. Donc si un attaquant fait une tentative de "brute force", voire
une tentative d'attaque par mots de passe faibles, il tentera
probablement sur le compte root, qui se trouve etre un compte qui
existe a priori partout ET qui est potentiellement un compte
utilisable pour se loguer (alors que la plupart des autres comptes
"connus" sont des comptes de demons, marques comme tels, et sous
lesquels on ne pourra pas se loguer).
Apres, les autres reponses possibles donnees me laissent un peu
sceptique, mais je ne demande qu'a etre convaincu par une explication
technique....
J'aurais voulu savoir pourquoi il est fortement déconseillé de laisser l'utilisateur root se connecter en ssh alors que la directive PermitRootLogin no du sshd_config n'empêche pas une fois loggé en utilisateur normal de passer en root avec la commande su. Je comprends bien que c'est plus difficile d'obtenir les droits root puisqu'il faut 2 mots de passe, mais j'aurais voulu savoir s'il y a d'autres raisons.
D'abord parceque sur un systeme ters propre et tres bien configure, tu ne feras pas "su", mais "sudo commande".
Ensuite, et surtout, a mon avis, parceque root est un compte bien connu. Donc si un attaquant fait une tentative de "brute force", voire une tentative d'attaque par mots de passe faibles, il tentera probablement sur le compte root, qui se trouve etre un compte qui existe a priori partout ET qui est potentiellement un compte utilisable pour se loguer (alors que la plupart des autres comptes "connus" sont des comptes de demons, marques comme tels, et sous lesquels on ne pourra pas se loguer).
Apres, les autres reponses possibles donnees me laissent un peu sceptique, mais je ne demande qu'a etre convaincu par une explication technique....
A +
VANHU.
Jeremy JUST
On 12 Apr 2005 21:22:24 GMT Fabien LE LEZ wrote:
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes droits que root, tout comme on peut avoir plusieurs administrateurs sous Windows ?
Il me semble que tous les comptes d'id nul ont les droits de root.
-- Jérémy JUST
On 12 Apr 2005 21:22:24 GMT
Fabien LE LEZ <gramster@gramster.com> wrote:
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes
droits que root, tout comme on peut avoir plusieurs administrateurs
sous Windows ?
Il me semble que tous les comptes d'id nul ont les droits de root.
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes droits que root, tout comme on peut avoir plusieurs administrateurs sous Windows ?
Il me semble que tous les comptes d'id nul ont les droits de root.
-- Jérémy JUST
Vincent Bernat
OoO En ce milieu de nuit étoilée du mercredi 13 avril 2005, vers 03:23, Jeremy JUST disait:
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes droits que root, tout comme on peut avoir plusieurs administrateurs sous Windows ?
Il me semble que tous les comptes d'id nul ont les droits de root.
Je confirme. Toutefois, ce sera sans doute "root" qui apparaîtra à diverses occasions et non le nom du nouvel utilisateur, ce qui peut être hasardeux pour savoir qui a fait quoi. -- printk(KERN_WARNING "%s: Short circuit detected on the loben", dev->name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c
OoO En ce milieu de nuit étoilée du mercredi 13 avril 2005, vers
03:23, Jeremy JUST <jeremy_just@netcourrier.com> disait:
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes
droits que root, tout comme on peut avoir plusieurs administrateurs
sous Windows ?
Il me semble que tous les comptes d'id nul ont les droits de root.
Je confirme. Toutefois, ce sera sans doute "root" qui apparaîtra à
diverses occasions et non le nom du nouvel utilisateur, ce qui peut
être hasardeux pour savoir qui a fait quoi.
--
printk(KERN_WARNING "%s: Short circuit detected on the loben",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c
OoO En ce milieu de nuit étoilée du mercredi 13 avril 2005, vers 03:23, Jeremy JUST disait:
Au fait, y'a pas moyen d'avoir plusieurs comptes ayant les mêmes droits que root, tout comme on peut avoir plusieurs administrateurs sous Windows ?
Il me semble que tous les comptes d'id nul ont les droits de root.
Je confirme. Toutefois, ce sera sans doute "root" qui apparaîtra à diverses occasions et non le nom du nouvel utilisateur, ce qui peut être hasardeux pour savoir qui a fait quoi. -- printk(KERN_WARNING "%s: Short circuit detected on the loben", dev->name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c
NonSenZ
VANHULLEBUS Yvan disait...
D'abord parceque sur un systeme ters propre et tres bien configure, tu ne feras pas "su", mais "sudo commande". ---
Je n'ai pas dit que je le faisais mais qu'il était possible de le faire (sous entendu pour l'attaquant). Enfin on peut toujours renommer su et trouver des configs encore plus tordues mais bon, plus c'est tordu, moins c'est facile à mettre en place de manière systématique sur tous les serveurs de production, pour garantir une politique de sécurité homogène...
En revanche, votre remarque sur l'identifiant root trivial est plus convaincante. Cela revient à dire, comme je le supposais, qu'on cherche juste à compliquer l'attaque par force brute, et qu'il n'y aurait pas d'autre raison...
-- NSZ
VANHULLEBUS Yvan disait...
D'abord parceque sur un systeme ters propre et tres bien configure, tu
ne feras pas "su", mais "sudo commande".
---
Je n'ai pas dit que je le faisais mais qu'il était possible de le faire
(sous entendu pour l'attaquant). Enfin on peut toujours renommer su et
trouver des configs encore plus tordues mais bon, plus c'est tordu,
moins c'est facile à mettre en place de manière systématique sur tous
les serveurs de production, pour garantir une politique de sécurité
homogène...
En revanche, votre remarque sur l'identifiant root trivial est plus
convaincante. Cela revient à dire, comme je le supposais, qu'on cherche
juste à compliquer l'attaque par force brute, et qu'il n'y aurait pas
d'autre raison...
D'abord parceque sur un systeme ters propre et tres bien configure, tu ne feras pas "su", mais "sudo commande". ---
Je n'ai pas dit que je le faisais mais qu'il était possible de le faire (sous entendu pour l'attaquant). Enfin on peut toujours renommer su et trouver des configs encore plus tordues mais bon, plus c'est tordu, moins c'est facile à mettre en place de manière systématique sur tous les serveurs de production, pour garantir une politique de sécurité homogène...
En revanche, votre remarque sur l'identifiant root trivial est plus convaincante. Cela revient à dire, comme je le supposais, qu'on cherche juste à compliquer l'attaque par force brute, et qu'il n'y aurait pas d'autre raison...
-- NSZ
NonSenZ
Laurent Blume disait...
Pour moi, c'est essentiellement une raison de comptabilité et responsabilité, plutôt que de sécurité pure. Ie, on sait *qui* fait le su en root. Ce qui ne serait pas le cas avec une connexion directe, quand le compte root est partagé. ---
Donc si seul l'administrateur a accès à la machine (en local et à distance), ça n'a aucun intérêt. Ca se tient mais ça en fout un coup aux sacro-saintes règles de sécurité que j'ai pu lire sur le web et qui prétendent qu'il est absolument impératif de ne pas permettre de connexion root par ssh (sans argumentation cela va de soi) :-).
-- NSZ
Laurent Blume disait...
Pour moi, c'est essentiellement une raison de comptabilité et responsabilité,
plutôt que de sécurité pure. Ie, on sait *qui* fait le su en root. Ce qui ne
serait pas le cas avec une connexion directe, quand le compte root est partagé.
---
Donc si seul l'administrateur a accès à la machine (en local et à
distance), ça n'a aucun intérêt. Ca se tient mais ça en fout un coup aux
sacro-saintes règles de sécurité que j'ai pu lire sur le web et qui
prétendent qu'il est absolument impératif de ne pas permettre de
connexion root par ssh (sans argumentation cela va de soi) :-).
Pour moi, c'est essentiellement une raison de comptabilité et responsabilité, plutôt que de sécurité pure. Ie, on sait *qui* fait le su en root. Ce qui ne serait pas le cas avec une connexion directe, quand le compte root est partagé. ---
Donc si seul l'administrateur a accès à la machine (en local et à distance), ça n'a aucun intérêt. Ca se tient mais ça en fout un coup aux sacro-saintes règles de sécurité que j'ai pu lire sur le web et qui prétendent qu'il est absolument impératif de ne pas permettre de connexion root par ssh (sans argumentation cela va de soi) :-).
