Je
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ AVERTISSEMENT: FICHIER DE CLÉ PRIVÉE NON PROTÉGÉ! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Les autorisations 0644 pour '/Users/Cody/.ssh/blue_gum.pub' sont trop ouvertes.j'ai fait
chmod 600 ~/.ssh/blue_gum.pubet maintenant je reçois la fenêtre contextuelle (utilisant mac os x mavericks) pour entrer le mot de passe de la clé SSH, je n'en ai pas donc j'ai laissé vide et ensuite je reçois
Permission refusée (clé publique).Les clés ont été copiées dans le fichier authorized_keys sur le serveur en utilisant
scp ~/.ssh/blue_gum.pub cody@10.0.0.10:~/.ssh/authorized_keysJ'ai également essayé chmod 600 avant le scp vers le serveur et le même problème se produit.
Je me suis assuré que .ssh sur le client et le serveur avaient des autorisations 700 et que tous les fichiers à l'intérieur avaient 600. Le même problème persiste. Je vais essayer la méthode de dépannage décrite ci-dessous. Voici aussi mon sshd_config si cela aide en quoi que ce soit :
# Fichier de configuration généré par le paquet
# Voir la page manuel de sshd_config(5) pour plus de détails
# Ports, IPs et protocoles sur lesquels nous écoutons
Port 22
# Utilisez ces options pour restreindre les interfaces/protocoles auxquels sshd s'attachera
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocole 2
# Clés hôtes pour la version du protocole 2
CléHôte /etc/ssh/ssh_host_rsa_key
CléHôte /etc/ssh/ssh_host_dsa_key
CléHôte /etc/ssh/ssh_host_ecdsa_key
# Séparation de privilèges activée pour la sécurité
UtiliseSéparationPrivilèges oui
# Durée de vie et taille de la clé serveur éphémère de version 1
IntervalleRégénérationClé 3600
BitsCléServeur 768
# Journalisation
FacilitéSyslog AUTH
NiveauJournal INFO
# Authentification :
TempsGrâceConnexion 120
ConnexionAutoriséePasRoot non
ModesStrict oui
AuthentificationRSA oui
AuthentificationPublique oui
FichierClésAutorisées %h/.ssh/authorized_keys
# Ne lit pas les fichiers ~/.rhosts et ~/.shosts de l'utilisateur
IgnoreFichiersRhosts oui
# Pour que cela fonctionne, vous aurez également besoin des clés hôtes dans /etc/ssh_known_hosts
AuthentificationRhostsRSA non
# similaire pour la version du protocole 2
AuthentificationBaséeHôte non
# Décommentez si vous ne faites pas confiance à ~/.ssh/known_hosts pour l'authentification RhostsRSA
IgnorerKnownHostsUtilisateur oui
# Pour autoriser les mots de passe vides, changez en oui (NON RECOMMANDÉ)
AutoriseMotsDePasseVides non
# Changez en oui pour activer les mots de passe par challenge-réponse (attention aux problèmes avec
# certains modules PAM et les threads)
AuthentificationChallengeRéponse non
# Changez en non pour désactiver les mots de passe en clair tunnelisés
AuthentificationMotDePasse oui
# Options Kerberos
#AuthentificationKerberos non
#ObtientJetonAFSKerberos non
#KerberosOuAuthentificationLocale oui
#NettoyageTicketKerberos oui
# Options GSSAPI
#AuthentificationGSSAPI non
#NettoyageCrédentielsGSSAPI oui
TransfertX11 oui
DécalageAffichageX11 10
AfficherMotd non
AfficherDernierJournal oui
MaintienConnexionTCP oui
#UtiliseConnexion non
#MaxDéparts 10:30:60
#Bannière /etc/issue.net
# Permet au client de transmettre les variables d'environnement de locale
AccepterEnv LANG LC_*
Sous-système sftp /usr/lib/openssh/sftp-server
# Réglez ceci sur 'oui' pour activer l'authentification PAM, le traitement du compte,
# et le traitement de la session. Si cela est activé, l'authentification PAM sera
# autorisée à travers l'authentificationChallengeRéponse et
# AuthentificationMotDePasse. Selon votre configuration PAM,
# l'authentification PAM via l'authentification par challenge-réponse peut contourner
# le réglage de "AutoriseConnexionRoot sans-mot-de-passe".
# Si vous voulez juste que les vérifications de compte et de session PAM s'exécutent sans
# authentification PAM, alors activez ceci mais réglez AuthentificationMotDePasse
# et AuthentificationChallengeRéponse sur 'non'.
UtilisePAM oui
IgnorerKnownHostsUtilisateur non
AuthentificationMotDePasse non
