[Bug 227] 2nd Client Instance Can Login Without Authorization

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=227





------- Additional Comments From drchang at hawaii.edu  2002-04-26 19:39 -------
Here is what is happening. I've replaced information with variables where
necessary to 
maintain privacy.

I'm connected and logged in from one workstation (HOST_X) using 
publickey
authentication. If from another workstation (HOST_Y) I execute:

# ssh -v -2 -c 
$CIPHER -l $USERNAME $HOSTNAME

OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 
0x0090603f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts 
Authentication disabled, originating port will not be trusted.
debug1: 
restore_uid
debug1: ssh_connect: getuid 6726 geteuid 6726 anon 1
debug1: Connecting to 
$HOSTNAME [$HOSTNAME] port 22.
debug1: temporarily_use_uid: 6726/100 (e=6726)
debug1: 
restore_uid
debug1: temporarily_use_uid: 6726/100 (e=6726)
debug1: 
restore_uid
debug1: Connection established.
debug1: identity file /$PATH/id_rsa type -
1
debug1: identity file /$PATH/id_dsa type 2
debug1: Remote protocol version 1.99, remote 
software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling 
compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-
OpenSSH_3.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT 
received
debug1: kex: server->client $CIPHER $CIPHER2 none
debug1: kex: client->server 
$CIPHER $CIPHER2 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: 255/512
debug1: bits 
set: 2018/4095
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting 
SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '$HOSTNAME' is known and matches the RSA host 
key.
debug1: Found key in /$PATH/known_hosts:1
debug1: bits set: 2118/4095
debug1: 
ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 
1
debug1: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS sent
debug1: 
waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: cipher_init: set keylen (16 -
> 32)
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,keyboard-
interactive
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: 
testing agent key "$USER at HOST_X"
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 817 
lastkey 1381a8 hint -1
debug1: ssh-userauth2 successful: method publickey
debug1: channel 
0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive 
session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: 
Requesting authentication agent forwarding.
debug1: channel request 0: auth-agent-
req at openssh.com
debug1: channel request 0: shell
debug1: fd 3 setting 
TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: $DATE_TIME 
from $LAST_HOST

I get connected without any prompt for a passphrase for my private key. 
The
key available on this workstation need not be in .authorized_keys for a login
to occur. 
Also "$USER@$HOST_X" is not the address listed in the key of the
workstation making the 
connection. Rather, it is "$USER at HOST_Y".
"$USER@$HOST_X" is the address listed in the key 
of the workstation already
logged in.

So it appears that "$USER@$HOST_Y" can connect 
using "$USER at HOST_X"'s
credentials.

HOST_X and HOST_Y are on totally different 
networks. HOST_X and HOST_Y
reference completely different keys.

Here are the RPM's in 
use. They are the latest binaries from Red Hat:

# rpm -qa | grep ssh
openssh-askpass-3.1p1-
2
openssh-3.1p1-2
openssh-server-3.1p1-2
openssh-clients-3.1p1-2

Linux kernel is 2.4.9-
31 using Red Hat Linux 7.2.

I did not configure ssh-agent for anything. It doesn't appear to be 
in use.

Explicit settings in sshd_config are:
PubkeyAuthentication 
yes
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication 
no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PasswordAuthentication 
no

I shall have to try compiling from source to see if that makes a difference.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.