We have Co:Z connecting to a Linux server from one z/OS LPAR and replicated the RACF digital certificate to 4 other LPARS. On those LPARS, we are getting the following error. Please provide some guidance as to what the issue might be.
SafSshAgentŽT: -> signSHA1()
SafSshAgentŽE: gsk_sign_data error: Key not supported by encryption or signature algorithm (0x03353030)
SafSshAgentŽT: <- signSHA1()
SafSshAgent error
SafSshAgent error
Last edited by slhussey on Mon Nov 17, 2014 10:42 am, edited 1 time in total.
Re: SafSshAgent error
This error indicates that the z/OS userid does not have the required access to the key ring.
See item #2 on this page for the required SAF/RACF rules: http://dovetail.com/docs/coz/auth.html#auth-racf
This assumes that the key ring is owned by the userid.
PS> You can also use a specific key ring owned by another userid, but this requires different SAF rules.
See starting Slide 18 "Permissions for using a Key Ring" in this presentation for more information:
http://dovetail.com/docs/sftp/ssh_keys_ ... -06-19.pdf
The recording of this presentation is also available on our webinars page: http://dovetail.com/webinars.html
See item #2 on this page for the required SAF/RACF rules: http://dovetail.com/docs/coz/auth.html#auth-racf
This assumes that the key ring is owned by the userid.
PS> You can also use a specific key ring owned by another userid, but this requires different SAF rules.
See starting Slide 18 "Permissions for using a Key Ring" in this presentation for more information:
http://dovetail.com/docs/sftp/ssh_keys_ ... -06-19.pdf
The recording of this presentation is also available on our webinars page: http://dovetail.com/webinars.html
Re: SafSshAgent error
I have had our CSO confirm that the permissions listed in the PDF document and on the webpage are the same between the 2 LPARs (the working one and the failing one). Is there something I can activate to display the failing permission?
Re: SafSshAgent error
Depending on your RACF configuration, you might be getting ICH408I messages in the job log. Otherwise, the RACF configuration might route violations to the audit log or maybe not log them at all.
I can tell you that this error and reason code 0x03353030 from the IBM gsk_sign_data error is EXACTLY what you get when you don't have the required SAF/RACF permissions for the key ring.
Are you using a key ring owned by the userid that is running the job?
This is the normal case, and is covered by item #2 on this page for the required SAF/RACF rules: http://dovetail.com/docs/coz/auth.html#auth-racf
I can tell you that this error and reason code 0x03353030 from the IBM gsk_sign_data error is EXACTLY what you get when you don't have the required SAF/RACF permissions for the key ring.
Are you using a key ring owned by the userid that is running the job?
This is the normal case, and is covered by item #2 on this page for the required SAF/RACF rules: http://dovetail.com/docs/coz/auth.html#auth-racf
Re: SafSshAgent error
Our RACF configuration is for ICH messages to appear in our joblog, but we are not seeing any.
The key ring is owned by a different ID and is defined as a SITE key.
The error is occurring within SSH. I activated SSH logging with -vv and the sequence of messages are the same between the 2 LPARs up to:
debug2: input_userauth_pk_ok: fp 63:ff:ca:a8:9d......
The next message on the successful LPAR is: debug1: Authentication succeeded (publickey).
The next message on the failing LPAR is: SafSshAgentŽE: gsk_sign_data error: Key not supported by encryption or signature algorithm (0x03353030)
debug1: Trying private key: /u/sh1849/.ssh/id_rsa
debug1: Trying private key: /u/sh1849/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Does this narrow the options that might cause the problem?
The key ring is owned by a different ID and is defined as a SITE key.
The error is occurring within SSH. I activated SSH logging with -vv and the sequence of messages are the same between the 2 LPARs up to:
debug2: input_userauth_pk_ok: fp 63:ff:ca:a8:9d......
The next message on the successful LPAR is: debug1: Authentication succeeded (publickey).
The next message on the failing LPAR is: SafSshAgentŽE: gsk_sign_data error: Key not supported by encryption or signature algorithm (0x03353030)
debug1: Trying private key: /u/sh1849/.ssh/id_rsa
debug1: Trying private key: /u/sh1849/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Does this narrow the options that might cause the problem?
Re: SafSshAgent error
Issue resolved. The problem was that the digital certificate was exported/imported using the RACDCERT command without a PASSWORD option. This caused the private key to NOT be exported/imported.
Re: SafSshAgent error
Well done. That's a new one for me 
I suppose that you would have seen that there was no private key if you would have done a RACDCERT LIST on the certificate. Or maybe you did this and compared two systems to find the problem?
I suppose that you would have seen that there was no private key if you would have done a RACDCERT LIST on the certificate. Or maybe you did this and compared two systems to find the problem?
Re: SafSshAgent error
Since it is a SITE key and shared, I do not have authority to LIST it. I read a document from SHARE about RACF digital certificates and it had the command for EXPORT, so I read the TSO HELP for that and requested that CSO confirm what they had done. They found it and fixed it.