Direct links to fixes
Closed as program error.
There appears to be a problem in the way SSP handles "Password and Key" authentication for SFTP connection, specifically it seems to be related to the order in which the Client attempts to authenticate. To recreate the problem first define a SSP user with a password and add a SSH Public Key into SSP Authorized user store,then using a OpenSSH client on Unix issue sftp -i .ssh/id_rsa -oPort=20022 -oPreferredAuthentications=publickey,password martin@localhost The uses the default order for PreferredAuthentications and everything works as expected. The problem comes when you switch the authnetication method order and perform the password authentication first ahead of the public key authentication sftp -i .ssh/id_rsa -oPort=20022 -oPreferredAuthentications=password,publickey martin@localhost This time the connection fails with "Authenticated with partial success" and keeps prompting for the password debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 2f:e3:48:2d:15:f2:bb:00:9b:1b:c1:23:89:4e:b4:2c debug3: put_host_port: [127.0.0.1]:20022 debug3: put_host_port: [localhost]:20022 debug3: load_hostkeys: loading entries for host "[localhost]:20022" from file "/home/martin/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/martin/.ssh/known_hosts:11 debug3: load_hostkeys: loaded 1 keys debug1: Host '[localhost]:20022' is known and matches the RSA host key. debug1: Found key in /home/martin/.ssh/known_hosts:11 debug2: bits set: 524/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: .ssh/id_rsa (0x2af5c3b73cb0) debug1: Authentications that can continue: password,publickey debug3: start over, passed a different list password,publickey debug3: preferred password,publickey debug3: authmethod_lookup password debug3: remaining preferred: publickey debug3: authmethod_is_enabled password debug1: Next authentication method: password martin@localhost's password: debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64) debug2: we sent a password packet, wait for reply Authenticated with partial success. debug1: Authentications that can continue: password,publickey Permission denied, please try again. martin@localhost's password: If we check the Maverick log in SSP we can see that the password authentication worked and it is the key authentication that is still to be done, but SSP is actually requesting a password still. We double checked using a couple of Exits and it behaves the same when password authentication precedes public key authentication we just see the password (BARCLAYS_SSH_NOPW) exit being invoked
STRRTC -354752 MW/RJ Circumvention: None
SFTP client unable to authenticate using Password,PublicKey When an SFTP client connects with the Preferred Authentication order of Password, followed by PublicKey, the adapter prompts them for password a second time rather than authenticating their public key. Actually, the SFTP adapter mistakenly changes the authentication to Password,Password,Password,PublicKey, so if the client enters their password three times, the public key authentication will take place and the client will login. If the client uses the order of PublicKey,Password (which is normal), the authentication works.
Updated the SSH toolkit, which contains the fix to correctly handle the password,publickey authentication order.
Reported component name
STR SECURE PROX
Reported component ID
NoSpecatt / Xsystem
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
STR SECURE PROX
Fixed component ID
Applicable component levels