GSI-enabled OpenSSH 7.6p1

[e-sakane]

To Whom It May Concern,

I am Eisaku Sakane, a researcher of National Institute of Informatics (NII), Japan.
I submit an issue according to an advice that I took from Dr. Jim Basney at 2019 Intetnet2 Global Summit in Washington DC.

NII supports the GSI middleware because HPCI project that is a distributed high-performance computing infrastructure in Japan uses the GSI for single sign-on to supercomputers and storages.

As a result of the GSI support, we have GSI-enabled OpenSSH 7.6p1. This includes:

• included the HPN-SSH patch (openssh-7_6_P1-hpn-14.14.diff)
• fixed a connection failure problem if multi-thread AES-CTR ciphers used
• fixed an inappropriate path problem of gsiscp (it may be useful for developers)
• fixed errors in test scripts caused by setting "null" as hostkey algorithm
• modified multiplex.sh to skip the transfer test when a system-installed gsiscp does not found (it also may be useful for developers)

We would like to share our gsi-openssh-7.6p1 among the Grid Community.
What do you think of this?

Thank you in advance.

[fscheiner]

Sorry for not replying earlier, but missed the time.

Thanks for your interest. Say, have you also followed #67? For general information about status of GSI-OpenSSH in the GCT, please have a look at this thread which extends over more than half a year. Please also feel free to subscribe to this list and participate in the discussions.

@jbasney @msalle @matyasselmeci @ellert @brianhlin
Please correct if I'm wrong somewhere in the following. Quite some time has already passed since we last discussed this.

AFAIR we'd like to drop the HPN-SSH (and iSSHD) patches for the GCT to keep GSI-OpenSSH in the GCT simple and compatible with the version in EPEL/Fedora. HPN-SSH is nice but the GCT also offers GridFTP which is much better suited for high-performance file transfers, although HPN-SSH has the advantage to enable well-known tools like scp/sftp to yield good file transfer performance on WANs and LANs, which is tempting for users.

Back to GSI-OpenSSH in the GCT: Since the start of the GCT the "shipped" (quoted because up until #63 the OpenSSH source code and additional patches were downloaded from external sources on the fly during build) GSI-OpenSSH beame outdated. It's still based on OpenSSH Portable 7.5p1 . As our main target OS is RHEL (and compatible Linux distributions) and Mattias Ellert already provides up to date versions of GSI-OpenSSH for these via EPEL/Fedora based on the maintained OpenSSH version of the respective OS release - so most users can just install a maintained version of GSI-OpenSSH on their RHEL compatible OS - the outdated GSI-OpenSSH in the GCT is actually not as bad as it might look. hence also not much effort went into fixing that situation.

Back to your request: As we'd like to drop the HPN-SSH patches, I'm unsure how we could combine our efforts. Maybe we can reconsider if we'd know what the perspective of your patches are:

• How long do you plan to support these?
• Will you forward-port the patches to current OpenSSH versions?
• Will you rebase your patches on the latest HPN-SSH patches from SourceForge?

But there could still be a big obstacle ahead: I seem to also remember that the HPN-SSH patches aren't compatible with the OpenSSH patches used by EPEL/Fedora. So they might not be combined.

[e-sakane]

I apologize for the late reply.

Thank you for your polite explanation of current status. I understood the status.

Since we have used the GSI-OpenSSH provided by globus.org so far, we updated GSI-OpenSSH without dropping the features such as the HPN-SSH and iSSHD. However, we do not mean to strongly need those features. Personally, I think that the HPCI should move to use the GSI-OpenSSH in the GCT.

We would like to contribute to the GCT in another way.

Thank you.

[fscheiner]

Fixed with #108.