IC87654: UNABLE TO AUTHENTICATE SFTP USER WITH "PASSWORD,PUBLICKEY" IF PASSWORD AUTHENTICATION IS ATTEMPTED BEFORE PUBLIC KEY

3.4.1.8-SterlingSecureProxy-Windows-if0009
3.4.1.8-SterlingSecureProxy-SolarisSPARC-if0009
3.4.1.8-SterlingSecureProxy-Linux-if0009
3.4.1.8-SterlingSecureProxy-Linux_S390-if0009
3.4.1.8-SterlingSecureProxy-HP-if0009
3.4.1.8-SterlingSecureProxy-HP-IA-if0009
3.4.1.8-SterlingSecureProxy-AIX-if0009

APAR status

• Closed as program error.

Error description

• 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
  

Local fix

• STRRTC -354752
  MW/RJ
  Circumvention: None
  

Problem summary

• 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.
  

Problem conclusion

• Updated the SSH toolkit, which contains the fix to correctly
  handle the password,publickey authentication order.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  STR SECURE PROX

• Fixed component ID

  5725D0300

Applicable component levels

• R341 PSY

     UP