Forum Linux.debian/ubuntu Sécurisation SSH poussée : authentification par clé DSA

Posté par .
Tags : aucun
1
29
sept.
2010
bonjour tout le monde.

il m'arrive un soucis et je ne sais plus quoi faire. voilà j'ai suivit ce tuto car j'aimerai qu'avec une page de mon site web (machine a) je puisse exécuter des scripts sur une machine b.

Donc j'ai suivi ce tuto, je l'ai même fait et refais mais rien a faire:[url=http://technique.arscenic.org/connexion-distante-au-serveur-(...)]ici[/url].
et quand j'essaye de me connecté il me demande toujours le mot de passe. je vous met le lancement en mod debug.
[code]
ks*****:~# su www-data
ks*****:/root$ cd /var/www
ks*****:~$ ssh -vvv script@91.121.96.55
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to ip2 [ip2] port 22.
debug1: Connection established.
debug1: identity file /var/www/.ssh/identity type -1
debug3: Not a RSA1 key file /var/www/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /var/www/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug3: Not a RSA1 key file /var/www/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /var/www/.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: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
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,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-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 138/256
debug2: bits set: 486/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /var/www/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '91.121.96.55' is known and matches the RSA host key.
debug1: Found key in /var/www/.ssh/known_hosts:1
debug2: bits set: 507/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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /var/www/.ssh/identity ((nil))
debug2: key: /var/www/.ssh/id_rsa (0xb7868268)
debug2: key: /var/www/.ssh/id_dsa (0xb7868280)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,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: Trying private key: /var/www/.ssh/identity
debug3: no such identity: /var/www/.ssh/identity
debug1: Offering public key: /var/www/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /var/www/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
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
script@ip2's password:
[/code]
pourriez vous me dire ce qui ne va pas. Alors pour toutes les questions d'usage:

pour la partie client donc machine A. j'ai bien la clef publique, la clef privée, et le known_hosts.
Cela ce trouve dans le répertoire parent de www-data, c'est a dire: /var/www/.ssh/

pour la partie serveur j'ai bien copié la clef publique dans le fichier authorized_keys qui est dans le dossier parent de script, c'est a dire: /home/script/.SSH
  • # l'inverse ?

    Posté par . Évalué à 3.

    il faut copier la cle publique dans le fichier authorized_keys du serveur
    dans le home de l'utilisateur avec lequel tu va te loguer.

    habituellement pour etre sur qu'elle soit poser au bon endroit on fait (depuis la machine qui va executer la demande d'identification) un
    ssh-copy-id utilisateur@serveur

    et en general ca suffit.


    j'imagine aussi que tu as testé en tenant compte du bug potentiel identifié sur ce meme blog (en bas) ?
  • # Manque les logs serveurs

    Posté par (page perso) . Évalué à 2.

    Quand tu a un soucis sur une appli client/server les logs clients ne suffisent pas a diagnostiquer un problème.

    La ton client semble offrir une clef rsa et une clef dsa mais le serveur n'en veut pas:

    debug1: Offering public key: /var/www/.ssh/id_rsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: publickey,password
    debug1: Offering public key: /var/www/.ssh/id_dsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: publickey,password

    Après je dit "semble" car les messages initiaux ne sont pas rassurant quand a la qualité des clefs:

    debug3: Not a RSA1 key file /var/www/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    debug3: key_read: missing whitespace

    Vérifie coté serveur les droits des fichiers/dossiers home, home/.ssh et home/.ssh/*
    et regarde s'il n'y a pas un log qui traîne, si non lance le serveur ssh en debug/verbeux
    • [^] # Re: Manque les logs serveurs

      Posté par . Évalué à 1.

      oui j'ai oublié de préciser que vu que ca ne marchais pas avec une clef dsa j'ai essayé avec une clef rsa mais ca n'a pas fonctionné non plus. Alors j'ai créé les deux en mêmetemps ce qui ne fonctionne pas non plus.

      pourtant elles sont toutes les deux enregistré dans le fichier authorized_keys

      Vu que ca ne marchais pas j'ai "chmodé" tous les dossiers et fichiers en 777

      Je vais regarder les logs et vous communiquerai ce que j'ai
      • [^] # Re: Manque les logs serveurs

        Posté par (page perso) . Évalué à 3.

        Vu que ca ne marchais pas j'ai "chmodé" tous les dossiers et fichiers en 777

        Ce n'est pas une solution, et en plus cela va ajouter des problèmes. Par exemple, le serveur SSH refusera de lire un fichier authorized_hosts qui est lisible par tout le monde.

        Quels sont les fichiers qui ont ainsi vus leurs permissions modifiées ? Remets les permissions initiales.

        debug3: Not a RSA1 key file /var/www/.ssh/id_rsa.
        debug2: key_type_from_name: unknown key type '-----BEGIN'


        Comme dit plus haut, commence par corriger cela. Pour info, voilà à quoi ressemble un début de clef RSA :

        -----BEGIN RSA PRIVATE KEY-----
        MIIEogIBAAKCAQEAyiYy9xX9VNA+jXyfRaHfPtHNl6AwHa9CRFyT7+atYRxBFF7d


        D'après le message, on pourrait croire à quelque chose comme un saut à la ligne inopportun au milieu de l'entête.
    • [^] # Re: Manque les logs serveurs

      Posté par (page perso) . Évalué à 4.

      Il manquerait aussi la configuration du serveur.

      D'après le lien donné, il suffit d'utiliser la directive "PasswordAuthentication no". Certes c'est une bonne chose, mais si à côté de cela il manque les directives "RSAAuthentication yes" et "PubkeyAuthentication yes" les risques d'échecs sont assez élevés.
  • # j'ai tout recommencé du début!!

    Posté par . Évalué à 1.

    j'ai supprimé les dossier .ssh de www-data coté client et .ssh de script coté serveur. en suite
    coté client

    ks*****:~$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/var/www/.ssh/id_rsa):

    (j'ai tapé entrer)

    Created directory '/var/www/.ssh'.
    Enter passphrase (empty for no passphrase):

    (j'ai tapé entrer pour ne pas avoir de passphrase a taper et accéder a mon serveur directement)

    Enter same passphrase again:

    idem

    Your identification has been saved in /var/www/.ssh/id_rsa.
    Your public key has been saved in /var/www/.ssh/id_rsa.pub.
    The key fingerprint is:
    **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:** www-data@ip_du_serv
    The key's randomart image is:

    (là, il y a des symboles)

    ks****:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub script@IP¨_du_serv
    The authenticity of host 'IP¨_du_serv (IP¨_du_serv)' can't be established.
    RSA key fingerprint is **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '91.121.96.55' (RSA) to the list of known hosts.
    script@IP¨_du_serv's password:
    Now try logging into the machine, with "ssh 'script@IP¨_du_serv", and check in:

    .ssh/authorized_keys

    to make sure we haven't added extra keys that you weren't expecting.

    ks****:~$

    autorisation des fichiers:

    côté client:

    dossier .ssh: 700
    id_dsa: 600
    id_dsa.pub et known_hosts: 644

    côté serveur

    dossier .ssh: 700
    authorized_keys: 600

    coté serveur

    ns****:~# /etc/init.d/ssh restart
    Restarting OpenBSD Secure Shell server: sshd.


    ma clef privé et du type

    -----BEGIN RSA PRIVATE KEY-----
    MIIEoAIBAAKCAQEAotlD6nl4GfowH1LX+bLF9H8Ol/rGkWNH6Jxvfx9uow1Ak54F....
    -----END RSA PRIVATE KEY-----

    Ce que je ne comprend pas c'est qu'il y a des retours chariot

    pour les logs, ils sont activé mais je n'en ai aucun dans auth.log. j'en perd mon latin.
    et donc résultat toujours pareil:

    debug1: identity file /var/www/.ssh/identity type -1
    debug3: Not a RSA1 key file /var/www/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    • [^] # Re: j'ai tout recommencé du début!!

      Posté par . Évalué à 1.

      ok j'ai trouvé.

      en fait, d'origine quand on créer les clefs, il créé le dossier .ssh et le chmod en 700. Il faut le "chmoder" en 755

      merci de m'avoir mis sur la voix et de m'avoir aidé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.