Serveur ssh sans mot de passe

Support Debian
#1

Bonjour,

Ca fait un petit bout de temps que j’utilise les clefs pour m’identifier sur mes serveurs. Jusque là, j’ai jamais eu aucun problème.

Mais voilà, je viens de bidouiller un NAS, et j’ai pu installé une Debian Lenny dessus.
J’installe ssh etc… tout fonctionne sauf, l’autentification par clefs…

J’ai copié le fichier de configuration d’un autre serveur, et même problème.

Ce que j’ai fait :

ssh-copy-id -i .ssh/id_dsa.pub archives@vserveur
(la clef apparait bien dans /home/archives/.ssh/authorized_keys sur vserveur)

ensuite
ssh archives@vserveur

Et là… il me demande le mot de passe !

Voici mes fichiers de configuration :
sshd_config

[code]# Package generated configuration file

See the sshd_config(5) manpage for details

What ports, IPs and protocols we listen for

Port 333

Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 768

Logging

SyslogFacility AUTH
LogLevel INFO

Authentication:

LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

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

AllowUsers *** *** archives
[/code]

merci pour votre aide

#2

Si tu as accès physiquement à ton serveur (clavier + écran) tu peux essayer de changer la ligne PasswordAuthentication pour y mettre no à la place de yes et voir si le serveur accepte tes clés.
Évidemment c’est à éviter si ton seul moyen d’accès au serveur est via SSH, car en cas d’échec tu te retrouverais bloqué.

Sinon, les suspects habituels pour ce genre de problème sont :

  • les droits sur le répertoire ~/.ssh (seul l’utilisateur doit avoir accès en écriture)
  • la configuration du client SSH (option PreferredAuthentications dans ~/.ssh/config ou /etc/ssh/ssh_config)
#3

Salut,

Le mode debug serait plus parlant.

Les messages d’erreurs déclarés t’aiguilleront … :wink:

#4

super, merci :slightly_smiling:

ssh archives@192.168.1.30 -vvv OpenSSH_6.0p1 Debian-2, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.30 [192.168.1.30] port 22. debug1: Connection established. debug1: identity file /home/vohu/.ssh/id_rsa type -1 debug1: identity file /home/vohu/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/vohu/.ssh/id_dsa" as a RSA1 public key debug1: identity file /home/vohu/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: identity file /home/vohu/.ssh/id_dsa-cert type -1 debug1: identity file /home/vohu/.ssh/id_ecdsa type -1 debug1: identity file /home/vohu/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-2 debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [192.168.1.30]:22 debug3: load_hostkeys: loading entries for host "[192.168.1.30]:22" from file "/home/vohu/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/vohu/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 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 debug2: dh_gen_key: priv key bits set: 142/256 debug2: bits set: 492/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 78:55:b1:33:73:b0:f2:02:eb:70:0a:23:a9:dd:1d:ee debug3: put_host_port: [192.168.1.30]:22 debug3: put_host_port: [192.168.1.30]:22 debug3: load_hostkeys: loading entries for host "[192.168.1.30]:22" from file "/home/vohu/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/vohu/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "[192.168.1.30]:22" from file "/home/vohu/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/vohu/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '[192.168.1.30]:22' is known and matches the RSA host key. debug1: Found key in /home/vohu/.ssh/known_hosts:1 debug2: bits set: 516/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/vohu/.ssh/id_dsa (0x7ff6c67237d0) debug2: key: /home/vohu/.ssh/id_rsa ((nil)) debug2: key: /home/vohu/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering DSA public key: /home/vohu/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/vohu/.ssh/id_rsa debug3: no such identity: /home/vohu/.ssh/id_rsa debug1: Trying private key: /home/vohu/.ssh/id_ecdsa debug3: no such identity: /home/vohu/.ssh/id_ecdsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password archives@192.168.1.30's password:

syam > pas possible, il n’y a aucun port USB sur le NAS. Si je perds l’accès SSH je ne peux plus rien faire.
Pour le fichier client, la même machine se connecte parfaitement à l’autre serveur duquel j’ai copié la configuration.

#5

Salut,
° Pourquoi Debian Lenny ?
° Comment as tu généré tes clés ? DSA donc ? Vérifier les droits comme dit Syam.
° Sinon, saches qu’il est possible de relancer le service sshd, sans que cela coupe les connections ssh déja établies. Ce qui te permet d’annuler tes modifications si besoin.
° Pour débugger la connection, il y a le ssh -v du coté client, mais tu peux aussi voir des logs du serveur.
Pour ca, tu peux lancer un deuxième console; te connecter à ton serveur; lancer un deuxième serveur SSH en parallel avec une commande du genre:

-d pour laisser ssh s’afficher dans la console, plustot que de l’envoyer en demon en arrière plan.
-D pour le mode debug.
-p pour un port différent du premier serveur.
tu peux aussi utiliser -f pour utiliser un fichier de configuration de test différent.
° Avec l’option -d , du coup le serveur ssh se fermera quand l’utilisateur se déconnectera par contre. Garde bien le premier serveur fonctionnel.

