Discussion:
Portalbe OpenSSH's don't know agent's keys after authenticion failure with partial success
(too old to reply)
Tóth, László Attila
2016-02-18 14:31:04 UTC
Permalink
Hi,

I created a patch on the top of git repository git://
anongit.mindrot.org/openssh.git
commit 292a8dee14e5e67dcd1b49ba5c7b9023e8420d59 ***@mindrot.org upstream
commit

which fixes the issue, and OpenSSH client seems to be working fine in this
case, too. The patch is attached.


Regards,
Laszlo Attila Toth



2015-12-18 15:12 GMT+01:00 Tóth, László Attila <
Hi,
If SSH_MSG_USERAUTH_FAILURE arrives from the server with partial success
(set to 1), in input_userauth_failure() the pubkey_cleanup() and
pubkey_prepare() calls does different thing than the first pubkey_prepare()
instead of identical.
OpenSSH versions: 6.7p1 to 7.1p1 (based on changelog the issue seems to be
* ssh(1): reset the order in which public keys are tried after partial
authentication success.
* an ssh-agent with a passphrase-protected private key stored in its
standard name (e.g. .ssh/id_rsa)
* a server that accepts this key but requires further authentication (auth
failure with partial success)
* and the ssh client
First the client sends the key stored in the agent, and then clears its
keys in authctx, and retries the keys. At this point the public key is
missing (.ssh/id_rsa), therefore ssh tries to ask the passphrase, even if
the key is loaded into the agent. And if the passphrase is given, it
retries the very same key.
options.identity_keys[i] = NULL;
If the code wants to iterate thrugh these keys after a partial success,
these keys should never
be NULL'ed, instead these should be copied.
As a result, if I'm not mistaken, the ssh client skips all keys of the
agent.
Regrads,
Laszlo Attila TOTH
Damien Miller
2016-02-18 22:47:32 UTC
Permalink
Post by Tóth, László Attila
Hi,
I created a patch on the top of git repository git://
anongit.mindrot.org/openssh.git
commit
which fixes the issue, and OpenSSH client seems to be working fine in this
case, too. The patch is attached.
I'm not exactly clear on what the problem is here - authentication using
multiple public keys is tested in the regress/multipubkey.sh test at the
moment. Is there a case that is missing?

-d
Tóth, László Attila
2016-02-19 10:48:38 UTC
Permalink
Hi,

Yes, it seems that there's a case that's missing, but I think not from
regress/multipubkey.sh, because in this case there is only one public key,
which is in ~/.ssh/id_dsa and in the agent

I try to describe it:

Topology:
-------------

1) client: OpenSSH 7.1p2 with running ssh-agent

the client uses ssh-agent, and there is a passphrase-protected (e.g. DSA)
key, that's loaded into the agent, but can be accessed via its standard
file name (~/.ssh/id_dsa in the example).
No more public key is available either in the agent or in ~/.ssh

ssh -vp 2222 -o PubkeyAcceptedKeyTypes=+ssh-dss localhost -l gu=***@panther


2) the server: OpenSSH, but it doesn't really matter

3) between the client and the server there is a proxy that requires
additional authentication not related to the server's authentication


Communication without the patch, with output of 'ssh -v'
--------------------------------------------------------------------------------

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive

1) client sends that public key to the proxy without signature.
(SSH_MSG_USERAUTH_REQUEST)
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/panther/.ssh/id_dsa

2) the proxy accepts it, but requres the signed one (SSH_MSG_USERAUTH_PK_OK)
debug1: Server accepts key: pkalg ssh-dss blen 434

3) client sends the public key with signature (USERAUTH_REQUEST)

Here comes the tricky part, because the client already sent the public key,
therefore it won't resend it:

4) the proxy tries this public key on the server side (USERAUTH_REQUEST, to
the server, without signature)
5) the server doesn't know this key - missing from authorized_keys
(USERAUTH_FAILURE, partial_succes=0)
6) the proxy sends this failure to the client (USERAUTH_FAILURE,
partial_success=1 because it is alredy authenticated to the proxy)
Authenticated with partial success
debug1: Authentications that can continue: publickey,password

From now on the proxy doesn't really matter, just forwards packets:

7) the client retries the same public key from the agent (USERAUTH_REQUEST,
without signature)
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/panther/.ssh/id_dsa

8) the server receives this, and rejects it again (USERAUTH_FAILURE,
partial_succes=0)

Here the client goes wrong, I think:

9) the client is confused, finds the same public key, but not in the agent,
therefore it tries to read from the file system, but it's encrypted
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/panther/.ssh/id_rsa
debug1: Trying private key: /home/panther/.ssh/id_dsa
Enter passphrase for key '/home/panther/.ssh/id_dsa':

10) I presss enter, and it falls back to password
debug1: Trying private key: /home/panther/.ssh/id_ecdsa
debug1: Trying private key: /home/panther/.ssh/id_ed25519
debug1: Next authentication method: password
***@localhost's password:



Communication with the patch, with output of 'ssh -v'
--------------------------------------------------------------------------------
1-8) the same
9) the password method immediately (as it should be)
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/panther/.ssh/id_rsa
debug1: Trying private key: /home/panther/.ssh/id_ecdsa
debug1: Trying private key: /home/panther/.ssh/id_ed25519
debug1: Next authentication method: password
***@localhost's password:


Shortly from the client's view, with step numbers:
----------------------------------------------------------------------
-1) USERATUH_REQUEST(none)
0) USERAUTH_FAILURE(publickey,keyboard-interactive, partial_success=0)
1) USERAUTH_REQUEST(publickey, no signature)
2) USERAUTH_PK_OK
3) USERAUTH_REQUEST(publickey, signature)
6) USERAUTH_FAILURE(publickey,password, partial_success=1)
7) USERAUTH_REQUEST(publickey, no signature)
8) USERAUTH_FAILURE(publickey,password, partial_success=0)
and here the ~/.ssh/id_dsa file is read directly if OpenSSH is not patched


Regards,
Laszlo Attila Toth
Post by Damien Miller
Post by Tóth, László Attila
Hi,
I created a patch on the top of git repository git://
anongit.mindrot.org/openssh.git
commit
which fixes the issue, and OpenSSH client seems to be working fine in
this
Post by Tóth, László Attila
case, too. The patch is attached.
I'm not exactly clear on what the problem is here - authentication using
multiple public keys is tested in the regress/multipubkey.sh test at the
moment. Is there a case that is missing?
-d
Loading...