XCI-495 Design and Security Review Discussions

If I'm understanding the document correctly, XSEDE will operate an OOD instance, which connects to participating XSEDE resources using SSH.

I wasn't able to tell if these SSH connections are cached (per-user, of course) so that OOD operations are multiplexed over a single login. (See: ssh_config(5) ControlMaster)  If no such connection caching takes place, some OOD plugins will create a flood of SSH logins, which is very unfriendly behavior and likely to result in an IP-block.

Should such connection caching be used, subsequent invocations of ssh using the ControlMaster socket will not be subject to any authentication checks (since they're already using an authenticated connection).  As MFA is not required to log in to OOD each time, a new login could gain access to a resource without using MFA if the initial ControlMaster connection is still available for use.  Consequently, MFA would need to be required for each OOD login, not just for establishing an SSH session.

(Different reply, different topic)

Regarding oauth-ssh, since it's being re-visited, can it run its http(s) client transport, json parsing, and any regex operations as an unprivileged user (similar to ssh-nobody, not the actual account)?  None of that has to happen as root, and those operations pose an attack surface that doesn't exist without this module.

For greater adoption across XSEDE resources, I suggest considering the use of an XSEDE SSH-CA instead (see ssh-keygen(1): CERTIFICATES) of an extra PAM module.  These aren't x509 certificates, and support is built-in for all modern OpenSSH servers and clients.  There'd still need to be a vetting and accreditation process for such a service, but in exchange, adding a resource is a matter of adding a file with the CA's public key, and a couple of lines to sshd_config.  I have some proof-of-concept code that takes an OIDC access token and returns a user cert + key blob, if anyone is interested.

Looks good. Just one typo - in F.7, support@xsede.org should instead be help@xsede.org - the support@xsede.org email address doesn't exist. -Jim