[prev in list] [next in list] [prev in thread] [next in thread]
List: secure-shell
Subject: Strange behavior of ssh
From: <Dan.Johansson () swisscom ! com>
Date: 2003-04-30 5:48:17
[Download RAW message or body]
Hi,
I'm experiencing a strange behavior of ssh (in my opinion).
I'm having the following setup:
Host-A - HP-UX, OpenSSH 3.5p1, authorized_keys contains public keys for
user@Host-C, root@Host-A and root@Host-B
Host-B - HP-UX, OpenSSH 3.6.1p1, authorized_keys contains public keys
for user@Host-C, root@Host-A and root@Host-B
Host-C - Win-NT4, PuTTY 0.53
Here's my scenario:
ssh (PuTTY) user@Host-C to root@Host-A OK
ssh (PuTTY) user@Host-C to root@Host-B OK
ssh root@Host-A to root@Host-A OK
ssh root@Host-A to root@Host-B FAIL *
ssh root@Host-B to root@Host-A OK
ssh root@Host-B to root@Host-B FAIL
scp root@Host-A to root@Host-A OK
scp root@Host-A to root@Host-B OK
scp root@Host-B to root@Host-A OK
scp root@Host-B to root@Host-B OK
* And here is the output of "ssh -v -v root@HostB" from HostA:
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/opt/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to HostB [123.123.123.2] port 22.
debug1: Connection established.
debug1: identity file /.ssh/identity type 0
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.6.1p1
debug1: match: OpenSSH_3.6.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c
bc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c
bc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-9
6,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-9
6,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,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-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c
bc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c
bc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-9
6,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-9
6,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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: 136/256
debug1: bits set: 1575/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'HostB' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:127
debug1: bits set: 1571/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,keyboard-interactive
debug1: next auth method to try is publickey
debug2: userauth_pubkey_agent: no keys at all
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: try pubkey: /.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 4001a0c0
hint 1
debug2: input_userauth_pk_ok: fp
f4:26:12:76:df:3f:66:8a:b9:82:ce:7a:33:93:1a:f2
debug1: read PEM private key done: type RSA
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug2: x11_get_proto: /usr/bin/X11/xauth list U64632:0.0 2>/dev/null
Warning: No xauth data; using fake authentication data for X11
forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
debug1: Requesting authentication agent forwarding.
debug1: channel request 0: auth-agent-req@openssh.com
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to HostB closed by remote host.
Connection to HostB closed.
debug1: Transferred: stdin 0, stdout 0, stderr 79 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1098.7
debug1: Exit status -1
Any suggestions?
Regards,
Dan Johansson
Unix Systems Engineer
MC-TO-MIT-SYI-UNS
Mobile +41 (0)79 663 13 48
Dan.Johansson@swisscom.com
Swisscom Mobile Ltd, MC-TO-MIT-SYI-UNS, CH-3050 Bern
Location: Poststrasse 25, CH-3072 Ostermundigen
Phone +41 (0)31 342 51 57, Fax +41 (0)31 342 16 98,
www.swisscom-mobile.ch
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and delete this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic