Discuss how we will engage others in XSEDE to evolve existing interactive login capabilities.
Which use cases does this concern?
CAN-04 - Interactive login
Most high-performance computing and high-throughput computing services require users to open a remote terminal session on a login server. This is a vital access mode for shared computing services.
CAN-06 - Authenticate with an application
An individual needs to securely share his or her identity with an application in order to use a feature that requires authorization.
HPC-01 & HPC-02
HTC-01 & HTC-02
DA-01 through DA-05
VIS-01 through VIS-05
CB-08 - Use XSEDE SSO with campus login servers A campus IT administrator wants to allow XSEDE-registered researchers to login to campus login servers (remote command shell) using their XSEDE usernames/passwords.
RC-03? - Install software on a resource for use by a research community
Which use cases does this NOT concern?
CAN-01 - Run a remote job
SGW-03 - Science Gateway community execution management
SP login nodes with GSI OpenSSH server and Globus client (from Globus)
SSO hub with OpenSSH using Kerberos and xsede-user-tfa PAM modules (from XSEDE) and Globus GSI OpenSSH client (from Globus)
Any command line client running any SSH client accessing the SSO hub
Possible future components:
SP login nodes with GSI OpenSSH server and Globus client (from the Grid Community Toolkit)
Q: Who would be providing the support for this software (GSI* from GCT)?
Any command line client running any SSH client with the Globus SDK (a.k.a. Globus Auth OpenSSH)
Any command line client running any SSH client with web based login service (a.k.a. Lee's pilot)
Jupyter based browser login client
Lee thinks Jupyter isn't a login client. (It doesn't provide a terminal interface on the compute system.) True or false?
If the above is true, is the idea that users will no longer need terminal interfaces on XSEDE systems? That seems unlikely given the current systems.
We will probably need to meet with these people?
XCI management - What are we supposed to be doing? What is our mandate/scope for this?
E.g., just get through XSEDE-2, or look farther ahead?
SP PIs - They design & maintain the systems XSEDE provides access to and know the intended uses, users
Campus login server admins (CB-08) - They design campus login services & asked for SSO Hub access
Heavy SSH users on current XSEDE systems (SSO hub, others?)
Q: Should we also ask people who do computational science via other interfaces (Open OnDemand, Jupyter, cloud systems) how they do it and how they think it should be done on other systems?
With what purpose?
Confirm how SSH is currently used/needed on XSEDE SP systems, campus research systems.
Find out about future/upcoming systems and their interfaces.
Get a sense of the future needs for SSH access and how folks would LIKE it to work.
We don't know where SSH access is going and need to engage users and XSEDE stakeholders to identify a path forward.
Needs that are driving this discussion:
Products that have vendor/community support
Interfaces that simplify interactive access and that users prefer to use
Modern, standard, and ubiquitous user authentication and authorization mechanisms
Keep XSEDE innovative and leading in usability and ease of access thru the end of the program
Ensure XSEDE investments in improving SSH access matches user and SP needs and broader community
Identify what the future of SSH login is
Next steps / actions
We will survey users and SPs and hold a PEARC19 BOF so that by early Fall 2019 we have the input needed to prepare an XSEDE SSH futures plan.