bonjour,
je n'arrive pas à me connecter par échange de clé avec un ordi distant, il me demande toujours le mot de passe voici le log de connection 
ssh host-distant -v
OpenSSH_4.5p1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host-distant [192.168.1.xx] port 22.
debug1: Connection established.
debug1: identity file /home/xxxx/.ssh/identity type -1
debug1: identity file /home/xxxx/.ssh/id_rsa type 1
debug1: identity file /home/xxxx/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 'host-distant' is known and matches the RSA host key.
debug1: Found key in /home/xxxx/.ssh/known_hosts:16
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

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

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

debug1: Next authentication method: publickey
debug1: Trying private key: /home/xxxx/.ssh/identity
debug1: Offering public key: /home/xxxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /home/xxxx/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password
j'ai bien vérifié les chmod 
[user@hote_distant .ssh]$
chmod 700 /home/xxxx/.ssh/ 
[user@hote_distant .ssh]$ chmod 600 /home/xxxx/.ssh/authorized_keys
merci
debug1: Offering public key: /home/xxxx/.ssh/id_rsa
...
debug1: Offering public key: /home/xxxx/.ssh/id_dsa
Tu as une de ces deux cles privees sur ta machine (locale) ?
Difool wrote:
debug1: Offering public key: /home/xxxx/.ssh/id_rsa
...
debug1: Offering public key: /home/xxxx/.ssh/id_dsa
Tu as une de ces deux cles privees sur ta machine (locale) ?
oui
[user@local .ssh]$ ls
authorized_keys    id_dsa.pub  id_rsa.pub   known_hosts
 id_dsa             id_rsa
hum et le contenu de id_dsa.pub de la machine locale est-il bien recopie dans le fichier authorized_keys de la machine distante ?
Vérifie le contenu de authorized_keys, il doit contenir intégralement ta clé publique.
Si tu n'as qu'une clé publique dans authorized_keys fais un sum de ton fichier id_rsa.pub (local) et d'authorized_keys sur ton serveur.

Si tu as saisi une phrase clé lors de la création de ta clé publique, vérifie que ssh.agent est bien lancé.
Bonjour,
suivre le tuto ici la partie sur l'authentification.

S.
Slookeur wrote:Bonjour,
suivre le tuto ici la partie sur l'authentification.

S.
oui c'est ce que je fais à chaque fois mais un moment je ne sais pourquoi mais ça ne marche plus :p
C'est simple : Y'a un truc que t'as loupe.

Vu que tu n'as pas repondu :
Le contenu de ta cle publique id_rsa.pub ou id_dsa.pub a-t-il bien ete recopie dans le fichier authorized_keys de la machine distante ?

La machine distante est-elle configuree pour accepter l'authentification par cle (Sans oublier de recharger la conf ou relancer le serveur SSH) ?
J'imagine que oui, vu qu'elle essaie, mais bon ...
Bonsoir à tous

Je me permet de mettre mon grain de sel dans la conversation car j'ai toujours eu du mal à cerner la notion de machine local et de machine distante.

je m'explique, pour moi, la machine local, c'est le serveur (celui sur lequel on veux avoir accès) et la machine distante c'est le client (le pc que j'utilise pour accéder au serveur).

Ma confusion viens du fait que pour moi une machine locale c'est une machine dont j'ai accès physiquement, a l'opposé de la machine distante.

Donc si je suis avec mon ordinateur portable et veux ouvrir une connexion pour accéder à mon serveur ssh situé ailleurs (distant), la machine local n'est donc plus le serveur mais le portable. Vous saisissez l'ambigüité :-?

Qui est le serveur dans l'histoire ? la machine local ou la machine distante ?

Je ne c'est pas si j'ai été très clair mais je ne vois pas comment le formuler autrement.
Tu te contredis dans tes propos.
La machine locale est effectivement la machine sur laquelle on a forcement un acces physique, contrairement a la machine distante.

La machine locale est donc le client, c'est a dire celle que tu utilises pour te connecter au serveur.
La machine distante est alors le serveur sur lequel tu essaies de te connecter.

Mais ca n'empeche pas que machines locale et distante soient a cote l'une de l'autre et, par consequent, que tu aies un acces physique aux deux 😉

Par contre, je ne comprend pas ca :
tdt29 wrote:je m'explique, pour moi, la machine local, c'est le serveur (celui sur lequel on veux avoir accès) et la machine distante c'est le client (le pc que j'utilise pour accéder au serveur).
Pourquoi cela pour toi ? Puisque tu fais le bon raisonnement ensuite ? O_o
Locale ou distante importe peu pour ssh (et toutes les applications client/serveur) .

