IDP issues

[tscollins-nygc]

We are testing out Globus Auth (XSEDE/oauth-ssh) and have had no problem setting up local map file (globus-acct-map) for user mapping but no luck using idp_suffix. We have a GlobusID account (tscollins@globusid.org) and set 'idp_suffix globus.org' in the globus-ssh.conf but when we try to connect with a client we get the following: [ec2-user@ip-172-30-1-187 ~]$ oauth-ssh -l tscollins ga.nygenome.org Unexpected reply from the SSH service: {"error": {"code": "INVALID_ACCOUNT","description": "You cannot use that local account."}}

[lliming]

It may just have been a typo in your GitHub issue text, but you said you're using a GlobusID account (tscollins@globusid.org) and you're setting the required IDP suffix to "globus.org". These don't match. If you really set the IDP suffix that way, it surely won't work.

I can confirm that the IDP suffix feature (with no mapfile) does work when I authenticate with a University of Chicago identity (me@uchicago.edu), because I've used that configuration on my own SSH servers.

It might be that GlobusID, specifically, is not supported as a required IDP. In some other circumstances, Globus doesn't allow GlobusID identities to be used because the GlobusID IDP doesn't validate identities. (You can claim to be anyone, so there's not much value in regard to knowing who the user with a given globusid.org identity really is.) So, it might be worth trying a different identity provider?

[JasonAlt]

Like @lliming says, it should read 'globusid.org'. When enforcing idp_suffix, it's a straight forward string comparison against the @idp suffix.

[tscollins-nygc]

@lliming when I changed the idp_suffix from globus.org to globusid.org I was able to login with tscollins@globusid.org so it does seem the GlobusID is a supported IDP. Now when I change it from globusid.org to my institutions nygenome.org and try to connect as tscollins@nygenome.org I get the error that started this discussion: Unexpected reply from the SSH service: {"error": {"code": "INVALID_ACCOUNT","description": "You cannot use that local account."}} I have tried 'oauth-ssh -l tscollins ga.nygenome.org' and 'oauth-ssh -l tscollins@nygenome.org ga.nygenome.org' but both failed. I took a look at my managed consents details which are: Allow SSH access to ga.nygenome.org As tscollins@nygenome.org@accounts.google.com, with access to information (e.g. name, email, organization) for all of your account's identities. So I tried that super long username but it failed: oauth-ssh -l tscollins@nygenome.org@accounts.google.com ga.nygenome.org Authorization to this host has failed. Likely causes are no local account or a misconfigured service. Would I need to set the idp_suffix to be 'nygenome.org@accounts.google.com'?

[lliming]

In the oauth-ssh command, you only need -l where is your Unix username on the SSH server. (I assume that's just "tscollins"?

For the SSH/PAM service configuration, I'm pretty sure you do need the really long idp_suffix. The PAM module sees everything after the first '@' as the idp_suffix, so to get a match, you need the whole thing.

[tscollins-nygc]

I edited the globus-ssh.conf file twice adding it once as 'nygenome.org@accounts.google.com' and the second time as '@nygenome.org@accounts.google.com' but both times it failed: oauth-ssh -l tscollins ga.nygenome.org
Unexpected reply from the SSH service: {"error": {"code": "INVALID_ACCOUNT","description": "You cannot use that local account."}}

[tscollins-nygc]

@lliming you said "is your Unix username on the SSH server" so all of this means that there must be a account on the SSH server already for the user to authenticate with, correct? I ask this because one of the things we at the New York Genome Center are hoping to get rid of is maintaining local users accounts and passwords.

[JasonAlt]

There has to be an account that is 'local' to the system meaning that it is available for shell access. It can be an account configured via /etc/passwd, ldap, nis, etc. Basically anything that plugs into the system's getent call will work.

[lliming]

@tscollins-nygc You don't need to maintain local passwords. I create accounts and have the password set to a random, unknown-to-anyone password. Access is only via oauth-ssh.

But yes, you do need to have a Unix account for the individual to login to after they've authenticated with OIDC/OAuth2. As Jason says, that account can be auto-provisioned if that satisfies your needs, or it could be shared with other individuals if that's acceptable for your policies and the individuals aren't likely to interfere with each other's activity.