Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Probleme connexion ssh clé publique / privée

totosh

Bonjour,

Voila, je suis entrain de réalisé un pti pour mon bts ig sous Fedora dans le but d'établir une connexion ssh avec clé publique / privée sur un serveur.
Je réalise le pti pour l'instant avec des machines virtuelles avec Fedora 13 ou j'ai effectué toutes les mises à jour.

J'ai donc suivi le tuto http://doc.fedora-fr.org/wiki/SSH_:_Authentification_par_cl%C3%A9 ici.
La connexion ssh sans clé fonctionne mais avec les clés ca bug :s
J'ai créé les clé sur le client, puis envoyé la clé publique sur le serveur que j'ai inséré dans authorized_keys situé dans le répertoire /home/userssh/.ssh/
Je modifie ensuite l'option PasswordAuthentication en no et reboot le service sshd.

Cependant quand je souhaite me connecté avec le client, j'ai l'accès refusé > Permission denied (publickey, gssapi-keyex, gssapi-with-mic)

Si quelqu'un peut m'aider, merci d'avance.

Edit: ssh -v userssh@192.168.1.11

OpenSSH_5.4p1, OpenSSL 1.0.0b-fips 16 Nov 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.11 [192.168.1.11] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.11' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: totosh@totosh06
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

serveur:
Droit /.ssh/ > 700 userssh userssh
Droit authorized_keys > 664 userssh userssh

Difool

Quel type de clé as-tu généré ? RSA ou DSA ?
Edit : D'après le log, les deux ont été généré mais laquelle utilise-tu ? Laquelle est copiée dans le authorized_keys du serveur ? As-tu essayé avec l'autre ?

Y'a moyen de voir ton /etc/ssh/sshd_config ?

Par ailleurs, désactiver le login par mot de passe n'est pas nécessaire. C'est peut-être d'ailleurs sûrement pas préférable, tant que le login par clé ne fonctionne pas ...

totosh

Au départ, j'ai réalisé une clé DSA 1024b avec passphrase, vu que cela n fonctionnait pas, je l'ai supprimé et testé sans passphrase mais même résultat.
J'ai donc supprimé de nouveau et réalisé clé RSA sans passphrase et toujours pareil.

Voici le know_hosts

192.168.1.11 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCi/TI9ycA+LTSmBBXF7YlXGh/YPb0f9k4aIEvBbMGSuPkyMuN89mXMHZBQUB7mNlBa5pWvRHXkS0b6z+ERUKxG332gMYQaGeDekHmQP5c/vwViwwnx840pK0vb06hbTTbBK+pLD/bXVDC94oYTSCCZpzqt4CoWHH3oNwddRbmNPoAVxuE4Cl/r0JWsgaZjvD1P4kUE6eNiJEpdb0qIjzHJt5uZZCeEsa421bPBOD0ZWsCfvDeKL4MQ2BU6V5l9nlW/060Q0lAxKDiw0VvuR+I8ggBHEA7tSR/eTbEyPHR+taiUbwXg9Jw/EuAabpoBRuSZudqKVvmGUeksG7SCVXmT

et id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPBDADWZ8Kce+abGr0lgn49LSzCDohq1u8CDPAGXnoUfIcmEYT4jpAGFc02w9waCep0elXy9jGrgqzSI7H/k4ICBNRwNAZxin5vYCGfTJa6lZwSgzudJeG7YWBRsxOUOuDje9oHeRIFiJr7vIiUqCwdPt+CmF1uCJT9qFPVm8zlhFeRjqLI0cnVAQdmbTI8gGPNiPdTobiBcc+X4BeN/gs4CiBk+t2L1tmkG53xB/SANGfqX/F3rAYfzMD/7jeSIoPWG1kwwKKo+oZCH//1DifVbJg3V2akX+OBoxtPZyAuUywQr7gWBvLAK3PGIUBhgcJ

Sinon pour l'option du mot de passe, ba lorsqu'il est activé je peux me connecter si je saisi le password, donc si je désactive pas, je peux savoir comment que m'a clé fonctionne?

PS: je vois que les deux clé ne sont pas pareil dans id_rsa.pub et know_hosts, normal?

Difool

totosh wrote: Sinon pour l'option du mot de passe, ba lorsqu'il est activé je peux me connecter si je saisi le password, donc si je désactive pas, je peux savoir comment que m'a clé fonctionne?

Ben l'auth par mot de passe vient après celle par clé donc s'il te demande le mot de passe, c'est que la clé ne fonctionne pas.

totosh wrote: PS: je vois que les deux clé ne sont pas pareil dans id_rsa.pub et know_hosts, normal?

Oui, dans know_hosts, c'est une clé pour identifier la machine, me semble (histoire d'éviter les mauvaises surprises).
Dans le doute, tu peux supprimer/renommer ce fichier, il sera recréé.

