Authenication to Co:z SFTP Server Using a RACF Keyring

[jacobsm]

We've successfully tested SFTP using a RACF Keyring going from zOS to an external server. Is there a documented procedure to go the other way, i.e. store the remote users public key in a RACF keyring instead of in the authorized_keys file?

Mark jacobs

[dovetail]

Yes, this is documented in the IBM Ported Tools User's Guide.

However, the way it works is that you add a line to $HOME/.ssh/authorized_keys that points to the RACF keyring+label.

I really don't see much benefit to doing this - isn't it just as easy to put the public key directly in $HOME/.ssh/authorized_keys ? There is no harm in anyone "seeing" the public key, although you have to make sure that you use the correct permissions to protect the authorized keys file from updates except by the owning userid - but you would need this anyway, eh?

BTW - there will be a two-part webinar on June 12 & 19 on IBM Ported Tools OpenSSH Keys -


IBM Ported Tools for z/OS: OpenSSH - Key Authentication
Space is limited.
Reserve your Webinar seat for part 1 now at:
https://www3.gotomeeting.com/register/956665254

IBM Ported Tools for z/OS: OpenSSH is IBM's port of the popular open source SSH product for z/OS, which is used by the Co:Z Toolkit. In part 1 of this webinar, we will discuss OpenSSH authentication - both host and user authentication. You will learn how to manage host keys as well use keys for user authentication.
Title: IBM Ported Tools for z/OS: OpenSSH - Key Authentication
Date: Tuesday, June 12, 2012
Time: 2:00 PM - 3:00 PM EDT


IBM Ported Tools for z/OS: OpenSSH - Using Key Rings
Space is limited.
Reserve your Webinar seat for part 2 now at:
https://www3.gotomeeting.com/register/275261614

IBM Ported Tools for z/OS: OpenSSH is IBM's port of the popular open source SSH product for z/OS, which is used by the Co:Z Toolkit. In part 2 of this webinar, we will discuss the benefits of using RACF (or equivalent) key rings with OpenSSH. You will learn how to use RACF commands to create keys, certficiates, and key rings and how to use them with Ported Tools and Co:Z.
Title: IBM Ported Tools for z/OS: OpenSSH - Using Key Rings
Date: Tuesday, June 19, 2012
Time: 2:00 PM - 3:00 PM EDT

[jacobsm]

I see your point, but we have too many people/userids with superuser access rights, which makes it trivial to utilize public key authentication, with the public key stored in the authorized_keys file, to spoof RACF userids. I've tried it myself and the process works. The method of doing so will be left as a exercise for the reader.

But seriously it is a big hole, but its not really able to categorized as a security/integrity problem since the installation has control on who can get superuser rights.

By forcing all server -> zOS userid authentication back into RACF where it belongs, the spoofing problem is greatly reduced.

Before I open up an SR with IBM do you know if there's a setting within the OpenSSH product to force the public keys to be stored in a keyring, not allowing any public keys in the authorized_keys file to be used for authentication?

[dovetail]

Here is one approach to preventing use of individual user's authorized_keys files

1) Update /etc/ssh/sshd_config and add this:

Code: Select all

AuthorizedKeysFile /etc/ssh/global_authorized_keys

this new file will be used by *all* users for their authorized keys file. This may or may not be acceptable to you. If not, you could use the "Match" statement in sshd to form exceptions for specific users.
Don't do this unless you understand the implications (and carefully do step 3 !)

2) in this new file, put one of these two lines:

Code: Select all

zos-key-ring-label="SSHRING SSH01"

or

Code: Select all

zos-key-ring-label="* SSH01"

this will set it up so that the certificate with the label "SSH01" in the key ring "SSHRING" will contain the SSH public key used to authenticate this user. If you use the second example, with the "*" for a key ring name, then this means to use the "virtual key ring", which IMO is a little simpler.

Note: you could even have multiple lines, pointing to alternate keyring/labels, which might be handy since the certificates could expire and need to be cycled.

3) this new file must be owned by root (uid=0) and must be protected with permissions bits, and even better to use an ACL so that it can only be updated after RACF says so. This should be done for all /etc/ssh config files if you want to keep your superusers at bay a little. Of course, one can argue that a superuser can always find a way....

4) set up certificates for each user id with the same label (and ring name if not the virtual ring). Key ring and label names are scoped under the owning userid, so each user will have their own, but the names will all match up.

So, for example, if the userid is "KIRK", then you would have a certificate owned by KIRK with the matching key ring and label name.

Its a little tricky to take a OpenSSH-format public key and make an X.509 certificate that can be imported into z/OS.
Here is a post with the details: http://dovetail.com/forum/viewtopic.php?f=8&t=1241