No further authentication methods available

[Schweinebauer]

Wenn ich mich via SSH a´la Public Key einloggen will, responded der server "no further authentication methods available".

Key ist aber korrekt eingetragen, auf dem Server, wie auch auf meinem Clienten.

SSH habe ich server- und clientseitig auch schon neugestartet.

Gruß

 

[Ilai]

poste mal das log von ssh -v $server

 

[Schweinebauer]

poste mal das log von ssh -v $server

85:/etc/ssh# ssh -v $server
OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004
usage: ssh [-1246AaCfghkNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
           [-D port] [-e escape_char] [-F configfile] [-i identity_file]
           [-L port:host:hostport] [-l login_name] [-m mac_spec] [-o option]
           [-p port] [-R port:host:hostport] [user@]hostname [command]
85:/etc/ssh#

 

[Spin-Doc]

poste mal das log von ssh -v $server

Nicht ssh -v $server eingeben sondern

ssh -v ADRESSEdeinesSERVERS

 

[Schweinebauer]

OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 85.14.220.95 [85.14.220.95] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host '85.14.220.95 (85.14.220.95)' can't be established.
RSA key fingerprint is 2b:4e:b7:1f:45:a2:98:db:38:09:ba:d5:3f:70:a9:4a.

 

[Ilai]

der Fingerprint kan nnicht verifiziert werden - entweder der hat sich geändert, oder er ist lokal nicht bekannt - bricht der Connect an der Stelle schon ab?

wenn der Fingerprint bekannt ist, aber sich geändert hat, dann kannst du den alten Fingerprint in der ~/.ssh/known_hosts löschen -
ABER NUR, WENN DU DIR GANZ SICHER BIST, DASS DU DICH AUF DEM RICHTIGEN SERVER EINLOGGEN WILLST!

Sorry für das 'schreien', aber das ist echt absolut wichtig!

Wenn der Key nicht bekannt ist, müsste dich der SSH Client eigentlich auffordern, den Fingerprint zu prüfen und ggf. anzunehmen.

 

[Schweinebauer]

Ja,d er Client warnt mich. Aber ich nehme den Fingerprint an....?

 

[Schweinebauer]

In der kfnown-hosts steht nur

85.14.220.** ssh-rsa AAA****************[...]

 

[Ilai]

naja, das Log, welches du gepostet hast, endet an der Stelle.
Wenn das Log dort endet und der ssh Prozess ebenfalls beendet wird, dann scheint es mehr als nur eine Warnugn zu sein.

benenn die known_hosts mal um, dann sollte ssh dir direkt auf der Konsole sagen, dass der Fingerprint nicht verifiziert werden kann.

 

[Schweinebauer]

Tut sich garnichts

 

[Ilai]

also für mich sieht es immer noch danach aus, als würde der Connect scheitern, weil der Fingerprint nicht verifiziert werden konnte. Die Pub Keys würden erst in den nächsten Zeilen des Logs geprüft werden.
So weit kommt er ja aber gar nicht.

Da aber der Fingerprint des Servers nicht stimmt, werden die Keys gar nicht erst los geschickt - man gibt seine Schlüssel ja nicht irgend jemandem, dem man nicht vertraut.

Der Server scheint so konfiguriert zu sein, dass er kein KEYBOARD INTERACTIVE akzeptiert.

Vielleicht können die Config Files weiter helfen (Server und Client global & userspezifisch)
An sonsten kann ich dir auch nicht weiter helfen.