totosh

Ok sinon tu as une idée d'ou peut venir le problème de clé?

Difool

Que contient /home/userssh/.ssh/authorized_keys sur la machine 192.168.1.11 ?

cat /home/userssh/.ssh/authorized_keys

Quand tu as regénéré un couple de clés, tu es sûr d'avoir supprimé les bonnes ? Tu n'aurais pas conservé une clé publique qui ne correspondrait pas à une clé privée ?

Quels sont les droits du répertoire ~/.ssh et des clés publiques sur la machine client ?

ls -la ~/.ssh

SkyR713

Les droits 664 sur ton authorized_keys sont incorrects je pense, essaye en 600 pour voir.

totosh

voila les droits sur .ssh sur le client

drwx------ 2 totosh totosh 4096  2 déc.  21:27 .ssh/

Et le contenu de authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPBDADWZ8Kce+abGr0lgn49LSzCDohq1u8CDPAGXnoUfIcmEYT4jpAGFc02w9waCep0elXy9jGrgqzSI7H/k4ICBNRwNAZxin5vYCGfTJa6lZwSgzudJeG7YWBRsxOUOuDje9oHeRIFiJr7vIiUqCwdPt+CmF1uCJT9qFPVm8zlhFeRjqLI0cnVAQdmbTI8gGPNiPdTobiBcc+X4BeN/gs4CiBk+t2L1tmkG53xB/SANGfqX/F3rAYfzMD/7jeSIoPWG1kwwKKo+oZCH//1DifVbJg3V2akX+OBoxtPZyAuUywQr7gWBvLAK3PGIUBhgcJL/DVIaj98npObSHx5eTj totosh@totosh06

Difool

Ce n'est pas la même clé que tu as collé précédemment ...

Donc mets la bonne clé dans le authorized_keys et réessaie.

totosh

Dsl j'ai du faire une un moment, j'ai bien remis la bonne clé dans authorized_keys mais ca ne marche pas encore

authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCXib2vKOWl3rk5tR87vdawbc/OTobSC07nuCIc3IA0em5GTziEusxdtEhtBrzuT/ATLsU5EKSpM3ag9nPKUv3K+dnJxlnaxtaYFME0xYQ2JgaiL/RAvPv9QqTHxvtmg/2Vf88zMrcH0nkPIUIEBY4JUCv5G46s+aiR+jCNNz8GinOMGQewvM3IIxQPlcnGrl3U2QaFm0WfiDjZfZYCRjSPJRwa7KEXBLuDqDzPEduZafMNIJhj58jE4G4E8dScN4fz3KrSwpcsSPpTwOlGr0zt/dW1RdOujvaK1t29PaZa63R54cEucM657OUlT/mcEq5YeEWvKth0YVswffLX5cgN totosh@totosh06

id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCXib2vKOWl3rk5tR87vdawbc/OTobSC07nuCIc3IA0em5GTziEusxdtEhtBrzuT/ATLsU5EKSpM3ag9nPKUv3K+dnJxlnaxtaYFME0xYQ2JgaiL/RAvPv9QqTHxvtmg/2Vf88zMrcH0nkPIUIEBY4JUCv5G46s+aiR+jCNNz8GinOMGQewvM3IIxQPlcnGrl3U2QaFm0WfiDjZfZYCRjSPJRwa7KEXBLuDqDzPEduZafMNIJhj58jE4G4E8dScN4fz3KrSwpcsSPpTwOlGr0zt/dW1RdOujvaK1t29PaZa63R54cEucM657OUlT/mcEq5YeEWvKth0YVswffLX5cgN totosh@totosh06

know_hosts

192.168.1.11 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCi/TI9ycA+LTSmBBXF7YlXGh/YPb0f9k4aIEvBbMGSuPkyMuN89mXMHZBQUB7mNlBa5pWvRHXkS0b6z+ERUKxG332gMYQaGeDekHmQP5c/vwViwwnx840pK0vb06hbTTbBK+pLD/bXVDC94oYTSCCZpzqt4CoWHH3oNwddRbmNPoAVxuE4Cl/r0JWsgaZjvD1P4kUE6eNiJEpdb0qIjzHJt5uZZCeEsa421bPBOD0ZWsCfvDeKL4MQ2BU6V5l9nlW/060Q0lAxKDiw0VvuR+I8ggBHEA7tSR/eTbEyPHR+taiUbwXg9Jw/EuAabpoBRuSZudqKVvmGUeksG7SCVXmT

sshd.config

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile    .ssh/authorized_keys
#PubkeyAgent none
#PubkeyAgentRunAs nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

#PermitEmptyPasswords no
PasswordAuthentication yes 

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    ForceCommand cvs server

commande ssh -v userssh@192.168.1.11

