Je cherche =E0 configurer deux machines Linux de mani=E8re =E0 faire un
scp de
l'une sur l'autre sans mot de passe.
Sur la premi=E8re machine le home de l'utilisateur est mont=E9 depuis un
serveur NFS
(sous /Users/toto) sur la seconde pas de souci l'utilisateur est local
(/home/toto). J'ai fait l'=E9change de clef publique comme d'habitude.
Le probl=E8me
c'est que depuis machine2 un ssh machine1 me demande le mot de passe.
Un ssh -vvv me confirme le fait qu'il cherche l'info dans
/home/toto/.ssh et non pas dans /Users/toto.ssh qui est le vrai
home....
Je n'ai pas d'id=E9e (google pas plus) - j'ai essay=E9 man sshd_config
sans succ=E8s. Mais peut-=EAtre est ce un pb de NIS pourtant
/etc/nsswitch.conf =E0 l'air correct.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TiChou
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
Sur la première machine le home de l'utilisateur est monté depuis un serveur NFS (sous /Users/toto) sur la seconde pas de souci l'utilisateur est local (/home/toto).
J'ai fait l'échange de clef publique comme d'habitude.
À savoir ?
Le problème c'est que depuis machine2 un ssh machine1 me demande le mot de passe. Un ssh -vvv me confirme le fait qu'il cherche l'info dans /home/toto/.ssh et non pas dans /Users/toto.ssh qui est le vrai home....
Vous dites que sur la machine 2 le répertoire home de toto est /home/toto. Donc si vous faites un ssh depuis machine 2, normal que la commande ssh aille lire le fichier /home/toto/.ssh.
-- TiChou
Dans le message
<news:1130183841.399913.189840@g14g2000cwa.googlegroups.com>,
*gal* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
Sur la première machine le home de l'utilisateur est monté depuis un
serveur NFS (sous /Users/toto) sur la seconde pas de souci l'utilisateur
est local (/home/toto).
J'ai fait l'échange de clef publique comme d'habitude.
À savoir ?
Le problème c'est que depuis machine2 un ssh machine1 me demande le mot
de passe.
Un ssh -vvv me confirme le fait qu'il cherche l'info dans
/home/toto/.ssh et non pas dans /Users/toto.ssh qui est le vrai
home....
Vous dites que sur la machine 2 le répertoire home de toto est /home/toto.
Donc si vous faites un ssh depuis machine 2, normal que la commande ssh
aille lire le fichier /home/toto/.ssh.
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
Sur la première machine le home de l'utilisateur est monté depuis un serveur NFS (sous /Users/toto) sur la seconde pas de souci l'utilisateur est local (/home/toto).
J'ai fait l'échange de clef publique comme d'habitude.
À savoir ?
Le problème c'est que depuis machine2 un ssh machine1 me demande le mot de passe. Un ssh -vvv me confirme le fait qu'il cherche l'info dans /home/toto/.ssh et non pas dans /Users/toto.ssh qui est le vrai home....
Vous dites que sur la machine 2 le répertoire home de toto est /home/toto. Donc si vous faites un ssh depuis machine 2, normal que la commande ssh aille lire le fichier /home/toto/.ssh.
-- TiChou
gal
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ... machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis machine2 vers machine1 sans mot de passe.
J'ai un utilisateur toto: Sur machine1 son compte est monté NFS (autofs) et géré par NIS sur machine2 ce compte est défini localement dans /etc/passwd et sous /home.
Quand je fais un: machine2> ssh -vvv machine1 Je vois que ssh va chercher les credentials dans /home/.ssh; ils y sont bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh (mon point de montage NFS)
Guillaume
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ...
machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis
machine2 vers machine1 sans mot de passe.
J'ai un utilisateur toto:
Sur machine1 son compte est monté NFS (autofs) et géré par NIS sur
machine2 ce compte est défini localement dans /etc/passwd et sous
/home.
Quand je fais un: machine2> ssh -vvv machine1
Je vois que ssh va chercher les credentials dans /home/.ssh; ils y sont
bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh
(mon point de montage NFS)
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ... machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis machine2 vers machine1 sans mot de passe.
J'ai un utilisateur toto: Sur machine1 son compte est monté NFS (autofs) et géré par NIS sur machine2 ce compte est défini localement dans /etc/passwd et sous /home.
Quand je fais un: machine2> ssh -vvv machine1 Je vois que ssh va chercher les credentials dans /home/.ssh; ils y sont bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh (mon point de montage NFS)
Guillaume
[SauronDeMordor]
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ... machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis machine2 vers machine1 sans mot de passe.
J'ai un utilisateur toto: Sur machine1 son compte est monté NFS (autofs) et géré par NIS su r machine2 ce compte est défini localement dans /etc/passwd et sous /home.
Quand je fais un: machine2> ssh -vvv machine1 Je vois que ssh va chercher les credentials dans /home/.ssh; ils y sont bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh (mon point de montage NFS)
Guillaume
verifier que $HOME de toto de machine 2 est correcte.
regarder le contenu de /etc/nsswitch.conf si file est avant nis alors verifier que toto n est pas present dans /etc /password.
ensuite verifier avev la commande suivante que le Home de toto est bien / Users/toto verifier que /home n est pas un montage de /Users (mount bind, lien symbo lique) car cela peut etre la raison du message d erreur.
ensuite verifier que les droit de /Users/toto/.ssh soit correct pour que le user sshd (si separation de privilege active) et que le user root puissse acceder a ces donnees. en effet avec nfs, root local est souvent mapé enn anonymous sur le serveur nfs.
voila en esperant vous avoir donner des pistes de reflexions.
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ...
machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis
machine2 vers machine1 sans mot de passe.
J'ai un utilisateur toto:
Sur machine1 son compte est monté NFS (autofs) et géré par NIS su r
machine2 ce compte est défini localement dans /etc/passwd et sous
/home.
Quand je fais un: machine2> ssh -vvv machine1
Je vois que ssh va chercher les credentials dans /home/.ssh; ils y sont
bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh
(mon point de montage NFS)
Guillaume
verifier que $HOME de toto de machine 2 est correcte.
regarder le contenu de /etc/nsswitch.conf
si file est avant nis alors verifier que toto n est pas present dans /etc /password.
ensuite verifier avev la commande suivante que le Home de toto est bien / Users/toto
verifier que /home n est pas un montage de /Users (mount bind, lien symbo lique) car cela peut etre la raison du message
d erreur.
ensuite verifier que les droit de /Users/toto/.ssh soit correct pour que le user sshd (si separation de privilege
active) et que le user root puissse acceder a ces donnees. en effet avec nfs, root local est souvent mapé enn anonymous
sur le serveur nfs.
voila en esperant vous avoir donner des pistes de reflexions.
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ... machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis machine2 vers machine1 sans mot de passe.
J'ai un utilisateur toto: Sur machine1 son compte est monté NFS (autofs) et géré par NIS su r machine2 ce compte est défini localement dans /etc/passwd et sous /home.
Quand je fais un: machine2> ssh -vvv machine1 Je vois que ssh va chercher les credentials dans /home/.ssh; ils y sont bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh (mon point de montage NFS)
Guillaume
verifier que $HOME de toto de machine 2 est correcte.
regarder le contenu de /etc/nsswitch.conf si file est avant nis alors verifier que toto n est pas present dans /etc /password.
ensuite verifier avev la commande suivante que le Home de toto est bien / Users/toto verifier que /home n est pas un montage de /Users (mount bind, lien symbo lique) car cela peut etre la raison du message d erreur.
ensuite verifier que les droit de /Users/toto/.ssh soit correct pour que le user sshd (si separation de privilege active) et que le user root puissse acceder a ces donnees. en effet avec nfs, root local est souvent mapé enn anonymous sur le serveur nfs.
voila en esperant vous avoir donner des pistes de reflexions.
TiChou
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ... machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis machine2 vers machine1 sans mot de passe.
Oui, si sur la machine2 la clé privée se trouve bien dans ~/.ssh/identity ou dans ~/.ssh/rsa, si le fichier de la clé privée a bien les bonnes permissions (0600), si sur la machine1 le répertoire ~/.ssh appartient au bon propriétaire et si le serveur ssh de machine1 accepte l'authentification par clé publique (PubkeyAuthentication à yes) et l'authentification RSA (RSAAuthentication à yes).
Toutes ces conditions doivent être vérifiées avant d'aller plus loin.
J'ai un utilisateur toto: Sur machine1 son compte est monté NFS (autofs) et géré par NIS sur machine2 ce compte est défini localement dans /etc/passwd et sous /home.
Quand je fais un: machine2> ssh -vvv machine1 Je vois que ssh va chercher les credentials dans /home/.ssh;
Vous vouliez dire dans /home/toto/.ssh ?
ils y sont bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh (mon point de montage NFS)
Mais ssh est lancé sur machine2, pourquoi donc voudriez-vous qu'il aille dans /Users/toto/.ssh de la machine1 ? Et quand bien même, comment pourrai-il le faire surtout sans être authentifié? C'est le serveur ssh de machine1 qui doit aller dans /Users/toto/.ssh. Lancez le serveur ssh de machine1 en mode debug si vous voulez vous assurer qu'il y aille bien (ce que je ne doute pas puisque votre commande scp du début y est allé à priori sans soucis).
-- TiChou
Dans le message
<news:1130219053.665727.275210@z14g2000cwz.googlegroups.com>,
*gal* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ...
machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis
machine2 vers machine1 sans mot de passe.
Oui, si sur la machine2 la clé privée se trouve bien dans ~/.ssh/identity ou
dans ~/.ssh/rsa, si le fichier de la clé privée a bien les bonnes
permissions (0600), si sur la machine1 le répertoire ~/.ssh appartient au
bon propriétaire et si le serveur ssh de machine1 accepte l'authentification
par clé publique (PubkeyAuthentication à yes) et l'authentification RSA
(RSAAuthentication à yes).
Toutes ces conditions doivent être vérifiées avant d'aller plus loin.
J'ai un utilisateur toto:
Sur machine1 son compte est monté NFS (autofs) et géré par NIS sur
machine2 ce compte est défini localement dans /etc/passwd et sous
/home.
Quand je fais un: machine2> ssh -vvv machine1
Je vois que ssh va chercher les credentials dans /home/.ssh;
Vous vouliez dire dans /home/toto/.ssh ?
ils y sont bien pour machine2 mais pour machine1 ils sont
dans /Users/toto/.ssh (mon point de montage NFS)
Mais ssh est lancé sur machine2, pourquoi donc voudriez-vous qu'il aille
dans /Users/toto/.ssh de la machine1 ? Et quand bien même, comment
pourrai-il le faire surtout sans être authentifié?
C'est le serveur ssh de machine1 qui doit aller dans /Users/toto/.ssh.
Lancez le serveur ssh de machine1 en mode debug si vous voulez vous assurer
qu'il y aille bien (ce que je ne doute pas puisque votre commande scp du
début y est allé à priori sans soucis).
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Sur machine1 et machine2: ssh-keygen -t rsa, pas de pass phrase ... machine2> scp .ssh/id_rsa.pub machine1:.ssh/authorized_keys
Normalement à ce point je m'attends à pouvoir me connecter depuis machine2 vers machine1 sans mot de passe.
Oui, si sur la machine2 la clé privée se trouve bien dans ~/.ssh/identity ou dans ~/.ssh/rsa, si le fichier de la clé privée a bien les bonnes permissions (0600), si sur la machine1 le répertoire ~/.ssh appartient au bon propriétaire et si le serveur ssh de machine1 accepte l'authentification par clé publique (PubkeyAuthentication à yes) et l'authentification RSA (RSAAuthentication à yes).
Toutes ces conditions doivent être vérifiées avant d'aller plus loin.
J'ai un utilisateur toto: Sur machine1 son compte est monté NFS (autofs) et géré par NIS sur machine2 ce compte est défini localement dans /etc/passwd et sous /home.
Quand je fais un: machine2> ssh -vvv machine1 Je vois que ssh va chercher les credentials dans /home/.ssh;
Vous vouliez dire dans /home/toto/.ssh ?
ils y sont bien pour machine2 mais pour machine1 ils sont dans /Users/toto/.ssh (mon point de montage NFS)
Mais ssh est lancé sur machine2, pourquoi donc voudriez-vous qu'il aille dans /Users/toto/.ssh de la machine1 ? Et quand bien même, comment pourrai-il le faire surtout sans être authentifié? C'est le serveur ssh de machine1 qui doit aller dans /Users/toto/.ssh. Lancez le serveur ssh de machine1 en mode debug si vous voulez vous assurer qu'il y aille bien (ce que je ne doute pas puisque votre commande scp du début y est allé à priori sans soucis).
-- TiChou
gal
En fait dans la log j'ai une erreur: Authentication refused: bad ownership or modes for directory:/Users/toto
Pas très verbeux. Qqn a-t-il déjà rencontrer cette erreur ?
En fait dans la log j'ai une erreur:
Authentication refused: bad ownership or modes for
directory:/Users/toto
Pas très verbeux. Qqn a-t-il déjà rencontrer cette erreur ?
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
En fait dans la log j'ai une erreur: Authentication refused: bad ownership or modes for directory:/Users/toto
Pas très verbeux.
Mais si, tout est dit, cf ma précédente remarque. Vérifier le propriétaire et les permissions de /Users/toto.
-- TiChou
[SauronDeMordor]
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
En fait dans la log j'ai une erreur: Authentication refused: bad ownership or modes for directory:/Users/toto
Pas très verbeux.
Mais si, tout est dit, cf ma précédente remarque. Vérifier le propriétaire et les permissions de /Users/toto.
c ets ce que j ai ecrit dans le mon poste precedent, verifier aussi que l es droit sont transmis par nfs, car si le user sshd n existe pas sur le serveur qui sert le file system, ou si root est mape en anonymous (options root_squashfs du serveur nfs) et bien les droits que tu vois avec ls -l ne sont pas pris e n compte.
man exports
<snip> root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids that might be equally sensitive, such as user b in. <snip>
Dans le message
<news:1130274440.772005.197470@g43g2000cwa.googlegroups.com>,
*gal* tapota sur f.c.o.l.configuration :
En fait dans la log j'ai une erreur:
Authentication refused: bad ownership or modes for
directory:/Users/toto
Pas très verbeux.
Mais si, tout est dit, cf ma précédente remarque. Vérifier le
propriétaire et les permissions de /Users/toto.
c ets ce que j ai ecrit dans le mon poste precedent, verifier aussi que l es droit sont transmis par nfs, car si le user
sshd n existe pas sur le serveur qui sert le file system, ou si root est mape en anonymous (options root_squashfs du
serveur nfs) et bien les droits que tu vois avec ls -l ne sont pas pris e n compte.
man exports
<snip>
root_squash
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any
other uids that might be equally sensitive, such as user b in.
<snip>
Dans le message <news:, *gal* tapota sur f.c.o.l.configuration :
En fait dans la log j'ai une erreur: Authentication refused: bad ownership or modes for directory:/Users/toto
Pas très verbeux.
Mais si, tout est dit, cf ma précédente remarque. Vérifier le propriétaire et les permissions de /Users/toto.
c ets ce que j ai ecrit dans le mon poste precedent, verifier aussi que l es droit sont transmis par nfs, car si le user sshd n existe pas sur le serveur qui sert le file system, ou si root est mape en anonymous (options root_squashfs du serveur nfs) et bien les droits que tu vois avec ls -l ne sont pas pris e n compte.
man exports
<snip> root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids that might be equally sensitive, such as user b in. <snip>