SSH Access ========== - `List of the available login nodes (per cluster) <#list-of-the-available-login-nodes-per-cluster>`__ - `Register your SSH key with us <#register-your-ssh-key-with-us>`__ - `Accessing the login nodes <#accessing-the-login-nodes>`__ - `CPU cluster (Discoverer) <#cpu-cluster-discoverer>`__ - `GPU cluster (Discoverer+) <#gpu-cluster-discoverer>`__ - `Notes on the database model used by the SSH servers to validate users <#notes-on-the-database-model-used-by-the-ssh-servers-to-validate-users>`__ - `Helper documents <#helper-documents>`__ - `Getting help <#getting-help>`__ List of the available login nodes (per cluster) ----------------------------------------------- .. _list-of-the-available-login-nodes-per-cluster: .. list-table:: List of the login nodes (per cluster) and the SSH access details * - **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 keys (no password-based authentication is supported). That authentication mechanism, also known as "key-based authentication", is considered very secure and surpasses traditional password-based SSH authentication. .. note:: Most modern OpenSSH client applications can interact with a variety of `OpenSC`_-compatible `PKCS#11`_ hardware tokens. This means that Discoverer HPC users can additionally protect their private SSH keys by storing them inside the protected memory of hardware tokens, such as `HSM and PIV devices`_. We strongly recommend adopting HSM and PIV devices for your day-to-day SSH activities. When used properly, HSM and PIV devices provide much stronger protection than any 2FA system deployment. Register your SSH key with us ----------------------------- .. _register-your-ssh-key-with-us: **To access the login nodes, you need to use key-based SSH authentication, based on the validation of pre-registered OpenSSH public keys.** You need to read the following documents to understand how to create and register your SSH key with us: - :doc:`ssh_key_generation` - :doc:`ssh_key_exchange` We usually guide you towards the on-boarding process and explain how to deal with the key generation and key exchange. Once you provide us with a copy or your OpenSSH key(a), we register them as an authentication token to your user account. From that moment onwards, you can utilize that key(s) for obtaining SSH access to the login nodes of Discoverer and Discoverer+. Check the `Helpers`_ section below for more information regarding key-based SSH access to our login nodes. We strongly recommend using HSM and PIV devices for your day-to-day SSH activities, when possible. See :doc:`ssh_hsm` for more information. Accessing the login nodes -------------------------- .. _accessing-the-login-nodes: **CPU cluster (Discoverer)** .. _cpu-cluster-discoverer: .. toctree:: :maxdepth: 1 ssh_logging_in ssh_logging_in_bg_acad **GPU cluster (Discoverer+)** .. _gpu-cluster-discoverer: .. toctree:: :maxdepth: 1 ssh_logging_in_plus Notes on the database model used by the SSH servers to validate users --------------------------------------------------------------------- .. _notes-on-the-database-model-used-by-the-ssh-servers-to-validate-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. These installations synchronise and share the same content through an `N-way multi-master replication protocol`_. Each user account is stored in that LDAP directory as a unique distinguished 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 of that DN. All POSIX user-level attributes 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 authentication (the key provided to the SSH client program by the user). This type of authentication protocol is considered very secure and surpasses traditional password-based SSH authentication. Note that OpenSSH key authentication comes with two-way authentication, where the second component protecting the authentication process is the password that protects the private SSH key on the user's device. Helper documents ---------------- .. _helpers: Additional and related documents: .. toctree:: :maxdepth: 1 ssh_install_client ssh_key_generation ssh_key_exchange ssh_caching_openssh_key ssh_convert_xshell_key_into_openssh_new_format_key ssh_convert_putty_key_into_openssh_key ssh_convert_openssh_key_into_putty ssh_key_fingeprint ssh_key_fingeprint_plus ssh_hsm yubikey-ssh-piv-setup .. _`389 Directory Server`: https://directory.fedoraproject.org/ .. _`LDAP`: https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol .. _`N-way multi-master replication protocol`: https://access.redhat.com/solutions/273533 .. _`OpenSSH`: https://www.openssh.com/ .. _`SSSD`: https://sssd.io/ .. _`HSM and PIV devices`: https://www.cardcontact.de/ .. _`OpenSC`: https://github.com/OpenSC/OpenSC/wiki .. _`PKCS#11`: https://en.wikipedia.org/wiki/PKCS_11 Getting help ------------ .. _getting-help: See :doc:`help` for more information.