[RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

Yop69 · Le 08/03/2010, à 20:54

Bonsoir,

Voila, je souhaite avoir une commande (un rsync pépiote) dans un fichier .sh qui devra pas me demander de mot de passe quand elle se connectera en ssh sur mon serveur.
J'ai donc créé la paire de clé, copié la clé public sur le serveur. Mais j'essaie en vain de me connecter sur mon serveur et j'ai toujours une demande de mot de passe

Pouvez vous m'aider ? A savoir que j'ai fait un verbose de la connexion ssh (mais je ne comprends pas tout)

http://www.yionel.fr/pastebin/index.php/view/17962863

Merci beaucoup pour votre aide !

Dernière modification par Yop69 (Le 08/03/2010, à 23:21)

mallain · Le 08/03/2010, à 21:18

Bonsoir,

Afin de répondre au mieux à ta demande. Imaginons la situation suivante.

J'ai 2 éléments actifs

* Mon serveur identifié "serveur"
* Un poste local identifié "local"

Sur mon serveur, mon utilisateur s'appelle "user_server" sur mon poste local "user_local"

Je possède sur mon poste "local" une clé ssh. Elle se situe dans /home/user_local/.ssh/
2 fichiers sont présents.

* /home/user_local/.ssh/id_rsa : Clé privée qui doit resté sur le poste client
* /home/user_local/.ssh/id_rsa.pub : Clé publique qui peut être "diffusé"

Côté serveur

Première chose, configurons notre serveur SSH afin d'autoriser la connexion avec une clé SSH.
Pour se faire, on édite le fichier /etc/ssh/sshd_config, et on supprime le commentaire concernant la ligne "AuthorizedKeysFile"

user_server@server:~$ vi /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Maintenant que c'est fait, nous "rechargerons" la configuration du serveur SSH, à travers cette commande.

sudo /etc/init.d/sshd reload

Côté client

Nous allons copier le contenu de notre clé publique dans le presse papier, et le déposer dans le fichier /home/user_server/.ssh/authorized_keys

On affiche le contenu de notre clé publique sur notre pc local.

cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAud+6+pkwOl9Lz6hCy0cR7TpFHb133hiMAex5m1oIu6ZcR+IshItr86qh8BRb5eWcv2o7wusNYPZOcgRw6ezrezrezrezr17MSnFx1NQRLWcsKAGqadanbzylBhv038zwv8pBj6T94V61jqq8WNQpGsm7aucztikeLqoSpK9KuS441bN8R/sdfsdfsdf8FBLefmMYzDdEh2CLDSTqkcpJ1jdw/50lFr9fwKFUkmQmhkbL88qY01GbVt9aQpPgYnyDc5TC2j/mjnGnfsdfsdfLDqgw+NFlCxTNzZfSkLLIopoepQ91/Gf7agvFDAkYaENKP/C80DukQDAjJKCK3BxyYG4wLIaFURFUBqyUAX8ainH/WX/ohI3pa7UAMKRVZg0bPJ+bQOeSaLjWlb/FfsEHmW5fiJXapI91xT7+9O6+VCPsdfsdsdfsdfsdfsdfNRyAcUF+YNbIpuyKdiYZf3At6uwDv5UQOd3s83N6DgfeB22ShpZUbQPXMpfz/Dqy9F5QZPeaVU+OI9K3pl4OBeAwFRXYa51idoPGAIrhMRzf8W3nrOSo5uNpIdRu+63zZAjj5zF5845FGDFGzACcab+GqW9pwqBQY91ftDGNe4SAvcDTkGl0G9s= user_local@local

Je sélectionne le texte, et j'édite le fichier /home/user_server/.ssh/authorized_keys du serveur afin d'y insérer le contenu du presse papier.

vi /home/user_server/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAud+6+pkwOl9Lz6hCy0cR7TpFHb133hiMAex5m1oIu6ZcR+IshItr86qh8BRb5eWcv2o7wusNYPZOcgRw6ezrezrezrezr17MSnFx1NQRLWcsKAGqadanbzylBhv038zwv8pBj6T94V61jqq8WNQpGsm7aucztikeLqoSpK9KuS441bN8R/sdfsdfsdf8FBLefmMYzDdEh2CLDSTqkcpJ1jdw/50lFr9fwKFUkmQmhkbL88qY01GbVt9aQpPgYnyDc5TC2j/mjnGnfsdfsdfLDqgw+NFlCxTNzZfSkLLIopoepQ91/Gf7agvFDAkYaENKP/C80DukQDAjJKCK3BxyYG4wLIaFURFUBqyUAX8ainH/WX/ohI3pa7UAMKRVZg0bPJ+bQOeSaLjWlb/FfsEHmW5fiJXapI91xT7+9O6+VCPsdfsdsdfsdfsdfsdfNRyAcUF+YNbIpuyKdiYZf3At6uwDv5UQOd3s83N6DgfeB22ShpZUbQPXMpfz/Dqy9F5QZPeaVU+OI9K3pl4OBeAwFRXYa51idoPGAIrhMRzf8W3nrOSo5uNpIdRu+63zZAjj5zF5845FGDFGzACcab+GqW9pwqBQY91ftDGNe4SAvcDTkGl0G9s= user_local@local

Maintenant, (normalement) en faisant ssh user_server@server, je serai connecté sans mot de passe sur le serveur.

En espérant avoir su t'aiguiller.

Mickaël.

Yop69 · Le 08/03/2010, à 21:52

Merci beaucoup pour ton aide, malheursement j'en suis au même point
J'ai décommenter
AuthorizedKeysFile %h/.ssh/authorized_keys
Je pensais que c'était ça mais non, il me demande toujours mon mot de passe :'(

Gage · Le 08/03/2010, à 22:14

Dans ton fichier /etc/ssh/sshd_config, vérifie les méthodes autorisées. Si l'authentification par mot de passe est possible, normal qu'il commence par te demander ton mot de passe. En plus, pour peu que ton mot de passe ne soit pas follement solide, c'est une sacrée grosse faille.
En exemple, mon fichier de configuration :

gage@Monordi $: cat /etc/ssh/sshd_config
#	$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/bin:/bin:/usr/sbin:/sbin

# 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            # Pense à désactiver le protocole 1, il est obsolète et ne devrait plus être utilisé que si on n'a pas le choix (genre quand on se connecte depuis une très vieille machine pas à jour).

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

# Authentication:

LoginGraceTime 2m
PermitRootLogin no                  #Comme ça, tu es sûr qu'aucun petit malin ne tentera de pirater ton compte root. Enfin, encore faudrait-il qu'il ait la clef.
#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 no                        # C'est là que ça se passe
PermitEmptyPasswords no                         # Ça évite de te faire pirater un compte qui ne serait pas pourvu de mot de passe. Genre le compte root sous Ubuntu. Bon, en fait on s'en fiche parce que l'authentification par mot de passe est interdite. Note que si cette option a été réglée à "yes" par le passé, avec l'authentification par mot de passe activée et un routeur qui redirigeait le port 22 vers ton serveur, ta machine est, à l'heure actuelle, foutue et tu n'as plus qu'à réinstaller le système.

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

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

# GSSAPI options
#GSSAPIAuthentication no
#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 yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#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/lib/ssh/sftp-server

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

Par ailleurs, une façon assez simple de mettre ta clé sur l'ordinateur serveur sans te fatiguer consiste à exécuter :

ssh-copy-id -i ma_clé.pub mon_login@mon_serveur

Le serveur va alors te demander le mot de passe, tu le donnes, puis côté serveur, tu actives l'authentification par clé et désactives celle par mot de passe.

Dernière modification par Gage (Le 08/03/2010, à 22:23)

nesthib · Le 08/03/2010, à 22:25

tu peux désactiver l'authentification par clé en modifiant ce paramètre dans le fichier de configuration de sshd (/etc/ssh/sshd_config sur le serveur)

PasswordAuthentication no

puis relance le serveur ssh

sudo /etc/init.d/ssh restart

si cela ne fonctionne pas poste le contenu de ton fichier de config

Yop69 · Le 08/03/2010, à 22:33

Gage> Le problème c'est que mon serveur je l'attaque de l'extérieur sur différents pc que je ne connais pas forcément . Donc mot de passe obligé et crois moi ya pas de faille car c'est un sacré mot de passe.
Je ne peux donc pas désactiver l'authentification par mot de passe

et oui la commande ssh-copy-id c'est celle que j'ai faite (avec "-p xxx user@ip" )

nesthib> Pourquoi désactiver l'authentification par clé ? c'est ce que je veux

Voici mon fichier sshd_config :
http://www.yionel.fr/pastebin/index.php/view/63145141

nesthib · Le 08/03/2010, à 22:44

@Yop69 : ben justement si tu comprends un minimum l'anglais password = mot de passe
essaie et tu verras, plus de possibilité d'authentification par mot de passe mais l'authentification par clé reste toujours possible.

ou alors tu as mal formulé ta question, peut-être as-tu affecté une passphrase à ta clé auquel cas il est normal de devoir l'entrer pour la déverrouiller

Gage · Le 08/03/2010, à 22:53

Sinon, une autre possibilité, que je n'ai pas essayée chez moi, donc je ne fais que décrire sans avoir testé, est de désactiver l'authentification par mot de passe au niveau de l'ordi où tu as une clé. Ça se passe dans ton fichier ~/.ssh/ssh_config :

PasswordAuthentification no

nesthib · Le 08/03/2010, à 23:04

^^ un poil en retard Gage

NB. moi j'ai testé et ça fonctionne parfaitement

Gage · Le 08/03/2010, à 23:18

Non, parce que toi tu proposes de désactiver l'authentification pas mot de passe sur le serveur, ce qui aboutirait à refuser toute authentification par mot de passe (enfin, c'est ce qu'il a compris. En fait, tu lui donnais déjà le choix, mais ça n'était pas d'une clarté limpide ). Moi, je propose de la désactiver sur les postes clients où il y a une clef.

Mais, à la réflexion, ça ne devrait rien résoudre. En effet, par défaut, ssh essaie l'authentification par mot de passe en dernier recours, seulement après avoir essayé les autres méthodes, notamment l'authentification par clef. Je pense donc à un problème de l'authentification par clef.

Peux-tu donc poster les retours de :
Côté serveur :

cat /etc/ssh/sshd_config
cat $HOME/.ssh/authorized_keys

Et côté client :

cat /etc/ssh/ssh_config
cat $HOME/.ssh/ssh_config
cat $HOME/.ssh/id_rsa.pub
cat $HOME/.ssh/known_hosts

Le tout entre des balises code (une par fichier, c'est plus simple à lire), afin que ça soit accessible sans passer par un énième pastebin qui applique une coloration syntaxique foireuse parce qu'il croit que c'est du bash.

Dernière modification par Gage (Le 08/03/2010, à 23:20)

Yop69 · Le 08/03/2010, à 23:21

j'ai trouvé \o/ \o/

cela venait des droits du fichiers authorized_keys sur le serveur qui doit etre a 600 alors que moi il appartenait à root avec des droits foireux.

Je suis super content ^^

Merci à vous !!

Gage · Le 08/03/2010, à 23:22

Ah bah forcément, si tu interdis à ssh de lire les clés autorisées, faut pas s'attendre à ce qu'il les trouve... .

Yop69 · Le 08/03/2010, à 23:44

Gage a écrit :

Le tout entre des balises code (une par fichier, c'est plus simple à lire), afin que ça soit accessible sans passer par un énième pastebin qui applique une coloration syntaxique foireuse parce qu'il croit que c'est du bash.

Euh c'est surtout moi qui me suis vautré en lui disant que c'est du bash

Gage · Le 08/03/2010, à 23:57

Bien, tu seras donc fouetté.

mallain · Le 09/03/2010, à 18:10

Re,

Je viens de publier un petit billet à ce sujet sur mon blog. [url=http://[Merci de relire les règles]/cb9Qu0]Authentification SSH sans mot de passe avec une clé SSH de type RSA[/url]

En y insérant un petit clin d'œil à Yop69 pour le coup des droits ;-)

Bonne continuation à tous.

Mickaël.

Yop69 · Le 09/03/2010, à 19:28

:-) cool

lalounator · Le 14/03/2011, à 23:42

Yop69 a écrit :

cela venait des droits du fichiers authorized_keys sur le serveur qui doit etre a 600 alors que moi il appartenait à root avec des droits foireux.

mec tu viens de me sauver la life, j'avais exactement le même problème que je viens de résoudre

béni soit ce forum et ses utilisateurs
béni soit GNU/Linux

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/03/2010, à 20:54

[RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#2 Le 08/03/2010, à 21:18

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#3 Le 08/03/2010, à 21:52

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#4 Le 08/03/2010, à 22:14

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#5 Le 08/03/2010, à 22:25

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#6 Le 08/03/2010, à 22:33

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#7 Le 08/03/2010, à 22:44

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#8 Le 08/03/2010, à 22:53

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#9 Le 08/03/2010, à 23:04

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#10 Le 08/03/2010, à 23:18

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#11 Le 08/03/2010, à 23:21

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#12 Le 08/03/2010, à 23:22

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#13 Le 08/03/2010, à 23:44

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#14 Le 08/03/2010, à 23:57

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#15 Le 09/03/2010, à 18:10

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#16 Le 09/03/2010, à 19:28

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

#17 Le 14/03/2011, à 23:42

Re : [RESOLU] ssh et clé. Je ne veux pas de mot de passe grrr

Pied de page des forums