En espérant que ça te permette de voir pourquoi ta clé dsa n’est pas acceptée.
car dans ton ssh -vvv, j’ai l’impression que le client envoie sa clé DSA; donc qu’il accède bien à la clé, donc qu’il n’y a pas de problèmes de droits.

$ grep debug1 log_ssh_de_Vohu debug1: Next authentication method: publickey debug1: Offering DSA public key: /home/vohu/.ssh/id_dsa debug1: Authentications that can continue: publickey,password
Bonne chance

#6

ENfinnnnnnn…
Donc, c’était bien un problème de droits… J’avais déplacé ma partition home, lorsque j’ai changé les droits, ça n’a changé que ceux de .ssh, et pas son contenu…

Merci à tous, je note toutes les astuces, ça pourra toujours servir

:slightly_smiling:

#7

Résolu le sujet alors ?
Bonne continuation

#8

Salut,

Toujours est-il que, je prend note(s) une nouvelle fois … :wink:

[quote=“SwitchT”]Salut,
° Pourquoi Debian Lenny ?
° Comment as tu généré tes clés ? DSA donc ? Vérifier les droits comme dit Syam.
° Sinon, saches qu’il est possible de relancer le service sshd, sans que cela coupe les connections ssh déja établies. Ce qui te permet d’annuler tes modifications si besoin.
° Pour débugger la connection, il y a le ssh -v du coté client, mais tu peux aussi voir des logs du serveur.
Pour ca, tu peux lancer un deuxième console; te connecter à ton serveur; lancer un deuxième serveur SSH en parallel avec une commande du genre:

-d pour laisser ssh s’afficher dans la console, plustot que de l’envoyer en demon en arrière plan.
-D pour le mode debug.
-p pour un port différent du premier serveur.
tu peux aussi utiliser -f pour utiliser un fichier de configuration de test différent.
° Avec l’option -d , du coup le serveur ssh se fermera quand l’utilisateur se déconnectera par contre. Garde bien le premier serveur fonctionnel.

En espérant que ça te permette de voir pourquoi ta clé dsa n’est pas acceptée.
car dans ton ssh -vvv, j’ai l’impression que le client envoie sa clé DSA; donc qu’il accède bien à la clé, donc qu’il n’y a pas de problèmes de droits.

$ grep debug1 log_ssh_de_Vohu debug1: Next authentication method: publickey debug1: Offering DSA public key: /home/vohu/.ssh/id_dsa debug1: Authentications that can continue: publickey,password
Bonne chance[/quote]

Archivé ! :083

#9

[quote=“vohu”]
syam > pas possible, il n’y a aucun port USB sur le NAS. Si je perds l’accès SSH je ne peux plus rien faire.
Pour le fichier client, la même machine se connecte parfaitement à l’autre serveur duquel j’ai copié la configuration.[/quote]

Tu peu toujours démonté le disque et y accéder en le remontant dans une autre machine … :mrgreen:

#10

Sauf que je n’ai plus de PC de bureau :laughing: et j’ai pas très envie d’investir dans un SATA->USB

#11

Salut,

Pas un ami, pas un copain, pas un LUG, tu es à plaindre

#12

Je viens de déménager :119

Et il faut avouer que je m’entoure pas vraiment de geeks…

#13

pas d’accés console non plus ? Tu dois bien avoir un port série non sorti sur la carte.

#14

[quote=“vohu”]Je viens de déménager :119

Et il faut avouer que je m’entoure pas vraiment de geeks…[/quote]

Tu n’as pas besoin de geeks, même une belle-mère qui te fait confiance et c’est suffisant :slightly_smiling:

#15

Pirate> non, absolument rien, uniquement un port ethernet. Il doit bien avoir un port série quelque part sur la carte… mais je sais pas trop où.

Pour installer la lenny, j’ai fait une mise à jour du firmware (qui s’installe sur une partition du disque dur) depuis l’interface web de l’ancien système… Si ça avait planté, effectivement, le seul recours, étant d’enlever le disque et de le reconfigurer depuis un PC. en USB ou SATA.

ggoodluck47> Oui, mais il faut encore qu’elle soit dans la région ou j’ai déménagé :slightly_smiling:
Je connais 2 personnes ici, et ils n’ont que des portables.

M’enfin, la question ne se pose plus, puisque ça fonctionne.
Au pire, pour éviter de perdre l’accès ssh, j’avais installé telnet, et fait un lien dans local.rc vers un script vide que j’aurai écrasé par ftp.

#16

La proposition que j’ai faite pour sshd ne t’aurai pas convenu mieux que d’installer telnet ? :stuck_out_tongue:

#17

Si, mais je l’avais déjà fait avant.

C’est pour ça que je note ta solution pour la prochaine fois