openssh unix dev - Feb 2018 - Attempts to connect to Axway SFTP server result in publickey auth loopin

We are attempting to use openssh sftp to connect to a server that is 
running some version of the Axway SFTP server. After a publickey auth 
completes, the server resends publickey as a valid auth. This results in 
a loop as openssh sftp resubmits the publickey information. This seems 
similar to a discussion in 2014 that terminated with the thought that it 
might be nice if the client tracked this 
(https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-August/032800.html). 
Is there any option we can use that will prevent this behavior? Attempts 
to contact Axway have failed as we?re not direct customers of theirs and 
the party actually running the server is blaming openssh.

debug1: Authentications that can continue: 
password,publickey,keyboard-interactive
debug3: start over, passed a different list 
password,publickey,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /ssh/keys/secret.key
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp 
SHA256:W0A/tu/vWh2vk0zHJUdTsZN9adQmS6x7fEbMbSTayfs
debug3: sign_and_send_pubkey: RSA 
SHA256:W0A/tu/vWh2vk0zHJUdTsZN9adQmS6x7fEbMbSTayfs
debug3: send packet: type 50
debug3: receive packet: type 51
Authenticated with partial success.
debug1: Authentications that can continue: 
password,publickey,keyboard-interactive
debug1: Offering RSA public key: /ssh/keys/secret.key
LOOP

On 23 February 2018 at 01:49, Paul Ellis <openssh-unix-dev at skarsol.com>
wrote:
> We are attempting to use openssh sftp to connect to a server that is
running
> some version of the Axway SFTP server. After a publickey auth completes,
the
> server resends publickey as a valid auth.
That could be potentially correct behaviour in the case where the
server requires several keys to authenticate, although it sounds like
this is not the case here.
> This results in a loop as openssh
> sftp resubmits the publickey information. This seems similar to a
discussion
> in 2014 that terminated with the thought that it might be nice if the
client
> tracked this
>
(https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-August/032800.html).
> Is there any option we can use that will prevent this behavior?
Not currently.
> Attempts to
> contact Axway have failed as we?re not direct customers of theirs and the
> party actually running the server is blaming openssh.
You might want to direct them to RFC4252[1] section 5.1, which covers
partial authentication and says:

"""
   Already successfully completed authentications SHOULD NOT be included
   in the name-list, unless they should be performed again for some
   reason.

"""

[1] https://tools.ietf.org/html/rfc4252

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Thu, Feb 22, 2018 at 08:49:54AM -0600, Paul Ellis
wrote:
> We are attempting to use openssh sftp to connect to a server that is
running
> some version of the Axway SFTP server. After a publickey auth completes,
the
> server resends publickey as a valid auth. This results in a loop as openssh
> sftp resubmits the publickey information. This seems similar to a
discussion
> in 2014 that terminated with the thought that it might be nice if the
client
> tracked this
(https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-August/032800.html).
> Is there any option we can use that will prevent this behavior?
You could try this patch which defers resetting the "tried" flag on
the
pubkeys until the list of authentication methods changes.  I don't have
a server with this behaviour so I'm not sure if it helps (and I'm not
sure it's the right thing to do anyway).

diff --git a/sshconnect2.c b/sshconnect2.c
index 8138e46e0..c97a9d768 100644
--- a/sshconnect2.c
+++ b/sshconnect2.c
@@ -562,8 +562,6 @@ input_userauth_failure(int type, u_int32_t seq, struct ssh
*ssh)
 
 	if (partial != 0) {
 		verbose("Authenticated with partial success.");
-		/* reset state */
-		pubkey_reset(authctxt);
 	}
 	debug("Authentications that can continue: %s", authlist);
 
@@ -1892,12 +1890,15 @@ authmethod_get(char *authlist)
 {
 	char *name = NULL;
 	u_int next;
+	struct ssh *ssh = active_state;
 
 	/* Use a suitable default if we're passed a nil list.  */
 	if (authlist == NULL || strlen(authlist) == 0)
 		authlist = options.preferred_authentications;
 
 	if (supported == NULL || strcmp(authlist, supported) != 0) {
+		/* XXX reset pubkey state */
+		pubkey_reset(ssh->authctxt);
 		debug3("start over, passed a different list %s", authlist);
 		free(supported);
 		supported = xstrdup(authlist);

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Fri, Feb 23, 2018 at 05:01:00PM +1100, Darren Tucker
wrote:
> You could try this patch which defers resetting the "tried" flag
on the
> pubkeys until the list of authentication methods changes.  I don't have
> a server with this behaviour so I'm not sure if it helps (and I'm
not
> sure it's the right thing to do anyway).
I think this is a better way to handle it: keep track of the signatures
sent and mark the successful one to not be used again.  This seems to
behave as expected against a server hacked up to behave more or less as
you describe.

diff --git a/sshconnect2.c b/sshconnect2.c
index 8138e46..3f475d9 100644
--- a/sshconnect2.c
+++ b/sshconnect2.c
@@ -246,6 +246,7 @@ typedef struct cauthmethod Authmethod;
 typedef struct identity Identity;
 typedef struct idlist Idlist;
 
+#define IDENTITY_SUCCESSFUL 0x1000
 struct identity {
 	TAILQ_ENTRY(identity) next;
 	int	agent_fd;		/* >=0 if agent supports key */
@@ -268,6 +269,7 @@ struct cauthctxt {
 	int attempt;
 	/* pubkey */
 	struct idlist keys;
+	struct identity *sent_signed_id;
 	int agent_fd;
 	/* hostbased */
 	Sensitive *sensitive;
@@ -562,6 +564,11 @@ input_userauth_failure(int type, u_int32_t seq, struct ssh
*ssh)
 
 	if (partial != 0) {
 		verbose("Authenticated with partial success.");
+		if (authctxt->sent_signed_id != NULL) {
+			debug3("Marking key %s as successful",
+			    authctxt->sent_signed_id->filename);
+			authctxt->sent_signed_id->tried = IDENTITY_SUCCESSFUL;
+		}
 		/* reset state */
 		pubkey_reset(authctxt);
 	}
@@ -1168,6 +1175,7 @@ sign_and_send_pubkey(Authctxt *authctxt, Identity *id)
 	packet_put_raw(buffer_ptr(&b), buffer_len(&b));
 	buffer_free(&b);
 	packet_send();
+	authctxt->sent_signed_id = id;
 
 	return 1;
 }
@@ -1422,6 +1430,7 @@ pubkey_cleanup(Authctxt *authctxt)
 		free(id->filename);
 		free(id);
 	}
+	authctxt->sent_signed_id = NULL;
 }
 
 static void
@@ -1430,7 +1439,10 @@ pubkey_reset(Authctxt *authctxt)
 	Identity *id;
 
 	TAILQ_FOREACH(id, &authctxt->keys, next)
-		id->tried = 0;
+		if (id->tried != IDENTITY_SUCCESSFUL)
+			id->tried = 0;
+	authctxt->sent_signed_id = NULL;
+
 }
 
 static int

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.