Avec ssh, et sshd , le client est celui qui lance le ssh et le serveur est celui sur lequel le démon sshd tourne et accepte des connexions ssh.

Avec http et httpd le client http est le navigateur (Ex:firefox) et le serveur httpd (Ex:Apache)

Si l'authentification ssh ne fonctionne plus, on peut envisager plusieurs hypothèses mail il faut d'abord vérifier le contenu de authorized_keys sur le serveur et la clé publique sur le client.
@Difool
En effet je me suis embrouillé tout seul :roll:

@Difool et pmarion

En tous cas merci pour les précisions
Je ne vous cache pas que je suis plus a l'aise avec les notions client/serveur comme l'explique pmarion plutot que local/distant (même si on est d'accord que c'est la même chose), je trouve ça beaucoup plus parlant. Après c'est surement moi qui , à un moment, ai du rater une subtilité, mais de tout ce que j'ai pu lire lorsque l'on parle de local/distant je ne trouve pas ça clair.

entre
il faut d'abord vérifier le contenu de authorized_keys sur le serveur et la clé publique sur le client.
et
le contenu de id_dsa.pub de la machine locale est-il bien recopie dans le fichier authorized_keys de la machine distante ?
qu'il veulent dire la même chose. La première citation est limpide comme de l'eau de roche, la deuxième est plus ambiguë (A mon sens bien entendu).


Maintenant que nous sommes d'accord sur les termes je sors et je vais suivre ce fil du coin de l'oeil car comme vous pouvez le constater je ne suis pas encore super calé en ssh.

Bonne journée a tous



PS : Wouha Difool tu te couches encore plus tard que moi c'est dingue 8-)
Difool wrote:C'est simple : Y'a un truc que t'as loupe.

Vu que tu n'as pas repondu :
Le contenu de ta cle publique id_rsa.pub ou id_dsa.pub a-t-il bien ete recopie dans le fichier authorized_keys de la machine distante ?

La machine distante est-elle configuree pour accepter l'authentification par cle (Sans oublier de recharger la conf ou relancer le serveur SSH) ?
J'imagine que oui, vu qu'elle essaie, mais bon ...
disons que là je viens encore de reinstaller une machine sous fedora, et sur la nouvelle machine distante ça marche donc ça ne m'avance ps, je ne comprend toujours pas pourquoi cette fonction s'arrete à un moment donné
Si cela fonctionne sur un serveur sshd et pas sur un autre serveur sshd, c'est que le répertoire .ssh présente une différence.

copie le .ssh d'un des deux serveurs sur l'autre dans /tmp et compare les .ssh avec diff.
pmarion wrote:Si cela fonctionne sur un serveur sshd et pas sur un autre serveur sshd, c'est que le répertoire .ssh présente une différence.

copie le .ssh d'un des deux serveurs sur l'autre dans /tmp et compare les .ssh avec diff.
je viens d'effacer le contenu du dossier .ssh de l'ordi distant puis j'ai fait 
ssh-copy-id -i ~/.ssh/id_dsa ordi_distant
et mem resultat aussi en supprimant le dossier
Bonjour,
pmarion wrote:Si cela fonctionne sur un serveur sshd et pas sur un autre serveur sshd, c'est que le répertoire .ssh présente une différence.
copie le .ssh d'un des deux serveurs sur l'autre dans /tmp et compare les .ssh avec diff.
Faux !

Une différence de taille peut exister dans les fichiers '/etc/ssh/sshd_config' et '/etc/ssh/ssh_config' des machines
concernées.
La configuration du serveur 'sshd' dépend du fichier '/etc/ssh/sshd_config'

Freaks s'il te plaît soit plus claire sur ce qui fonctionne et ce qui ne fonctionne pas ..

1) avec ta nouvelle machine locale tu peut te connecter sans mot de passe sur la machine distante ...
... machine distante sur laquelle tu ne peut te connecter depuis ton ancienne machine locale