OpenSSH_5.4p1, OpenSSL 1.0.0b-fips 16 Nov 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.11 [192.168.1.11] port 22.
debug1: Connection established.
debug1: identity file /home/totosh/.ssh/id_rsa type 1
debug1: identity file /home/totosh/.ssh/id_rsa-cert type -1
debug1: identity file /home/totosh/.ssh/id_dsa type -1
debug1: identity file /home/totosh/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.11' is known and matches the RSA host key.
debug1: Found key in /home/totosh/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: /home/totosh/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/totosh/.ssh/id_dsa
debug1: Next authentication method: password

Difool

Je vois pas trop, désolé.
Par contre, tu peux virer le contenu de id_rsa du forum. Ou alors, faudra changer de clé quand ça marchera.

SkyR713

ssh-copy-id userssh@192.168.1.11

ça devrait copier la clé au bon endroit

sinon

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex

m'étonne, on dirait qu'il n'essaye pas la méthode d'authentification par clef

Difool

Il essaye, mais après.

totosh

Sur le client je suis sous l'utilisateur totosh et je lance le ssh userssh@192.168.1.11
Je dois pas avoir le même compte? j'espere pas sinon je vois pas trop l'utilité^^

Sur le serveur: la clé publique doit etre dans le home de userssh ou celui de root?
je l'ai mis dans root aussi et j'ai ca:

debug1: Next authentication method: publickey
debug1: Offering public key: totosh@totosh06
debug1: Server accepts key: pkalg ssh-rsa blen 279
Agent admitted failure to sign using the key.
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: password

avec dans le sshd.config du serveur cette ligne

AuthorizedKeysFile    .ssh/authorized_keys

Difool

totosh wrote:Sur le client je suis sous l'utilisateur totosh et je lance le ssh userssh@192.168.1.11
Je dois pas avoir le même compte? j'espere pas sinon je vois pas trop l'utilité^^

Rien compris.
userssh est bien un utilisateur de ta machine ?
Pourquoi tu ne te connectes pas avec totosh ?

totosh wrote: Sur le serveur: la clé publique doit etre dans le home de userssh ou celui de root?

Dans le ~/.ssh/ de l'utilisateur sous lequel tu veux te connecter. Donc si tu lances ssh userssh@ip, il faut que ce soit dans le home de userssh.

totosh

Ok bon la connexion fonctionne!!!
Alors d'un je pense que SeLinux bloquait la comparaison de clé, j'avais stop SeLinux mais pas reboot les machines.

Après comment j'ai trouvé: un moment j'étais resté en root sur le client et j'ai réalisé une connexion ssh avec, et la message de SeLinux sur le serveur!! que j'avais pourtout désactivé j'ai donc reboot les deux machines et ca fonctionne.

Edit: Enfaite ma machine client possède le compte "totosh" seulement et je souhaite me connecter sur le serveur avec cette machine mais pas ce compte. Et le serveur lui possède le compte userssh seulement.

Edit2: je vais refaire tout au propre avec une clé DSA 1024 et passphrase pour + de sécurité et une pti plus complet.

Difool

Ok. Qu'est-ce qu'il te voulait, SeLinux ? Histoire de pouvoir mettre à jour la doc à ce sujet.

C'est quoi une « pti », au fait ?

totosh

Un pti, c'est un projet informatique.
Je dois en réaliser 5 pour l'examen du BTS informatique de gestion.

SeLinux m'a afficher un message comme quoi il a bloqué la demande de lecture sur le fichier /.ssh/authorized_keys. Mais étrange que ca me l'a pas fait avant 🙁
Donc il faut bien désactiver Selinux sur les deux postes pour avoir aucun problème. j'ai fais de même pour le pare-feu.

Je viens de le refaire avec une clé DSA 1024b avec passphrase et ca fonctionne, il reste plus qu'a test avec un client xp puis de compléter avec ssh-agent

Difool

totosh wrote: SeLinux m'a afficher un message comme quoi il a bloqué la demande de lecture sur le fichier /.ssh/authorized_keys. Mais étrange que ca me l'a pas fait avant 🙁
Donc il faut bien désactiver Selinux sur les deux postes pour avoir aucun problème. j'ai fais de même pour le pare-feu.

Ouais, enfin, tu peux chmod 777 / en root, aussi. Ça marchera mais j'suis pas sûr que ce sera aussi sécurisé 😉

Si SeLinux râle, c'est qu'il y a une raison. Probablement une règle à ajouter.
Pour une pti plus complet, comme tu dis, c'est un point à creuser.

Edit : https://bugzilla.redhat.com/show_bug.cgi?id=499343 Tu as probablement le même soucis

totosh

Oui je regarderai ca un peu plus tard quand j'aurai plus le temps de regarder ca.

En tout cas merci pour l'aide, maintenant ca marche niquel avec la clé DSA, et avec ssh agent. Pareil avec putty sur xp, ca passe bien 🙂

Page suivante »