I'm using Red Hat Linux 7.2 with the Red Hat binary RPM version of OpenSSH 3.1p1. I've noticed that when I'm logged in to the server from my local network using SSH2 and public key authentication, if I log in from another SSH2 client, an unauthorized key will be able to login to the server. Additionally, if a valid key is present on the 2nd client, no passphrase will be prompted for when connecting. In each instance, I'm logging into the same user account. In summary, if I'm logged in already, and I then I login using another client using public key authentication, the 2nd instance will not require a valid key for the server. All forms of authentication by host have been disabled in sshd_config.
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
could you please provide an example?
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@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@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@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@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.
Sorry about the linefeeds; cut and paste didn't work too well.
Please use attachments next time. In any case, your debug trace shows a successful login using public key authentication. Have you configured this?
$USER@HOST_X (more accurately, the key that $USER@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@HOST_Y connects, they connect as $USER@HOST_X, as seen in the debug trace. $USER@HOST_Y is not listed in .$authorized_keys. So $USER@HOST_X is configured, $USER@HOST_Y is not.
you are confused. you are using agent forwarding. as you say: only the key USER@HOST_X is allowed and this key is used: debug1: userauth_pubkey_agent: testing agent key "$USER@HOST_X" debug1: input_userauth_pk_ok: pkalg ssh-dss blen 817 lastkey 1381a8 hint -1 debug1: ssh-userauth2 successful: method publickey
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.
Mass change of RESOLVED bugs to CLOSED