SSH Permission denied (publickey)

Je suis en train de faire un SSH sur une Debian à partir d'Ubuntu. J'ai déjà une clé RSA; c'est la même clé que j'utilise obtenu mon Git.

J'ai copié la clé à partir d'Ubuntu à Debian en utilisant:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@ip-address

Puis j'ai modifié sshd_config sur Debian pour inclure les éléments suivants:

RSAAuthentication yes

PubkeyAuthentication yes

PasswordAuthentication no

Et j'ai redémarré mon service SSH. Maintenant, j'essaie de connecter par SSH à partir d'Ubuntu à l'aide de

ssh -v root@ip-addr

mais je reçois le texte suivant:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.0.1.64 [10.0.1.64] port 22.
debug1: Connection established.
debug1: identity file /home/koushatalebian/.ssh/id_rsa.pub type 1
debug1: identity file /home/koushatalebian/.ssh/id_rsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-8
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH* compat 0x04000000
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA e2:af:83:f8:df:e2:15:db:77:30:e1:6b:e7:dc:77:99
debug1: Host '10.0.1.64' is known and matches the ECDSA host key.
debug1: Found key in /home/koushatalebian/.ssh/known_hosts:10
debug1: ssh_ecdsa_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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/koushatalebian/.ssh/id_rsa.pub
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Au fond, je veux de la force SSH pour se produire uniquement par le biais de publickey d'authentification.

J'ai lu tous les post concernant ce sujet, et aucun d'entre eux travaillaient pour moi. C'est pourquoi j'ai créé ce comme un poste distinct.

MODIFIER

Changer StrictModes de yes à no dans sshd_config résolu le problème. Est-ce sécuritaire de le faire?

EDIT 2
C'est le journal pour le SSH sur le serveur:

May  5 18:23:55 lemaker sshd[2591]: Connection from 10.0.1.37 port 42748
May  5 18:23:55 lemaker sshd[2591]: debug1: PAM: setting PAM_RHOST to "10.0.1.37"
May  5 18:23:55 lemaker sshd[2591]: Failed publickey for root from 10.0.1.37 port 42748 ssh2
May  5 18:23:55 lemaker sshd[2591]: Connection closed by 10.0.1.37 [preauth]
Vous essayez de vous authentifier avec votre public. Vous devez utiliser votre clé privée - généralement l'un sans l'extension.
Qu'est-ce que ce paramètre? "PermitRootLogin yes"
La désactivation de StrictModes est probablement une mauvaise idée, car cela signifie que vous avez un fichier de clé ssh pense n'est pas suffisamment protégé par les autorisations pour être digne de confiance. Vous pouvez choisir de faire confiance de toute façon, mais vous le faites à vos risques et périls. Il est probablement mieux de trouver le ou les fichier(s) il n'aime pas et de réparer les autorisations sur eux

OriginalL'auteur Kousha | 2015-05-05

  1. 5

    Vous ne voulez pas offrir à vos .pub vos informations d'identification. Vous souhaitez utiliser votre clé privée sur votre fin, alors vous devriez probablement faire de 

    ssh -v -i ~/.ssh/id_rsa root@ip-addr

    qui est l'option par défaut de la clé à utiliser, vous pouvez simplement laisser tomber le -i drapeau complètement

    Aussi, assurez-vous d'avoir PermitRootLogin yes si vous allez connecter en tant que root via ssh

    Vite fait bien fait, mais toujours le même problème.
    Tiens, j'ai donc changé StrictModes à no et maintenant ça fonctionne. Est ce que ça va?
    Vous devriez probablement le double de vérifier que les autorisations sont sur vos clés, vous voulez 600 sur votre clé privée et 644 sur la clé publique. Et sur le serveur, vous aurez envie 644 sur authorized_keys et que le .ssh répertoire sur chaque est de 700
    Je l'ai fait, mais si je retourne à yes pour StrictModes j'obtiens le même problème.
    Avez-vous essayez de regarder dans /var/log/secure (pour Fedora/RHEL systèmes de type) ou je pense que c'est /var/log/auth.log pour Ubuntu pour voir ce que le serveur n'aime pas?

    OriginalL'auteur Eric Renouf

  2. 0

    Je voudrais faire une nouvelle paire de clés et de l'utiliser à la place. Cette juste des tests de choses localement, mais simplement de goudron .ssh répertoire et de le mettre sur le serveur distant pour faire les deux sens ssh possible, si vous voulez seulement un chemin, puis le public n'est pas la clé à la fois des fichiers authorized_keys:

    $ pwd
/home/testuser
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/testuser/.ssh/id_rsa):[ENTER]
Created directory '/home/testuser/.ssh'.
Enter passphrase (empty for no passphrase):[ENTER]
Enter same passphrase again:[ENTER]
Your identification has been saved in /home/testuser/.ssh/id_rsa.
Your public key has been saved in /home/testuser/.ssh/id_rsa.pub.
[...]
$ cd .ssh
$ ls -l
total 8
-rw------- 1 testuser testuser 1679 May 5 13:49 id_rsa
-rw-r--r-- 1 testuser testuser 401 May 5 13:49 id_rsa.pub
$ cat id_rsa.pub >> authorized_keys
$ ssh 127.0.0.1
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ECDSA key fingerprint is 0f:dd:ed:e3:bf:a1:c8:3f:fd:b2:0d:e8:1f:ee:29:f8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.16.0-36-generic x86_64)
[...]
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

$ exit
Connection to 127.0.0.1 closed.

    OriginalL'auteur John Rigler