Vous n'êtes pas identifié(e).
mais est-ce que ce n'est pas plutôt
sans le "d" à la fin de ssh ? car chez moi la 1er n'est pas reconnu et la 2ème fonctionne.
et j'ai également galéré pour ajouter les clefs au fichier ~/.ssh/authorized_keys (j'ai 2 ordi qui doivent accéder au serveur) et l'une remplaçai l'autre en utilisant "scp" alors qu'il existe une commande
pour faire ça. Sûrement très connu...quand on connaît. Peut-être en toucher 2 mots dans la doc ? personnellement j'ai trouvé ça par là : http://doc.fedora-fr.org/wiki/SSH_:_Aut … ge_de_SSHd
par ailleurs j'ai suivi les conseils de la doc ubuntu sur les droits :
Mot de passe toujours demandés avec authentification par clés
Si après avoir suivi ce tutoriel un mot de passe est toujours demandé, il se peut que ce soit dû à un problème de droits sur votre Dossier Personnel.
Sur la machine distante regardez le fichier /var/log/auth.log pour y trouver des indications et notamment et si la ligne suivante apparaît :
Authentication refused: bad ownership or modes for directory /home/votre_login
Alors faites :
chmod 755 $HOME
Et tout devrait rentrer dans l'ordre.
Si ce n'est toujours pas le cas, c'est que le serveur doit être configuré en mode de sécurité strict (c'est le cas par défaut sur Ubuntu).
Effectuez les opérations suivantes :
Sur le serveur :
dans le fichier /etc/ssh/sshd_config, la ligne StrictModes yes indique que le serveur va être très pointilleux sur les droits du compte sur lequel on se connecte en ssh.
saisissez ensuite les commandes suivantes
chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Sur le client, dans /etc/ssh/ssh_config, rajoutez la ligne PreferredAuthentications publickey.
Bref tout ça pour dire que ça ne marche toujours pas ! Il me renvoie un
problème : je n'ai pas fait attention et j'ai fait la commande "chmod 755 $HOME" en tant que root ! est-ce un problème pour la sécurité du serveur ? De la même façon le chmod en tant que simple utilisateur n’ayant rien changé était-ce vraiment utile et peut-on (doit-on ?) revenir en arrière ?
J'ai de bonne raison de croire qu'un fichier "config" pourrai être plus utile mais je ne sais pas trop comment ça fonctionne et comment le personnaliser... je vais continuer à chercher mais si vous avez des pistes... merci
Dernière modification par jean-kiki (22-05-2013 10:34:48)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
Ensuite, tu as essayé un
?
Pour le ssh-copy-id, tu as bien envoyé le fichier .pub et non l'autre ?
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dernière modification par jean-kiki (20-05-2013 10:04:31)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
Sur le serveur, les droits du fichier de clés autorisés doivent être les suivants :
Sur le client, les droits des fichiers de clés doivent être les suivants :
Si tout cela est bon, ça n'est pas un pb de droits.
Tu peux nous paster le contenu de ton fichier /etc/ssh/sshd_config du serveur, si tu l'as modifié.
Pour ce qui est du fichier ~/.ssh/authorized_keys du serveur, il ne contient pas d'info secrètes normalement. Une chose que tu peux faire, c'est le supprimer et refaire depuis le client un
cela le recréera et re-copiera bien la clé dessus.
Si un
ne marche toujours pas après ça, on regardera le
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
sur le client :
pour ls -lh /home/user/.ssh/authorized_keys sur le serveur :
pour ls -lh ~/.ssh/speedy_robbie* sur le client (j'ai nommé mes clefs du nom de mes machines... ce n'est pas secret comme info ?) :
ah ! à priori les droits sur ma clef publique client ne semble pas correspondre....
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
j'avais modifié le port que j'ai remis à 22 pour le publier sur le forum. Et sinon le fait que mes 2 machines clientes qui sont amenées à se connecter au serveur ai le même nom d'utilisateur ça n'est pas un problème pour AllowUsers si on le met qu'une fois ?
pour "ssh-copy-id" je viens de voir dans la doc ubuntu :
[...] change également les permissions des répertoires ~/.ssh et ~/.ssh/authorized keys de l'hôte distant pour enlever l'accès en écriture du groupe (qui vous empêcherait de vous connecter si le serveur distant ssh a "StrictModes yes" dans son fichier de configuration
heu... et là quand je veux recréer un fichier authorized_keys il me met "Permission denied (password)" gloups ! (j'ai remodifié mon sshs_config bien sur pour l'autoriser, et ça avant ça marchait)
Dernière modification par jean-kiki (20-05-2013 11:25:13)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
UsePAM no -> désactive la connection par mot de passe
et chez ubuntu ils sont d'accord aussi : http://doc.ubuntu-fr.org/ssh#configurat … erveur_ssh
pour utiliser le mot de passe je l'ai remis à yes (et "réinversé" les autres options bien sûr)
[edit] : hop là ! ok c'est bon pour le mot de passe. J'avais laissé un "PreferredAuthentications publickey" dans le fichier /etc/ssh/ssh_config sur le poste client. bon ben comme ça je comprend mieux la relation entre les différents fichiers ! hum hum...
du coup j'ai pu renvoyer un ssh-copy-id. Comme ça ne marche toujours pas, voilà de quoi aider à m'aider :
Dernière modification par jean-kiki (20-05-2013 14:43:02)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
edit: je comprend que ça ne peut pas marcher en lisant ça:
pour ls -lh /home/user/.ssh/authorized_keys sur le serveur :
-rw------- 1 jeankiki jeankiki 1,5k mai 20 11:32 /home/jeankiki/.ssh/authorized_keys
le fichier authorized_keys n' appartient pas au user mais à root, il contient la clé publique
la clé privée se trouvant évidemment chez le client dans /home/user/.ssh/nom_que_tu_lui_as_donné (par défaut id_rsa)
Dernière modification par nikau (21-05-2013 09:33:42)
Hors ligne
slt,
c' est pénible quand on fait ce qu' il faut et toujours ce fameux Permission denied (publickey)
oui c'est très pénible d'être bloqué comme ça et de rien pouvoir faire que répéter les commandes...
edit: je comprend que ça ne peut pas marcher en lisant ça:
pour ls -lh /home/user/.ssh/authorized_keys sur le serveur :
-rw------- 1 jeankiki jeankiki 1,5k mai 20 11:32 /home/jeankiki/.ssh/authorized_keys
le fichier authorized_keys n' appartient pas au user mais à root, il contient la clé publique
la clé privée se trouvant évidemment chez le client dans /home/user/.ssh/nom_que_tu_lui_as_donné (par défaut id_rsa)
ah c'est intéressant ça. Une info que je ne savais pas (ou que je n'ai pas vu). Je vais essayer ce soir. Du coup c'est un "chown root:root ~/.ssh/authorized_keys" sur le serveur ?
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hum.
Je déconseille fortement la solution à base de « /authorized_keys ». Elle ne respecte pas le standard de rangement du système de fichier, stocke des données personnelles sur la partition racine et passe très mal au multi-utilisateur.
Personnellement, je ne désactive pas PAM pour interdire le login par mot de passe, et je crains que déactiver PAM ne change d'autres choses...
captnfab, que risque t' il de se passer si le fichier authorized_keys est directement sur la racine ? je veux bien suivre ton conseil de le remettre dans un répertoire mais j' aimerais en connaître l' explication technique exacte. (ça fait pourtant 2 ans qu' il tournait ainsi sans problème)
@jean_kiki: pour désactiver le login par mot de passe, tu modifies la ligne en PasswordAuthentication no dans sshd_config.
Hors ligne
côté serveur. On à pu voir que lors de l’authentification il va chercher le ~/.ssh/authorized_keys dans root ! sauf que root n'a même pas de fichier .ssh parce-que ssh est installé et tourne côté utilisateur. c'est donc le ~ qui est ambiguë. Quand je mets le chemin complet /home/jeankiki/.ssh/authorized_keys (dans mon cas) et bien ça marche !
le problème avec ça m'a t-on expliqué c'est que si je crée plusieurs utilisateurs ssh ne va pas chercher dans leur /.ssh/authorized_keys à eux mais qu'il faudra les rajouter dans mon fichier de mon user. Vu que c'est un serveur perso c'est pas grave, mais c'est pas top non plus. J'ai donc retrouvé et remis l'option par défaut %h/.ssh/authorized_keys et à nouveau ça marche !!!
je sais pas trop ou j'ai fais la boulette mais je crois ça viens de mon inexpérience du fichier /etc/ssh/sshd_config au début. En y repensant j'avais peut-être pas décommenter le AuthorizedKeysFile, puis comme je connaissais pas et ne voyais pas l’intérêt du %h j'ai mis un ~ en décommentant. Peut-être aussi le PAM à son rôle à jouer et donc mieux vaut ne pas y toucher (et juste mettre PasswordAuthentication à no
@nikau : merci beaucoup pour ton partage. Le seul truc c'est que je préfère le faire fonctionner comme c'est censé fonctionner sans devoir bidouiller (et avec root on voit souvent des mises en garde). déjà je regrette d'avoir bidouillé les droits des fichiers, m'enfin ça je m'en sors plus.
@captfab : merci pour les commandes de vérification des droits sur les fichiers ça va me resservir et merci tout cours.
je me tâte à purger tout ça pour recommencer l'install ssh-server et voir si je m'en sors maintenant que j'ai mieux compris
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
captnfab, que risque t' il de se passer si le fichier authorized_keys est directement sur la racine ? je veux bien suivre ton conseil de le remettre dans un répertoire mais j' aimerais en connaître l' explication technique exacte. (ça fait pourtant 2 ans qu' il tournait ainsi sans problème)
Plusieurs choses
D'abord, il n'y a qu'un seul fichier authorized_keys pour tous les users, donc si tu ajoutes une clé pour l'utilisateur « tartampion », ça ajoute aussi la clé pour root, et donc tartampion peut se logguer en root avec sa clé.
Ensuite, si tu fais une réinstallation en ne sauvegardant que le /home alors ton fichier est perdu, alors qu'il s'agit de données utilisateurs
Finalement, tu as contourné un problème sans le comprendre, il est possible que ce faisant tu passes à côté d'une faille de sécurité liée à un pb de configuration (c'est le cas ici, cf. 1) )
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dernière modification par nikau (22-05-2013 11:09:46)
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne
c'est intéressant votre discussion ça confirme (et ça m'explique) le fonctionnement de ssh et ce que je pensais...
il faut suivre les conseils du capitaine, en effet c' est mieux que chaque user possède son propre authorized_keys dans son répertoire .ssh respectif avec un chmod 700
cela permet de faire un nouveau jeux de clé si un utilisateur en fait la demande.
Hors ligne
-je copie ma clef dans ~/.ssh/authorized_keys via :
-je modifie sur le serveur quelques entrées de /etc/ssh/sshd_config comme suit :
# Authentification:
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys (je décommente, même si je crois ce n'est pas nécessaire car c'est le comportement par défaut)
PasswordAuthentication no
-je tente
et là : ça marche pas-> Permission denied (publickey) hum...
-je tente
et là : ça marche ouf
donc en gros si je comprend bien il faut quand même préciser quelle clef on veux utiliser pour se connecter ainsi à ssh !
du coup j'ai réussi à créer un fichier config comme suit :
Host nom_du_serveur
HostName adresse_ip_serveur
User nom_de_l'utilisateur_à_contacter_sur_le_serveur
Port 22 (ou autre si modifié dans /etc/ssh/sshd_config)
IdentityFile ~/.ssh/nom_de_la_clef
et là si je fais un
et bien ça marche
Si je peux me permettre de suggérer, dans le wiki http://debian-facile.org/doc:reseau:ssh est-ce qu'il ne serait pas utile de préciser de se connecter avec ssh -i ~/.ssh/ma_clef utilisateur@ip_serveur dans le cas d'une connexion par clefs (ssh utilisateur@ip ne fonctionnant qu'avec l'authentification par mot de passe). Et également de rajouter un encart ou exemple de fichier config tellement utile pour se simplifier la vie...
Je ne sais pas si c'est chez tout le monde pareille, mais j'ai essayé de rester le plus proche possible de la configuration par défaut...si jamais ça peut servir (en tout cas ça m'aurait bien servi lol )
rappel de ma biblio :
http://debian-facile.org/doc:reseau:ssh
http://doc.ubuntu-fr.org/ssh
http://doc.fedora-fr.org/wiki/SSH_:_Aut … e_cl.C3.A9
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Merci, c'est tout à fait comme ça que je le voulais ! Crois-tu qu'il faille beaucoup de ressources à ce mouton ? Parce que ma config est toute petite...
Ça devrait aller. Tu peux te compiler un petit mouton.
Pas si petit que ça. Tiens ! il s'est mis en veille...
Hors ligne