As of September 1, 2022, the XSEDE platform transitioned to the newly-funded ACCESS platform. There are manifold changes to terminology and policy that XSEDE users will encounter in this transition, but one important one is this:
The SSOHub relies on several legacy services that use hardware and software that are no longer supported. ACCESS does not have resources to update and replace hardware, nor resources to care and feed it, nor resources to keep unsupported software running.
With the SSOHub deprecated, each ACCESS Resource Provider (or RP) is responsible for implementing and documenting direct connection via SSH by ACCESS users to their resources.
The XSEDE SSOHub was an SSH server to which an XSEDE user could connect using his or her XSEDE username, password, and DUO two-factor code. Once on the SSOHub, GSISSH could be used to connect to an XSEDE system (like DARWIN) without requiring a password.
After consultation with XSEDE staff and other SPs while implementing DARWIN, the SSOHub was leveraged as a secure gateway for password-based access to the system. An established accounting system with 2FA via DUO made that gateway a well-secured solution. Once an XSEDE user initially connected to DARWIN via the SSOHub, the user could install SSH key(s) for password-less direct access to DARWIN thereafter. In fact, we felt this design such a strong solution that no XSEDE account on DARWIN has ever had a password associated with it: UD had no user-facing services that required XSEDE user authentication (web apps, etc.), the SSOHub gated password-oriented access, and users could leverage SSH keys for direct access to DARWIN.
Unfortunately, without local passwords for ACCESS users the absence of the SSOHub means they will not be able to make the initial connection to DARWIN in order to install SSH keys. New ACCESS accounts on DARWIN and users who had not installed SSH keys once DARWIN transitioned to ACCESS are unable to SSH directly to DARWIN as of September 1, 2022.
As of September 1, 2022, ACCESS users with an account on DARWIN who did not install an SSH key will need to set a password on their account. ACCESS users who did install an SSH key are also encouraged to set a password using the password reset web application at https://idp.hpc.udel.edu/access-password-reset/.
The application starts by directing the client to the CILogon authentication system where the "ACCESS CI (XSEDE)" provider should be selected. If successful (and the client has an account on DARWIN), the application next asks for an email address to which a verification email should be sent; the form is pre-populated with the email address on-record on DARWIN for the client's account. The client has 15 minutes to follow the link in that email message to choose a new password. The form displays information regarding the desired length and qualifications of a valid password. If the new password is acceptable, the client's DARWIN password is set and SSH access via password should become available immediately.
ACCESS users on DARWIN can use the password reset web application to reset a forgotten password, too.
Every DARWIN user's home directory contains a subdirectory named .ssh
. Typically, this directory looks like this:
$ ls -l ~/.ssh total 38 -rw-r--r-- 1 username everyone 406 Sep 20 2021 authorized_keys -rw------- 1 username everyone 1675 Sep 20 2021 id_rsa -rw-r--r-- 1 username everyone 406 Sep 20 2021 id_rsa.pub -rw-r--r-- 1 username everyone 197 Sep 22 2021 known_hosts
When the user account was created, the RSA key-pair (id_rsa
is the private key, id_rsa.pub
is the public key) was generated to facilitate key-based authentication between nodes inside the DARWIN cluster. The presence of the public key found in id_rsa.pub
in the authorized_keys
file is what grants that access.
Adding other public keys to the ~/.ssh/authorized_keys
file (one per line) enables key-based authentication when the associated private key initiates the connection to DARWIN. All DARWIN ACCESS users are encouraged to set up key-based authentication in this manner.
The following pages may be helpful for users who are new to key-based SSH authentication: