SSH-Authentifizierung mit RSA-Schlüssel

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
defod
Beiträge: 118
Registriert: 28.12.2011 19:13:38

SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von defod » 31.08.2012 12:37:53

Hallo.

Ich habe ein Problem, mich per SSH mit einem Server zu verbinden. Authetifizierung soll über einen RSA-Schlüssel laufen.

Ich habe per ssh-keygen -t rsa einen Schlüssel erstellt, dabei den Default-Speicherort belassen und ein Passwort angegeben. Den öffentlichen Schlüssel habe ich dann dem Kunden geschickt, der diesen - davon gehe ich bisher aus - korrekt für dem sshd des Servers hinterlegt hat.

Wenn ich mich jetzt mit dem Server Verbinde, erhalte ich folgende Ausgabe:

Code: Alles auswählen

me@localhost:~$ ssh -vvv me@customer-server.tld -p 22597 
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 customer-server.tld [xxx.xxx.xxx.xxx] port 22597.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
Warum wird hier ein RSA1-Identifier erwartet? Beziehungsweise von wem, vom Client oder vom Server? Ich habe den Schlüssel mit -t rsa angelegt, nicht mit -t rsa1 und er liegt in ~/.ssh/id_rsa(.pub), nicht in ~/.ssh/identity(.pub)

Code: Alles auswählen

debug3: Could not load "/home/me/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/me/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/me/.ssh/id_rsa-cert type -1
debug1: identity file /home/me/.ssh/id_dsa type -1
debug1: identity file /home/me/.ssh/id_dsa-cert type -1
debug1: identity file /home/me/.ssh/id_ecdsa type -1
debug1: identity file /home/me/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 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: [customer-server.tld]:22597
debug3: load_hostkeys: loading entries for host "[customer-server.tld]:22597" from file "/home/me/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/me/.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-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-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: 129/256
debug2: bits set: 496/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 5d:36:45:92:c1:5d:0d:b0:d5:7e:34:93:33:7f:b7:5b
debug3: put_host_port: [xxx.xxx.xxx.xxx]:22597
debug3: put_host_port: [customer-server.tld]:22597
debug3: load_hostkeys: loading entries for host "[customer-server.tld]:22597" from file "/home/me/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/me/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "[xxx.xxx.xxx.xxx]:22597" from file "/home/me/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/me/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[customer-server.tld]:22597' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:1
debug2: bits set: 530/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/me/.ssh/id_rsa (0x7f563a9326e0)
debug2: key: /home/me/.ssh/id_dsa ((nil))
debug2: key: /home/me/.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 RSA public key: /home/me/.ssh/id_rsa
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/me/.ssh/id_dsa
debug3: no such identity: /home/me/.ssh/id_dsa
debug1: Trying private key: /home/me/.ssh/id_ecdsa
debug3: no such identity: /home/me/.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
me@customer-server.tld's password: 

Code: Alles auswählen

$ cat /etc/ssh/ssh_config | grep -v '^ *#' | grep -v '^$'
Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Code: Alles auswählen

$ ls -la ~/.ssh
total 28
drwx------  2 me me 4096 Aug 31 12:29 .
drwxr-xr-x 60 me me 4096 Aug 31 08:54 ..
-rw-------  1 me me 1766 Aug 31 10:04 id_rsa
-rw-r--r--  1 me me  399 Aug 31 10:04 id_rsa.pub
-rw-r--r--  1 me me  884 Aug 31 12:11 known_hosts
Kann mir jemand von Euch bitte weiter helfen? Stimmt da etwas an meiner Konfiguration nicht oder liegt es am Server bzw. was kann ich, ohne den Kunden zu nerven auf meiner Seite probieren, um das Ding zum Laufen zu bringen?

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von rendegast » 31.08.2012 13:37:36

Den öffentlichen Schlüssel habe ich dann dem Kunden geschickt, der diesen - davon gehe ich bisher aus - korrekt für dem sshd des Servers hinterlegt hat.
Es muß doch andersherum laufen, Du brauchst als ssh-client den Publikkey eines Schlüssels, der auf dem Server hinterlegt ist.

So wie es jetzt ist, könnte sich der Kunde bei Dir als /home/me einloggen.


EDIT EDIT
Sorry, Sorry
Zuletzt geändert von rendegast am 03.09.2012 12:42:57, insgesamt 2-mal geändert.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

defod
Beiträge: 118
Registriert: 28.12.2011 19:13:38

Re: SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von defod » 31.08.2012 13:41:00

Ich glaube nicht, oder? Hier zwei Anleitungen:

http://news.softpedia.com/news/How-to-U ... 8599.shtml
http://www.linuxproblem.org/art_9.html

Es wird jeweils das Schlüsselpaar lokal erstellt und der öffentliche Schlüssel dann hoch geladen. Oder stehe ich auf dem Schlauch?

nepos
Beiträge: 5238
Registriert: 05.01.2005 10:08:12

Re: SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von nepos » 31.08.2012 15:45:55

rendegast hat geschrieben:
Den öffentlichen Schlüssel habe ich dann dem Kunden geschickt, der diesen - davon gehe ich bisher aus - korrekt für dem sshd des Servers hinterlegt hat.
Es muß doch andersherum laufen, Du brauchst als ssh-client den Publikkey eines Schlüssels, der auf dem Server hinterlegt ist.

So wie es jetzt ist, könnte sich der Kunde bei Dir als /home/me einloggen.
Seit wann denn sowas? Der Private Key bleibt bei dir, der Public Key gehoert in die ~/.ssh/authorized_keys auf dem Server, wo du dich einloggen willst.

@defod: Wenn ich den Debugoutput auf die Schnelle richtig gelesen habe, dann liegt das Problem eher auf Server-Seite. Dein Client schickt den RSA-Key an den Server, weil das nicht klappt, macht er mit Passwort-Authentisierung weiter. Frag mal den Kunden, ob der Key auch wirklich korrekt auf dem Server gelandet ist.

Benutzeravatar
peschmae
Beiträge: 4844
Registriert: 07.01.2003 12:50:33
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: nirgendwo im irgendwo

Re: SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von peschmae » 31.08.2012 20:56:10

nepos hat geschrieben: @defod: Wenn ich den Debugoutput auf die Schnelle richtig gelesen habe, dann liegt das Problem eher auf Server-Seite. Dein Client schickt den RSA-Key an den Server, weil das nicht klappt, macht er mit Passwort-Authentisierung weiter. Frag mal den Kunden, ob der Key auch wirklich korrekt auf dem Server gelandet ist.
Ja, denke ich auf dern ersten Blick auch. Das mit Schlüssel verteilen hast du schon richtig herum gemacht.

Kann auch irgendwas doofes sein auf Serverseite, wie zum Beispiel dass die Berechtigungen von der authorized_keys zu liberal sind oder so, da gibts glaube ich ein paar Einschränkungen damit der sshd das akzeptiert...

MfG Peschmä
"er hätte nicht in die usa ziehen dürfen - die versauen alles" -- Snoopy

uname
Beiträge: 12482
Registriert: 03.06.2008 09:33:02

Re: SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von uname » 31.08.2012 22:03:13

Interessant wäre der Auszug aus /var/log/auth.log vom Server.

defod
Beiträge: 118
Registriert: 28.12.2011 19:13:38

Re: SSH-Authentifizierung mit RSA-Schlüssel

Beitrag von defod » 01.09.2012 08:05:35

Ich habs gelöst. Der Kunde hat mir geschrieben, ich müsse mich am Server per me@server anmelden, um ein git-Repository auszuchecken. Er hat auf dem Server gitosis installiert. Das ist ein Tool zur Verwaltung von Zugriffsrechten für einen zentralen git-Server. gitosis benutzt für alle gitosis-Benutzer nur einen Linux-Benutzer und übergibt den gitosis-Benutzernamen desjenigen, der sich per ssh authentifiziert an gitosis anhand eines Parameters eines Kommandos in ~/.ssh/authorizes_keys. Das heißt, ich bin zwar in gitosis der Benutzer me, aber für ssh bin ich der Benutzer git (oder unter welchem Namen gitosis auch immer läuft). ssh konnte mit dem Benutzer me also einfach nichts anfangen. Wenns mal wieder länger dauert...

Danke für Eure Unterstützung.

Antworten