Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

ssh et NFS (autofs)

7 réponses
Avatar
gal
Bonjour,

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.

Pour deux utilisateurs locaux pas de souci ...

Merci de votre aide !
Guillaume

7 réponses

Avatar
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

Avatar
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
Avatar
[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.

Avatar
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

Avatar
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 ?
Avatar
TiChou
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

Avatar
[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>