SSH Access¶
The login nodes¶
Cluster name | Login node host name | SSH port | VPN needed | Connectivity |
Discoverer (CPU) | login.discoverer.bg | 22 | Yes | IPv4 |
login.bg.discoverer.bg | 2222 | No | IPv4 (BG only) | |
Discoverer+ (GPU) | login-plus.discoverer.bg | 22 | No | IPv4/IPv6 |
Warning
The only user authentication mechanism supported on the login nodes is based on the validation of pre-registered OpenSSH public key (no password-based authentication is supported).
Note
Most modern OpenSSH client applications can interact with a variety of OpenSC-compatible PKCS#11 hardware tokens. Which in turn means that the users of Discoverer HPC, if they want to go that way, can additionally protect their private SSH keys by storing them in the protected memory of hardware tokens, like HSM smartcards. We strongly suggest you adopt HSM devices for your day-to-day SSH activities as a user. If used properly, the HSM devices provide a much stronger protection than the deployment of any 2FA system.
Notes on the database used by the SSH servers to validate the users¶
Discoverer’s user directory, containing all POSIX users and groups, is based on multiple running installations of 389 Directory Server, all acting together to form a cluster that supports a single LDAP directory, and synchronizing and sharing the same content by dint of N-way multi-master replication protocol. Each user account is stored in that LDAP directory as a unique distinguish name (DN) LDAP object. The unique username, along with a copy of the pre-registered OpenSSH public key (as well as some additional information about the user), are attributes to that DN. All POSIX user-level attibutes are part of the DN.
The OpenSSH server, running on both login.discoverer.bg and login-plus.discoverer.bg, interacts with the local SSSD service and a specially designed wrapper program, to verify the presence of the user in the LDAP directory and prove the authenticity of the OpenSSH private key used for the authentication (the key provided to the SSH client program by the user). That type of authentication protocol is considered very secure and surpasses the traditional password-based SSH authentication. Note that OpenSSH key authentication comes with a two-way authentication, whereupon the second component protecting the authentication process is the password that protects the private SSH key on the user’s device.
Helpers¶
Additional and related documents:
- Install SSH Client
- SSH Key Generation
- SSH Public Key Exchange
- Caching Private SSH Keys
- Convert Xshell SSH Key Into New OpenSSH Format and PuTTY format
- Convert PuTTY SSH Key Into OpenSSH Format
- Convert OpenSSH Key Into PuTTY Format
- login.discoverer.bg and login.bg.discoverer.bg - Key Fingeprints
- login-plus.discoverer.bg - Key Fingeprints