Pas de soucis avec les fichiers dans '/etc/ssh' de la machine distante.
La connexion avec clef fonctionne sur la machine distante donc les permissions de fichiers
dans le dossier '~/.ssh' sont bonnes, il te faut vérifier sur la machine distante:
- Le contenu du fichier '~/.ssh/authorized_keys' pour la clef de la machine qui n'arrive pas à se connecter.
- Le contenu du fichier '~/.ssh/known_hosts' (supprime le fichier) qui peut avoir conservé de mauvaises informations
sur ta machine locale, comme une première clef de chiffrement de la machine locale, clef qui aurait changée
depuis ... alors conflit et pas de connexion autorisée.

2) avec ton ancienne machine locale tu peut te connecter sans mot de passe sur ta nouvelle machine
distante

- Compare les fichiers '/etc/ssh' de la nouvelle machine locale et ceux de la machine distante.
- Vérifie les permissions des fichiers dans '~/.ssh' sur la machine distante.
- Le contenu du fichier '~/.ssh/known_hosts' sur la machine distante ... cf plus haut.

S.
alors petit récapitulatif j'ai une machine A et une machine B et une machine C
la A c'est mon poste qui à généré une clé SSH
cette clé est copiée via la commande : 
ssh-copy-id -i ~/.ssh/id_dsa machineB
et là ça marche
même commande pour la derniere machine C(sur laquelle j'ai effacé avant le dossier .ssh) 
ssh-copy-id -i ~/.ssh/id_dsa machineC
et là quand je teste de me connecter me demande tout de même mot de passe

voici un ls -al
de machine B 
drwx------  2 user user 4096 aoû  4 13:08 .ssh
de machine C 
drwx------  2 user user      4096 oct 18 14:44 .ssh
etc/ssh machine B 
-rw-------   1 root root 125811 jui 31 12:35 moduli
-rw-r--r--   1 root root   1964 jui 31 12:35 ssh_config
-rw-------   1 root root   3717 jui 31 12:35 sshd_config
-rw-------   1 root root    668 oct  8 20:31 ssh_host_dsa_key
-rw-r--r--   1 root root    590 oct  8 20:31 ssh_host_dsa_key.pub
-rw-------   1 root root    963 oct  8 20:31 ssh_host_key
-rw-r--r--   1 root root    627 oct  8 20:31 ssh_host_key.pub
-rw-------   1 root root   1671 oct  8 20:31 ssh_host_rsa_key
-rw-r--r--   1 root root    382 oct  8 20:31 ssh_host_rsa_key.pub
etc/ssh machine C 
-rw-------  1 root root 132839 nov 20  2007 moduli
-rw-r--r--  1 root root   1955 nov 20  2007 ssh_config
-rw-------  1 root root   3644 nov 20  2007 sshd_config
-rw-------  1 root root    668 aoû  3 23:29 ssh_host_dsa_key
-rw-r--r--  1 root root    590 aoû  3 23:29 ssh_host_dsa_key.pub
-rw-------  1 root root    963 aoû  3 23:29 ssh_host_key
-rw-r--r--  1 root root    627 aoû  3 23:29 ssh_host_key.pub
-rw-------  1 root root   1675 aoû  3 23:29 ssh_host_rsa_key
-rw-r--r--  1 root root    382 aoû  3 23:29 ssh_host_rsa_key.pub
Et des machines A, B, C laquelle est le serveur SSH ? La machine A ?

Accessoirement, créer une clé pour chaque machine, plutôt que la copier, ça ne serait pas mieux ?

Peux-tu montrer le /etc/ssh/sshd_config de la machine distante ?
Difool wrote:Et des machines A, B, C laquelle est le serveur SSH ? La machine A ?

Accessoirement, créer une clé pour chaque machine, plutôt que la copier, ça ne serait pas mieux ?

Peux-tu montrer le /etc/ssh/sshd_config de la machine distante ?
sshd_config machine B ok 
#    $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

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

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require 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 768

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

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile    .ssh/authorized_keys

# 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!
#PasswordAuthentication yes
#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

# 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
#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

# no default banner path
#Banner /some/path

# 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
sshd_config machine C pas ok 
#    $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

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

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require 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 yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile    .ssh/authorized_keys

# 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!
#PasswordAuthentication yes
#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

# 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 

#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
Et quel est le serveur ?
Tu essaies de te connecter sur la machine B et sur la machine C depuis la machine A ?

Euh, sur les deux machines :
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
Faudrait ptet décommenter ça pour que ça fonctionne ?
Mais apparemment, ça fonctionne avec la machine B ...

On peut peut-être utiliser un ~/.ssh/sshd_config ?
Tu peux regarder si tu as ce fichier sur une de tes 2 machines ?