Paul Ellis
2018-Feb-22 14:49 UTC
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
Darren Tucker
2018-Feb-23 05:35 UTC
Attempts to connect to Axway SFTP server result in publickey auth loopin
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.
Darren Tucker
2018-Feb-23 06:01 UTC
Attempts to connect to Axway SFTP server result in publickey auth loopin
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.
Darren Tucker
2018-Feb-23 11:58 UTC
Attempts to connect to Axway SFTP server result in publickey auth loopin
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.
Maybe Matching Threads
- Attempts to connect to Axway SFTP server result in publickey auth loopin
- [Bug 2642] New: [sshconnect2] publickey authentication only properly works if used first: pubkey_prepare doesn't work after pubkey_cleanup
- Password authentication problem with 6.4p1 (and later) clients: An analysis
- Axway XFB sftp server & no-more-sessions@openssh.com
- [Bug 2599] New: Overly verbose partial authentication