openssh unix dev - Apr 2002 - [Bug 227] 2nd Client Instance Can Login Without Authorization

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





------- Additional Comments From mouring at eviladmin.org  2002-04-26 15:03
-------
Provide us with your environment and a reproducable example.

The only thing I can think of is that you are using ssh-agent and you've
registered your key with the agent the first time.  Thus it is now usable for
all following SSH sessions (from your account) without having to decrypt the
key.

Other than using ssh-agent I can't see nor reproduce this with 3.1 compiled
from
the OpenSSH portable tree (non-Redhat RPM) or under OpenBSD using -current.

- Ben



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

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





------- Additional Comments From markus at openbsd.org  2002-04-26 17:41 -------
could you please provide an example?



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

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.

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





------- Additional Comments From drchang at hawaii.edu  2002-04-26 19:41 -------
Sorry about the linefeeds; cut and paste didn't work too well.



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

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





------- Additional Comments From djm at mindrot.org  2002-04-26 21:05 -------
Please use attachments next time. In any case, your debug trace shows a
successful login using public key authentication. Have you configured this?



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

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





------- Additional Comments From drchang at hawaii.edu  2002-04-26 21:33 -------
$USER at HOST_X (more accurately, the key that $USER at HOST_X uses) is the only
user
(key) authorized in .$authorized_keys. When this user is logged in via sshd, 
using their key for pubkey authentication, then when $USER at HOST_Y connects, 
they connect as $USER at HOST_X, as seen in the debug trace. $USER at HOST_Y is
not
listed in .$authorized_keys.

So $USER at HOST_X is configured, $USER at HOST_Y is not.



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

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

markus at openbsd.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From markus at openbsd.org  2002-04-27 18:34 -------
you are confused. you are using agent forwarding.

as you say:

only the key USER at HOST_X is allowed and this key is used:

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



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

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





------- Additional Comments From drchang at hawaii.edu  2002-04-27 19:49 -------
Thankfully I am confused! Thanks for pointing out the "agent
forwarding". I've
figured out that since I was using the same client, with this feature 
unwittingly enabled, to handle both connections during testing that it was the 
client that was maintaining my credentials. When this feature is disabled, the 
appropriate keys are authenticated or denied as expected.



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