On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Bonjour,
Sur mon réseau local, j'ai besoin d'exécuter une commande sur une
machine à partir d'ùne autre sans avoir à entrer de mot de passe.
La commande est /sbin/shutdown -h now.
Les deux machines sont branchées à un UPS et seulement une des deux
peut être éteinte proprement via l'UPS...
Je n'ai pas rsh d'installer. J'ai donc décider d'utiliser ssh.
Voici ce que j'ai fait:
Sur la machine (ledzep) qui exécutera la script avec la commande
shutdown, j'ai créé une clé:
[ luc]% ssh-keygen -t rsa1
J'ai choisi mot_passe comme passphrase (à refaire avec un meilleur
passphrase...)
Ensuite, j'ai copié ~/.ssh/id_identity.pub
sur l'autre machine (the_doors, mon firewall...) dans le répertoire
.ssh de l'utilisateur avec lequel shutdown sera exécuté (c'est un
utilisateur "ordinaire"). Le fichier a été renommé authorized_keys.
Les droits de ce fichier sont 400.
Pour tester le tout, j'effectue
[ luc]% ssh-agent bash
[ luc]% ssh-add
[ luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls
/home'
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Merci de consacrer votre temps pour me lire et répondre.
Bonjour,
Sur mon réseau local, j'ai besoin d'exécuter une commande sur une
machine à partir d'ùne autre sans avoir à entrer de mot de passe.
La commande est /sbin/shutdown -h now.
Les deux machines sont branchées à un UPS et seulement une des deux
peut être éteinte proprement via l'UPS...
Je n'ai pas rsh d'installer. J'ai donc décider d'utiliser ssh.
Voici ce que j'ai fait:
Sur la machine (ledzep) qui exécutera la script avec la commande
shutdown, j'ai créé une clé:
[luc@ledzep luc]% ssh-keygen -t rsa1
J'ai choisi mot_passe comme passphrase (à refaire avec un meilleur
passphrase...)
Ensuite, j'ai copié ~/.ssh/id_identity.pub
sur l'autre machine (the_doors, mon firewall...) dans le répertoire
.ssh de l'utilisateur avec lequel shutdown sera exécuté (c'est un
utilisateur "ordinaire"). Le fichier a été renommé authorized_keys.
Les droits de ce fichier sont 400.
Pour tester le tout, j'effectue
[luc@ledzep luc]% ssh-agent bash
[luc@ledzep luc]% ssh-add
[luc@ledzep luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls
/home'
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Merci de consacrer votre temps pour me lire et répondre.
Bonjour,
Sur mon réseau local, j'ai besoin d'exécuter une commande sur une
machine à partir d'ùne autre sans avoir à entrer de mot de passe.
La commande est /sbin/shutdown -h now.
Les deux machines sont branchées à un UPS et seulement une des deux
peut être éteinte proprement via l'UPS...
Je n'ai pas rsh d'installer. J'ai donc décider d'utiliser ssh.
Voici ce que j'ai fait:
Sur la machine (ledzep) qui exécutera la script avec la commande
shutdown, j'ai créé une clé:
[ luc]% ssh-keygen -t rsa1
J'ai choisi mot_passe comme passphrase (à refaire avec un meilleur
passphrase...)
Ensuite, j'ai copié ~/.ssh/id_identity.pub
sur l'autre machine (the_doors, mon firewall...) dans le répertoire
.ssh de l'utilisateur avec lequel shutdown sera exécuté (c'est un
utilisateur "ordinaire"). Le fichier a été renommé authorized_keys.
Les droits de ce fichier sont 400.
Pour tester le tout, j'effectue
[ luc]% ssh-agent bash
[ luc]% ssh-add
[ luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls
/home'
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Merci de consacrer votre temps pour me lire et répondre.
Pour tester le tout, j'effectue
[ luc]% ssh-agent bash
[ luc]% ssh-add
L'agent SSH est inutile dans votre cas. Oubliez le.
Dans mes lectures subséquentes, je crois que ça serait une bonne pratique de
[ luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls
/home'
On continue de me demander le mot de passe de l'utilisateur...
Oui, certainement parce que la session SSH a été négociée avec la version 2
du protocole SSH et donc ignore votre jeu de clés RSA1.
Par défaut sur les serveurs OpenSSH on établit d'abord une connexion avec le
protocole 2 si le client l'accepte et ensuite avec le protocole 1 si le
client a refusé le protocole 2.Que faire ?
Plusieurs possibilités :
- Modifier l'ordre des protocoles dans la configuration du serveur ssh de
la machine "the_doors" en plaçant la ligne 'Protocol 1,2' dans le fichier
/etc/ssh/sshd_config. Je vous le déconseille fortement.
- Forcer le client ssh sur la machine "ledzep" à n'utiliser que le
protocole 1 en passant comme paramètre '-1' à la commande 'ssh' :
$ ssh -1 'ls /home'
(Notez que la commande 'slogin' est un lien pointant sur la commande 'ssh')
- Et enfin la solution que je vous conseille avant tout, c'est d'utiliser
un jeu de clé RSA pour le protocole 2 :
$ ssh-keygen -t rsa
$ ssh 'umask 077;mkdir .ssh'
$ scp ~/.ssh/id_rsa.pub
:.ssh/authorized_keys
et
$ ssh 'ls /home'
pour voir le résultat.
Attention que si vous avez définit une passphrase lors de la génération du
jeu de clé RSA, la passphrase vous sera alors demandé lors de la session
SSH. Si ne vous souhaitez ne rien saisir lors de cette session, mettez une
passphrase vide.
J'ai décidé d'utiliser le protocole 2. Cependant,il faut utiliser
Pour tester le tout, j'effectue
[luc@ledzep luc]% ssh-agent bash
[luc@ledzep luc]% ssh-add
L'agent SSH est inutile dans votre cas. Oubliez le.
Dans mes lectures subséquentes, je crois que ça serait une bonne pratique de
[luc@ledzep luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls
/home'
On continue de me demander le mot de passe de l'utilisateur...
Oui, certainement parce que la session SSH a été négociée avec la version 2
du protocole SSH et donc ignore votre jeu de clés RSA1.
Par défaut sur les serveurs OpenSSH on établit d'abord une connexion avec le
protocole 2 si le client l'accepte et ensuite avec le protocole 1 si le
client a refusé le protocole 2.
Que faire ?
Plusieurs possibilités :
- Modifier l'ordre des protocoles dans la configuration du serveur ssh de
la machine "the_doors" en plaçant la ligne 'Protocol 1,2' dans le fichier
/etc/ssh/sshd_config. Je vous le déconseille fortement.
- Forcer le client ssh sur la machine "ledzep" à n'utiliser que le
protocole 1 en passant comme paramètre '-1' à la commande 'ssh' :
$ ssh -1 utilisateur_sur_the_doors@the_doors 'ls /home'
(Notez que la commande 'slogin' est un lien pointant sur la commande 'ssh')
- Et enfin la solution que je vous conseille avant tout, c'est d'utiliser
un jeu de clé RSA pour le protocole 2 :
$ ssh-keygen -t rsa
$ ssh utilisateur_sur_the_doors@the_doors 'umask 077;mkdir .ssh'
$ scp ~/.ssh/id_rsa.pub
utilisateur_sur_the_doors@the_doors:.ssh/authorized_keys
et
$ ssh utilisateur_sur_the_doors@the_doors 'ls /home'
pour voir le résultat.
Attention que si vous avez définit une passphrase lors de la génération du
jeu de clé RSA, la passphrase vous sera alors demandé lors de la session
SSH. Si ne vous souhaitez ne rien saisir lors de cette session, mettez une
passphrase vide.
J'ai décidé d'utiliser le protocole 2. Cependant,il faut utiliser
Pour tester le tout, j'effectue
[ luc]% ssh-agent bash
[ luc]% ssh-add
L'agent SSH est inutile dans votre cas. Oubliez le.
Dans mes lectures subséquentes, je crois que ça serait une bonne pratique de
[ luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls
/home'
On continue de me demander le mot de passe de l'utilisateur...
Oui, certainement parce que la session SSH a été négociée avec la version 2
du protocole SSH et donc ignore votre jeu de clés RSA1.
Par défaut sur les serveurs OpenSSH on établit d'abord une connexion avec le
protocole 2 si le client l'accepte et ensuite avec le protocole 1 si le
client a refusé le protocole 2.Que faire ?
Plusieurs possibilités :
- Modifier l'ordre des protocoles dans la configuration du serveur ssh de
la machine "the_doors" en plaçant la ligne 'Protocol 1,2' dans le fichier
/etc/ssh/sshd_config. Je vous le déconseille fortement.
- Forcer le client ssh sur la machine "ledzep" à n'utiliser que le
protocole 1 en passant comme paramètre '-1' à la commande 'ssh' :
$ ssh -1 'ls /home'
(Notez que la commande 'slogin' est un lien pointant sur la commande 'ssh')
- Et enfin la solution que je vous conseille avant tout, c'est d'utiliser
un jeu de clé RSA pour le protocole 2 :
$ ssh-keygen -t rsa
$ ssh 'umask 077;mkdir .ssh'
$ scp ~/.ssh/id_rsa.pub
:.ssh/authorized_keys
et
$ ssh 'ls /home'
pour voir le résultat.
Attention que si vous avez définit une passphrase lors de la génération du
jeu de clé RSA, la passphrase vous sera alors demandé lors de la session
SSH. Si ne vous souhaitez ne rien saisir lors de cette session, mettez une
passphrase vide.
J'ai décidé d'utiliser le protocole 2. Cependant,il faut utiliser
L'agent SSH est inutile dans votre cas. Oubliez le.
Dans mes lectures subséquentes, je crois que ça serait une bonne
pratique de l'utiliser.
Mais puisque c'est peu probable que quelqu'un vienne me voler ma clé
pour ce connecter à mon vieux P133, je suis prêt à prendre le risque
;-)
J'ai décidé d'utiliser le protocole 2. Cependant,il faut utiliser
authorisez_keys2 avec ce type de protocole.
J'avais
Permission denied (publickey,keyboard-interactive)
Merci pour tout! J'en ai ramé un coup...
C'est pourtant si simple quand on sait quoi faire!
L'agent SSH est inutile dans votre cas. Oubliez le.
Dans mes lectures subséquentes, je crois que ça serait une bonne
pratique de l'utiliser.
Mais puisque c'est peu probable que quelqu'un vienne me voler ma clé
pour ce connecter à mon vieux P133, je suis prêt à prendre le risque
;-)
J'ai décidé d'utiliser le protocole 2. Cependant,il faut utiliser
authorisez_keys2 avec ce type de protocole.
J'avais
Permission denied (publickey,keyboard-interactive)
Merci pour tout! J'en ai ramé un coup...
C'est pourtant si simple quand on sait quoi faire!
L'agent SSH est inutile dans votre cas. Oubliez le.
Dans mes lectures subséquentes, je crois que ça serait une bonne
pratique de l'utiliser.
Mais puisque c'est peu probable que quelqu'un vienne me voler ma clé
pour ce connecter à mon vieux P133, je suis prêt à prendre le risque
;-)
J'ai décidé d'utiliser le protocole 2. Cependant,il faut utiliser
authorisez_keys2 avec ce type de protocole.
J'avais
Permission denied (publickey,keyboard-interactive)
Merci pour tout! J'en ai ramé un coup...
C'est pourtant si simple quand on sait quoi faire!
Bonjour,
Sur mon réseau local, j'ai besoin d'exécuter une commande sur une machine
à partir d'ùne autre sans avoir à entrer de mot de passe.
La commande est /sbin/shutdown -h now.
Les deux machines sont branchées à un UPS et seulement une des deux peut
être éteinte proprement via l'UPS...
Je n'ai pas rsh d'installer. J'ai donc décider d'utiliser ssh.
Voici ce que j'ai fait:
Sur la machine (ledzep) qui exécutera la script avec la commande shutdown,
j'ai créé une clé:
[ luc]% ssh-keygen -t rsa1
J'ai choisi mot_passe comme passphrase (à refaire avec un meilleur
passphrase...)
Ensuite, j'ai copié ~/.ssh/id_identity.pub
sur l'autre machine (the_doors, mon firewall...) dans le répertoire .ssh
de l'utilisateur avec lequel shutdown sera exécuté (c'est un utilisateur
"ordinaire"). Le fichier a été renommé authorized_keys. Les droits de ce
fichier sont 400.
Pour tester le tout, j'effectue
[ luc]% ssh-agent bash
[ luc]% ssh-add
[ luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls /home'
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Merci de consacrer votre temps pour me lire et répondre.
Luc
Bonjour,
Sur mon réseau local, j'ai besoin d'exécuter une commande sur une machine
à partir d'ùne autre sans avoir à entrer de mot de passe.
La commande est /sbin/shutdown -h now.
Les deux machines sont branchées à un UPS et seulement une des deux peut
être éteinte proprement via l'UPS...
Je n'ai pas rsh d'installer. J'ai donc décider d'utiliser ssh.
Voici ce que j'ai fait:
Sur la machine (ledzep) qui exécutera la script avec la commande shutdown,
j'ai créé une clé:
[luc@ledzep luc]% ssh-keygen -t rsa1
J'ai choisi mot_passe comme passphrase (à refaire avec un meilleur
passphrase...)
Ensuite, j'ai copié ~/.ssh/id_identity.pub
sur l'autre machine (the_doors, mon firewall...) dans le répertoire .ssh
de l'utilisateur avec lequel shutdown sera exécuté (c'est un utilisateur
"ordinaire"). Le fichier a été renommé authorized_keys. Les droits de ce
fichier sont 400.
Pour tester le tout, j'effectue
[luc@ledzep luc]% ssh-agent bash
[luc@ledzep luc]% ssh-add
[luc@ledzep luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls /home'
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Merci de consacrer votre temps pour me lire et répondre.
Luc
Bonjour,
Sur mon réseau local, j'ai besoin d'exécuter une commande sur une machine
à partir d'ùne autre sans avoir à entrer de mot de passe.
La commande est /sbin/shutdown -h now.
Les deux machines sont branchées à un UPS et seulement une des deux peut
être éteinte proprement via l'UPS...
Je n'ai pas rsh d'installer. J'ai donc décider d'utiliser ssh.
Voici ce que j'ai fait:
Sur la machine (ledzep) qui exécutera la script avec la commande shutdown,
j'ai créé une clé:
[ luc]% ssh-keygen -t rsa1
J'ai choisi mot_passe comme passphrase (à refaire avec un meilleur
passphrase...)
Ensuite, j'ai copié ~/.ssh/id_identity.pub
sur l'autre machine (the_doors, mon firewall...) dans le répertoire .ssh
de l'utilisateur avec lequel shutdown sera exécuté (c'est un utilisateur
"ordinaire"). Le fichier a été renommé authorized_keys. Les droits de ce
fichier sont 400.
Pour tester le tout, j'effectue
[ luc]% ssh-agent bash
[ luc]% ssh-add
[ luc]% slogin -l utilisateur_sur_the_doors the_doors 'ls /home'
On continue de me demander le mot de passe de l'utilisateur...
Que faire ?
Merci de consacrer votre temps pour me lire et répondre.
Luc
L'agent permet d'utiliser la clé privé de la machine locale si on désire
alors se connecter vers une autre machine cliente sans que la clé soit
présente sur la machine cliente. Ca n'était pas le cas dans votre
utilisation. Ou alors j'ai loupé une étape.
[...]
L'agent permet d'utiliser la clé privé de la machine locale si on désire
alors se connecter vers une autre machine cliente sans que la clé soit
présente sur la machine cliente. Ca n'était pas le cas dans votre
utilisation. Ou alors j'ai loupé une étape.
[...]
L'agent permet d'utiliser la clé privé de la machine locale si on désire
alors se connecter vers une autre machine cliente sans que la clé soit
présente sur la machine cliente. Ca n'était pas le cas dans votre
utilisation. Ou alors j'ai loupé une étape.
[...]
TiChou wrote:
[...]L'agent permet d'utiliser la clé privé de la machine locale si on désire
alors se connecter vers une autre machine cliente sans que la clé soit
présente sur la machine cliente. Ca n'était pas le cas dans votre
utilisation. Ou alors j'ai loupé une étape.
[...]
Vous avez dû mal vous exprimer, l'agent ne permet en aucun cas de se
connecter sur une machine qui ne posséde pas une copie de notre clef
(publique).
Si la machine à laquelle on souhaite se connecter est configuré pour
n'accépter que l'autentification par clef (et non par mots de passe),
les élements suivants sont nécessaires :
- la clef privée sur la machine depuis laquelle on veux se connecter.
- la clef publique correspondante sur la machine à laquelle on souhaite
se connecter.
Par mesure de sécurité, la clef privée est protégés par mot de passe.
Celui-ci est demandé à chaque connection. L'agent peut-être utilisé pour
gardé en mêmoire la clef privée et eviter ansi de devoir donner le mot
de passe a chaque connection.
TiChou wrote:
[...]
L'agent permet d'utiliser la clé privé de la machine locale si on désire
alors se connecter vers une autre machine cliente sans que la clé soit
présente sur la machine cliente. Ca n'était pas le cas dans votre
utilisation. Ou alors j'ai loupé une étape.
[...]
Vous avez dû mal vous exprimer, l'agent ne permet en aucun cas de se
connecter sur une machine qui ne posséde pas une copie de notre clef
(publique).
Si la machine à laquelle on souhaite se connecter est configuré pour
n'accépter que l'autentification par clef (et non par mots de passe),
les élements suivants sont nécessaires :
- la clef privée sur la machine depuis laquelle on veux se connecter.
- la clef publique correspondante sur la machine à laquelle on souhaite
se connecter.
Par mesure de sécurité, la clef privée est protégés par mot de passe.
Celui-ci est demandé à chaque connection. L'agent peut-être utilisé pour
gardé en mêmoire la clef privée et eviter ansi de devoir donner le mot
de passe a chaque connection.
TiChou wrote:
[...]L'agent permet d'utiliser la clé privé de la machine locale si on désire
alors se connecter vers une autre machine cliente sans que la clé soit
présente sur la machine cliente. Ca n'était pas le cas dans votre
utilisation. Ou alors j'ai loupé une étape.
[...]
Vous avez dû mal vous exprimer, l'agent ne permet en aucun cas de se
connecter sur une machine qui ne posséde pas une copie de notre clef
(publique).
Si la machine à laquelle on souhaite se connecter est configuré pour
n'accépter que l'autentification par clef (et non par mots de passe),
les élements suivants sont nécessaires :
- la clef privée sur la machine depuis laquelle on veux se connecter.
- la clef publique correspondante sur la machine à laquelle on souhaite
se connecter.
Par mesure de sécurité, la clef privée est protégés par mot de passe.
Celui-ci est demandé à chaque connection. L'agent peut-être utilisé pour
gardé en mêmoire la clef privée et eviter ansi de devoir donner le mot
de passe a chaque connection.
Dans l'article news:c07gtc$8pc$,
Alexis Muller écrivait :
[...]
- la clef privée sur la machine depuis laquelle on veux se connecter.
Sauf si on s'est préalablement connecté sur cette machine depuis une autre
(ce que j'appelle la machine locale) et que l'agent SSH a été activé. Et
c'est bien de cela dont je parlais au départ et cela ne correspondait donc
pas à la situation de Luc Martineau qui avait activé son agent SSH.
Dans l'article news:c07gtc$8pc$1@netserv.univ-lille1.fr,
Alexis Muller <Alexis.Muller@nospam.lifl.fr> écrivait :
[...]
- la clef privée sur la machine depuis laquelle on veux se connecter.
Sauf si on s'est préalablement connecté sur cette machine depuis une autre
(ce que j'appelle la machine locale) et que l'agent SSH a été activé. Et
c'est bien de cela dont je parlais au départ et cela ne correspondait donc
pas à la situation de Luc Martineau qui avait activé son agent SSH.
Dans l'article news:c07gtc$8pc$,
Alexis Muller écrivait :
[...]
- la clef privée sur la machine depuis laquelle on veux se connecter.
Sauf si on s'est préalablement connecté sur cette machine depuis une autre
(ce que j'appelle la machine locale) et que l'agent SSH a été activé. Et
c'est bien de cela dont je parlais au départ et cela ne correspondait donc
pas à la situation de Luc Martineau qui avait activé son agent SSH.
Ce comportement est une option possible des outils openSSH. Mais la
fonction première de l'agent SSH reste la mémorisation de la clef
privée sous forme décrypté, pas le "forward" de clefs.
Personnellement, l'agent me permet de me loguer à des machines
différentes une bonne dizaine de fois par jour en ne tapant ma
"passe phrase" qu'une fois, heureusement ;-)
Ce comportement est une option possible des outils openSSH. Mais la
fonction première de l'agent SSH reste la mémorisation de la clef
privée sous forme décrypté, pas le "forward" de clefs.
Personnellement, l'agent me permet de me loguer à des machines
différentes une bonne dizaine de fois par jour en ne tapant ma
"passe phrase" qu'une fois, heureusement ;-)
Ce comportement est une option possible des outils openSSH. Mais la
fonction première de l'agent SSH reste la mémorisation de la clef
privée sous forme décrypté, pas le "forward" de clefs.
Personnellement, l'agent me permet de me loguer à des machines
différentes une bonne dizaine de fois par jour en ne tapant ma
"passe phrase" qu'une fois, heureusement ;-)
