2017-07-16 2 views
0

Client: Betriebssystem Ubuntu, Git-Version 2.7.4.Git Permission verweigert (publickey, gssapi-keyex, gssapi-mit-mic)?

Server: OS Centos, Git-Version 2.7.4.

Ich habe einen privaten SSH-Schlüssel in meinem Client und öffentlichen Schlüssel im Server.

Ich kann Shell verwenden, um meinen Server einzugeben (kein Passwort).

Aber kann Ursprung Master nicht drücken!

sudo ssh -i/path/to/key/Vt [email protected] OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to xxx.xx.xxx.xxx [xxx.xx.xxx.xxx] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /home/whj/.ssh/whjwebsite type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/whj/.ssh/whjwebsite-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 debug1: Authenticating to xxx.xx.xxx.xxx:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: [email protected] debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:aC1Ydp+6x8IP+TV5jEl7WwqW6sEycbznbfL09qON/OA debug1: Host 'xxx.xx.xxx.xxx' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/whj/.ssh/whjwebsite debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

'whjwebsite' ist meine privaten Schlüssel.

drwx ------ .ssh/

-rw ------- whjwebsite

Server: sshd_config:

`` ` RSAAuthentication ja PubkeyAuthentication ja GSSAPIAauthentifizierung ja GSSAPICleanupCredentials nein UseDNS nein AdresseFamily inet PermitRootLogin ja SyslogFacility AUTHPRIV PasswordAuthentication kein ChallengeResponseAuthentication no

client: ssh_config

enter image description here

+0

der Schlüssel vom Server zurückgewiesen wird – Jakuje

+0

Es ist schlimmer, dass: der öffentliche Schlüssel nicht einmal verwendet wird, weil die Verbindung „durch Zufall“ versagt - 'Authentifizierungen, die weiter: ... Next-Authentifizierung Methode: gssapi-keyex ... Nächste Authentifizierungsmethode: gssapi-with-mic' Gaaah! Das ist eine tödliche Falle, da ein Fehler in der Kerberos-Authentifizierung in der Regel die Verbindung abstürzt, ohne eine andere Methode zuzulassen (z. B. 'publickey'). –

Antwort

1

My 2 cents: auf Serverseite, deaktivieren GSSAPIAuthentication (d.h. SSO, das von Kerberos unterstützt wird, es sei denn, Sie verwenden die Active Directory-Authentifizierung unter Linux (mit Centrify oder SSSD) in einer Unternehmensfirewall.

Wenn Sie sich tatsächlich in einem SSO-Szenario befinden, aber Single Sign-On aus irgendeinem Grund nicht sofort einsatzbereit ist, verwenden Sie clientseitige Optionen, um Kerberos zu umgehen, z.

ssh -o GSSAPIAuthentication=no -o GSSAPIKeyExchange=no

Verwandte Themen