>Bon, on peut tout de même réduire la visibilité du mot de passe (d ans
>l'historique des commandes ou dans le PS) en l'envoyant déjà hashé à
>chpasswd.
>Il suffit de générer ce hash avec la commande :
>mkpasswd -m SHA-512
>puis de passer ce résultat à chpasswd en précisant l'option "-e". On
>aurait alors quelque chose de ce genre :
> pass=$(mkpasswd -m SHA-512)
> echo "root:$pass" | ssh chpasswd -e
>
>Pour que cela apporte quelque chose, il FAUT exécuter au moins une
>fois mkpasswd en mode interactif mais le résultat peut ensuite être
>réutilisé X fois.
Merci pour ta réponse.
Ce qui m'afflige, c'est que je pensais que le flux SSH d'une machine à
l'autre
etait crypté. Je ne savais pas qu'on pouvait lire les mdp ou autre
commande rien
qu'en analysant les trames (comme à l'époque du bon vieux POP3 qu'on
sniffait
pour chopper les dit mots de passe des boites)
Comment peut-on faire ça et comment ?
Si certains en parle c'est que ça doit etre réalisable et qu'ils ont déjà
essayé ? non ? ou c'est pure supputassion ?
--
Nahliel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive:
http://lists.debian.org/
>Bon, on peut tout de même réduire la visibilité du mot de passe (d ans
>l'historique des commandes ou dans le PS) en l'envoyant déjà hashé à
>chpasswd.
>Il suffit de générer ce hash avec la commande :
>mkpasswd -m SHA-512
>puis de passer ce résultat à chpasswd en précisant l'option "-e". On
>aurait alors quelque chose de ce genre :
> pass=$(mkpasswd -m SHA-512)
> echo "root:$pass" | ssh root@machine chpasswd -e
>
>Pour que cela apporte quelque chose, il FAUT exécuter au moins une
>fois mkpasswd en mode interactif mais le résultat peut ensuite être
>réutilisé X fois.
Merci pour ta réponse.
Ce qui m'afflige, c'est que je pensais que le flux SSH d'une machine à
l'autre
etait crypté. Je ne savais pas qu'on pouvait lire les mdp ou autre
commande rien
qu'en analysant les trames (comme à l'époque du bon vieux POP3 qu'on
sniffait
pour chopper les dit mots de passe des boites)
Comment peut-on faire ça et comment ?
Si certains en parle c'est que ça doit etre réalisable et qu'ils ont déjà
essayé ? non ? ou c'est pure supputassion ?
--
Nahliel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive:
http://lists.debian.org/20130607135609.GB10519@debianserver.info-cr.fr
>Bon, on peut tout de même réduire la visibilité du mot de passe (d ans
>l'historique des commandes ou dans le PS) en l'envoyant déjà hashé à
>chpasswd.
>Il suffit de générer ce hash avec la commande :
>mkpasswd -m SHA-512
>puis de passer ce résultat à chpasswd en précisant l'option "-e". On
>aurait alors quelque chose de ce genre :
> pass=$(mkpasswd -m SHA-512)
> echo "root:$pass" | ssh chpasswd -e
>
>Pour que cela apporte quelque chose, il FAUT exécuter au moins une
>fois mkpasswd en mode interactif mais le résultat peut ensuite être
>réutilisé X fois.
Merci pour ta réponse.
Ce qui m'afflige, c'est que je pensais que le flux SSH d'une machine à
l'autre
etait crypté. Je ne savais pas qu'on pouvait lire les mdp ou autre
commande rien
qu'en analysant les trames (comme à l'époque du bon vieux POP3 qu'on
sniffait
pour chopper les dit mots de passe des boites)
Comment peut-on faire ça et comment ?
Si certains en parle c'est que ça doit etre réalisable et qu'ils ont déjà
essayé ? non ? ou c'est pure supputassion ?
--
Nahliel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive:
http://lists.debian.org/
Tu n'oublieras pas de nous faire signe quand tes machines auront été piratées…
tu as une autre solution constructive ? Histoire d'apprendre des choses quoi !
Certains au moins essai de trouver et m'apporter des solutions en ce sens et je les en
remercie.
Tu n'oublieras pas de nous faire signe quand tes machines auront été piratées…
tu as une autre solution constructive ? Histoire d'apprendre des choses quoi !
Certains au moins essai de trouver et m'apporter des solutions en ce sens et je les en
remercie.
Tu n'oublieras pas de nous faire signe quand tes machines auront été piratées…
tu as une autre solution constructive ? Histoire d'apprendre des choses quoi !
Certains au moins essai de trouver et m'apporter des solutions en ce sens et je les en
remercie.
>Tu n'oublieras pas de nous faire signe quand tes machines auront été piratées…
>
tu as une autre solution constructive ? Histoire d'apprendre des choses quoi !
Certains au moins essai de trouver et m'apporter des solutions en ce sens et je les en
remercie.
>Tu n'oublieras pas de nous faire signe quand tes machines auront été piratées…
>
tu as une autre solution constructive ? Histoire d'apprendre des choses quoi !
Certains au moins essai de trouver et m'apporter des solutions en ce sens et je les en
remercie.
>Tu n'oublieras pas de nous faire signe quand tes machines auront été piratées…
>
tu as une autre solution constructive ? Histoire d'apprendre des choses quoi !
Certains au moins essai de trouver et m'apporter des solutions en ce sens et je les en
remercie.
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh
que les informations passe en crypter (on passe par un tunnel crypté).
Sinon c'est vrai qu'on nous conseil toujours de se connecter avec un
compte sans priviléges (ou avec des privileges reduits) puis de
tourner sur le compte root avec la commande su. C'est pour cela qu'on
utilise dans quelques cas des clés asymétriques (rsa, dsa, etc...)
pour les connexions
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh
que les informations passe en crypter (on passe par un tunnel crypté).
Sinon c'est vrai qu'on nous conseil toujours de se connecter avec un
compte sans priviléges (ou avec des privileges reduits) puis de
tourner sur le compte root avec la commande su. C'est pour cela qu'on
utilise dans quelques cas des clés asymétriques (rsa, dsa, etc...)
pour les connexions
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh
que les informations passe en crypter (on passe par un tunnel crypté).
Sinon c'est vrai qu'on nous conseil toujours de se connecter avec un
compte sans priviléges (ou avec des privileges reduits) puis de
tourner sur le compte root avec la commande su. C'est pour cela qu'on
utilise dans quelques cas des clés asymétriques (rsa, dsa, etc...)
pour les connexions
Bon, on peut tout de même réduire la visibilité du mot de passe (dans
l'historique des commandes ou dans le PS) en l'envoyant déjà hashé à
chpasswd.
Il suffit de générer ce hash avec la commande :
mkpasswd -m SHA-512
puis de passer ce résultat à chpasswd en précisant l'option "-e". On
aurait alors quelque chose de ce genre :
pass=$(mkpasswd -m SHA-512)
echo "root:$pass" | ssh chpasswd -e
Pour que cela apporte quelque chose, il FAUT exécuter au moins une
fois mkpasswd en mode interactif mais le résultat peut ensuite être
réutilisé X fois.
Merci pour ta réponse.
Ce qui m'afflige, c'est que je pensais que le flux SSH d'une machine à l'autre
etait crypté. Je ne savais pas qu'on pouvait lire les mdp ou autre commande rien
qu'en analysant les trames (comme à l'époque du bon vieux POP3 qu'on sniffait
pour chopper les dit mots de passe des boites)
Comment peut-on faire ça et comment ?
Si certains en parle c'est que ça doit etre réalisable et qu'ils ont déjà
essayé ? non ? ou c'est pure supputassion ?
Bon, on peut tout de même réduire la visibilité du mot de passe (dans
l'historique des commandes ou dans le PS) en l'envoyant déjà hashé à
chpasswd.
Il suffit de générer ce hash avec la commande :
mkpasswd -m SHA-512
puis de passer ce résultat à chpasswd en précisant l'option "-e". On
aurait alors quelque chose de ce genre :
pass=$(mkpasswd -m SHA-512)
echo "root:$pass" | ssh root@machine chpasswd -e
Pour que cela apporte quelque chose, il FAUT exécuter au moins une
fois mkpasswd en mode interactif mais le résultat peut ensuite être
réutilisé X fois.
Merci pour ta réponse.
Ce qui m'afflige, c'est que je pensais que le flux SSH d'une machine à l'autre
etait crypté. Je ne savais pas qu'on pouvait lire les mdp ou autre commande rien
qu'en analysant les trames (comme à l'époque du bon vieux POP3 qu'on sniffait
pour chopper les dit mots de passe des boites)
Comment peut-on faire ça et comment ?
Si certains en parle c'est que ça doit etre réalisable et qu'ils ont déjà
essayé ? non ? ou c'est pure supputassion ?
Bon, on peut tout de même réduire la visibilité du mot de passe (dans
l'historique des commandes ou dans le PS) en l'envoyant déjà hashé à
chpasswd.
Il suffit de générer ce hash avec la commande :
mkpasswd -m SHA-512
puis de passer ce résultat à chpasswd en précisant l'option "-e". On
aurait alors quelque chose de ce genre :
pass=$(mkpasswd -m SHA-512)
echo "root:$pass" | ssh chpasswd -e
Pour que cela apporte quelque chose, il FAUT exécuter au moins une
fois mkpasswd en mode interactif mais le résultat peut ensuite être
réutilisé X fois.
Merci pour ta réponse.
Ce qui m'afflige, c'est que je pensais que le flux SSH d'une machine à l'autre
etait crypté. Je ne savais pas qu'on pouvait lire les mdp ou autre commande rien
qu'en analysant les trames (comme à l'époque du bon vieux POP3 qu'on sniffait
pour chopper les dit mots de passe des boites)
Comment peut-on faire ça et comment ?
Si certains en parle c'est que ça doit etre réalisable et qu'ils ont déjà
essayé ? non ? ou c'est pure supputassion ?
C'est comme ça qu'on fait sur nos
cluster. on a plussieurs dizaines de machines identiques. on modifie
le /etc/shadow sur une avec passwd et ensuite la modification est
répercutée sur toutes les autres avec un programme qui copie en
parallèle (voir pdsh).
C'est comme ça qu'on fait sur nos
cluster. on a plussieurs dizaines de machines identiques. on modifie
le /etc/shadow sur une avec passwd et ensuite la modification est
répercutée sur toutes les autres avec un programme qui copie en
parallèle (voir pdsh).
C'est comme ça qu'on fait sur nos
cluster. on a plussieurs dizaines de machines identiques. on modifie
le /etc/shadow sur une avec passwd et ensuite la modification est
répercutée sur toutes les autres avec un programme qui copie en
parallèle (voir pdsh).
Si tu es le seul utilisateur de la machine à partir de laquelle tu
vas changer les mots de passe sur tes serveurs, je pense que le
risque est plutôt faible et que certains utilisateurs de cette ML ont
peut-être un peu exagéré le danger de ce que tu faisais ;-)
j'avoue que je conserve un accès SSH root sur mes serveurs - en
entreprise, ce n'est généralement plus le cas).
J'espère ne pas avoir été trop bavard.
Si tu es le seul utilisateur de la machine à partir de laquelle tu
vas changer les mots de passe sur tes serveurs, je pense que le
risque est plutôt faible et que certains utilisateurs de cette ML ont
peut-être un peu exagéré le danger de ce que tu faisais ;-)
j'avoue que je conserve un accès SSH root sur mes serveurs - en
entreprise, ce n'est généralement plus le cas).
J'espère ne pas avoir été trop bavard.
Si tu es le seul utilisateur de la machine à partir de laquelle tu
vas changer les mots de passe sur tes serveurs, je pense que le
risque est plutôt faible et que certains utilisateurs de cette ML ont
peut-être un peu exagéré le danger de ce que tu faisais ;-)
j'avoue que je conserve un accès SSH root sur mes serveurs - en
entreprise, ce n'est généralement plus le cas).
J'espère ne pas avoir été trop bavard.
Belaïd MOUNSI a écrit :
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh qu e
les informations passe en crypter (on passe par un tunnel crypté). Sin on
c'est vrai qu'on nous conseil toujours de se connecter avec un compte sa ns
priviléges (ou avec des privileges reduits) puis de tourner sur le com pte
root avec la commande su. C'est pour cela qu'on utilise dans quelques ca s
des clés asymétriques (rsa, dsa, etc...) pour les connexions
Euh, c'est une blague ?
Si c'est ca, SSH perd tout son intérêt par rapport à telnet (pour n e citer
que lui ... ).
De ce qu'il me semble, la première étape d'une connexion SSH , c'est des
échanges de clés, avant même de demander un mot de passe ...
C'est d'ailleurs stocké dans un fichier known_hosts côté client , e t est
vérifié à chaque connexion, pour être sur qu'on s'adresse bien à la bonne
machine. (protection contre les "man in the middle").
On m'aurait menti ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/**FrenchLists<http://wiki.debian.org/fr/FrenchL ists>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@**lists.debian.org<debian-user-french-REQ
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/**<http://li sts.debian.org/
Belaïd MOUNSI a écrit :
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh qu e
les informations passe en crypter (on passe par un tunnel crypté). Sin on
c'est vrai qu'on nous conseil toujours de se connecter avec un compte sa ns
priviléges (ou avec des privileges reduits) puis de tourner sur le com pte
root avec la commande su. C'est pour cela qu'on utilise dans quelques ca s
des clés asymétriques (rsa, dsa, etc...) pour les connexions
Euh, c'est une blague ?
Si c'est ca, SSH perd tout son intérêt par rapport à telnet (pour n e citer
que lui ... ).
De ce qu'il me semble, la première étape d'une connexion SSH , c'est des
échanges de clés, avant même de demander un mot de passe ...
C'est d'ailleurs stocké dans un fichier known_hosts côté client , e t est
vérifié à chaque connexion, pour être sur qu'on s'adresse bien à la bonne
machine. (protection contre les "man in the middle").
On m'aurait menti ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/**FrenchLists<http://wiki.debian.org/fr/FrenchL ists>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@**lists.debian.org<debian-user-french-REQ UEST@lists.debian.org>
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/**51B1EDC0.6010405@stuxnet.org<http://li sts.debian.org/51B1EDC0.6010405@stuxnet.org>
Belaïd MOUNSI a écrit :
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh qu e
les informations passe en crypter (on passe par un tunnel crypté). Sin on
c'est vrai qu'on nous conseil toujours de se connecter avec un compte sa ns
priviléges (ou avec des privileges reduits) puis de tourner sur le com pte
root avec la commande su. C'est pour cela qu'on utilise dans quelques ca s
des clés asymétriques (rsa, dsa, etc...) pour les connexions
Euh, c'est une blague ?
Si c'est ca, SSH perd tout son intérêt par rapport à telnet (pour n e citer
que lui ... ).
De ce qu'il me semble, la première étape d'une connexion SSH , c'est des
échanges de clés, avant même de demander un mot de passe ...
C'est d'ailleurs stocké dans un fichier known_hosts côté client , e t est
vérifié à chaque connexion, pour être sur qu'on s'adresse bien à la bonne
machine. (protection contre les "man in the middle").
On m'aurait menti ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/**FrenchLists<http://wiki.debian.org/fr/FrenchL ists>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@**lists.debian.org<debian-user-french-REQ
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/**<http://li sts.debian.org/
Belaïd MOUNSI a écrit :
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh qu e
les informations passe en crypter (on passe par un tunnel crypté). Sin on
c'est vrai qu'on nous conseil toujours de se connecter avec un compte sa ns
priviléges (ou avec des privileges reduits) puis de tourner sur le com pte
root avec la commande su. C'est pour cela qu'on utilise dans quelques ca s
des clés asymétriques (rsa, dsa, etc...) pour les connexions
Euh, c'est une blague ?
Si c'est ca, SSH perd tout son intérêt par rapport à telnet (pour n e citer
que lui ... ).
De ce qu'il me semble, la première étape d'une connexion SSH , c'est des
échanges de clés, avant même de demander un mot de passe ...
C'est d'ailleurs stocké dans un fichier known_hosts côté client , e t est
vérifié à chaque connexion, pour être sur qu'on s'adresse bien à la bonne
machine. (protection contre les "man in the middle").
On m'aurait menti ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/**FrenchLists<http://wiki.debian.org/fr/FrenchL ists>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@**lists.debian.org<debian-user-french-REQ
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/**<http://li sts.debian.org/
Belaïd MOUNSI a écrit :
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh qu e
les informations passe en crypter (on passe par un tunnel crypté). Sin on
c'est vrai qu'on nous conseil toujours de se connecter avec un compte sa ns
priviléges (ou avec des privileges reduits) puis de tourner sur le com pte
root avec la commande su. C'est pour cela qu'on utilise dans quelques ca s
des clés asymétriques (rsa, dsa, etc...) pour les connexions
Euh, c'est une blague ?
Si c'est ca, SSH perd tout son intérêt par rapport à telnet (pour n e citer
que lui ... ).
De ce qu'il me semble, la première étape d'une connexion SSH , c'est des
échanges de clés, avant même de demander un mot de passe ...
C'est d'ailleurs stocké dans un fichier known_hosts côté client , e t est
vérifié à chaque connexion, pour être sur qu'on s'adresse bien à la bonne
machine. (protection contre les "man in the middle").
On m'aurait menti ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/**FrenchLists<http://wiki.debian.org/fr/FrenchL ists>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@**lists.debian.org<debian-user-french-REQ UEST@lists.debian.org>
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/**51B1EDC0.6010405@stuxnet.org<http://li sts.debian.org/51B1EDC0.6010405@stuxnet.org>
Belaïd MOUNSI a écrit :
Je crois que c'est lorsque tu es enfin connecté a ton compte en ssh qu e
les informations passe en crypter (on passe par un tunnel crypté). Sin on
c'est vrai qu'on nous conseil toujours de se connecter avec un compte sa ns
priviléges (ou avec des privileges reduits) puis de tourner sur le com pte
root avec la commande su. C'est pour cela qu'on utilise dans quelques ca s
des clés asymétriques (rsa, dsa, etc...) pour les connexions
Euh, c'est une blague ?
Si c'est ca, SSH perd tout son intérêt par rapport à telnet (pour n e citer
que lui ... ).
De ce qu'il me semble, la première étape d'une connexion SSH , c'est des
échanges de clés, avant même de demander un mot de passe ...
C'est d'ailleurs stocké dans un fichier known_hosts côté client , e t est
vérifié à chaque connexion, pour être sur qu'on s'adresse bien à la bonne
machine. (protection contre les "man in the middle").
On m'aurait menti ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/**FrenchLists<http://wiki.debian.org/fr/FrenchL ists>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@**lists.debian.org<debian-user-french-REQ
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/**<http://li sts.debian.org/
On Fri, 07 Jun 2013 16:23:39 +0200
giggzounet wrote:C'est comme ça qu'on fait sur nos
cluster. on a plussieurs dizaines de machines identiques. on modifie
le /etc/shadow sur une avec passwd et ensuite la modification est
répercutée sur toutes les autres avec un programme qui copie en
parallèle (voir pdsh).
Y'a même un truc qui s'appelle LDAPn qui est très chiant à setupéter
(merci PAP:), mais qui une fois bien établi supprime quasimment
tout PB ;-p (ainsi que, par effet de bord, toute discussion oiseuse…)
On Fri, 07 Jun 2013 16:23:39 +0200
giggzounet <giggzounet@gmail.com> wrote:
C'est comme ça qu'on fait sur nos
cluster. on a plussieurs dizaines de machines identiques. on modifie
le /etc/shadow sur une avec passwd et ensuite la modification est
répercutée sur toutes les autres avec un programme qui copie en
parallèle (voir pdsh).
Y'a même un truc qui s'appelle LDAPn qui est très chiant à setupéter
(merci PAP:), mais qui une fois bien établi supprime quasimment
tout PB ;-p (ainsi que, par effet de bord, toute discussion oiseuse…)
On Fri, 07 Jun 2013 16:23:39 +0200
giggzounet wrote:C'est comme ça qu'on fait sur nos
cluster. on a plussieurs dizaines de machines identiques. on modifie
le /etc/shadow sur une avec passwd et ensuite la modification est
répercutée sur toutes les autres avec un programme qui copie en
parallèle (voir pdsh).
Y'a même un truc qui s'appelle LDAPn qui est très chiant à setupéter
(merci PAP:), mais qui une fois bien établi supprime quasimment
tout PB ;-p (ainsi que, par effet de bord, toute discussion oiseuse…)