[Fwd: Re: ssh mit Host basierender Authentifierung]
Hi Bernd, Bernd Tannenbaum wrote:
Aber zum besseren debug: Du kannst auch einen ssh-Verbindungsaufbau "verbose" testen. Dadurch erhälst du recht gute Infos darüber, ob der nach dem Schlüssel sucht, ihn findet, etc...(ssh -v gerd/heinz) Vielleicht kannst du den Output mal posten.
Interessant finde ich, dass es überhaupt nicht zur "hostbased" authentications kommt : debug1: authentications that can continue: publickey,password,hostbased debug1: next auth method to try is publickey debug1: try privkey: /root/.ssh/id_dsa debug1: next auth method to try is password root@gerd.fasel.de's password: Ciao Ingo Anlage: ------- heinz:/home/roessler # ssh -v gerd.fasel.de OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to gerd.fasel.de [192.168.30.2] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.0.2p1 debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p2 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 sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 131/256 debug1: bits set: 1575/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'gerd.fasel.de' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts2:2 debug1: bits set: 1572/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,hostbased debug1: next auth method to try is publickey debug1: try privkey: /root/.ssh/id_dsa debug1: next auth method to try is password root@gerd.fasel.de's password: debug1: ssh-userauth2 successful: method password debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug1: client_init id 0 arg 0 debug1: channel request 0: shell debug1: channel 0: open confirm rwindow 0 rmax 16384 Last login: Tue Mar 25 13:04:27 2003 from heinz.fasel.de Have a lot of fun... gerd:~ # exit debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 logout debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: rcvd close debug1: channel 0: input open -> closed debug1: channel 0: close_read debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: channel 0: send close debug1: channel 0: is dead debug1: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug1: channel_free: channel 0: dettaching channel user Connection to gerd.fasel.de closed. debug1: Transferred: stdin 0, stdout 0, stderr 39 bytes in 19.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.1 debug1: Exit status 0 heinz:/home/roessler # PS: Entschuldige die PM
Hallo, Ingo
Hi Bernd,
Bernd Tannenbaum wrote:
Aber zum besseren debug: Du kannst auch einen ssh-Verbindungsaufbau "verbose" testen. Dadurch erhälst du recht gute Infos darüber, ob der nach dem Schlüssel sucht, ihn findet, etc...(ssh -v gerd/heinz) Vielleicht kannst du den Output mal posten.
Interessant finde ich, dass es überhaupt nicht zur "hostbased" authentications kommt :
debug1: authentications that can continue: publickey,password,hostbased debug1: next auth method to try is publickey debug1: try privkey: /root/.ssh/id_dsa debug1: next auth method to try is password root@gerd.fasel.de's password:
Tja, sieht genau so aus wie bei mir damals, der key wird nicht als solcher erkannt. Also entweder Olivers Einwurf triffts (siehe andere Antwort) oder wenn das nicht hilft, würde ich beide Rechner auf dieselbe ssh-Version ziehen, hat zumindest bei mir geklappt. GL, bernd
Hi, Ingo Rößler wrote:
Interessant finde ich, dass es überhaupt nicht zur "hostbased" authentications kommt :
Durch PreferredAuthentications hostbased,publickey,password bekommt man das im Griff. Dann hat die Namensauflösung nicht (insbesondere Reverselookup) geklappt. Das habe ich auch geklärt. Jetzt stehe ich hier und weiss nicht was das heissen soll : debug1: authentications that can continue: publickey,password,hostbased debug1: next auth method to try is hostbased debug1: sig size 20 20 ### speziell dies! ### debug1: authentications that can continue: publickey,password,hostbased debug1: authentications that can continue: publickey,password,hostbased debug1: next auth method to try is publickey debug1: try pubkey: /root/.ssh/id_dsa debug1: authentications that can continue: publickey,password,hostbased debug1: next auth method to try is password root@gerd's password: Ich hoffe, es fällt noch jemanden was dazu ein. Danke, Ingo
participants (2)
-
Bernd Tannenbaum
-
Ingo Rößler