SSH Access
==========

The login nodes
---------------

.. list-table:: List of 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.


Accessing the login nodes
.........................

**CPU cluster (Discoverer)**

.. toctree::
   :maxdepth: 1

   ssh_logging_in
   ssh_logging_in_bg_acad

**GPU cluster (Discoverer+)**

.. toctree::
   :maxdepth: 1

   ssh_logging_in_plus

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:

.. 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

.. _`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 smartcards`: https://www.cardcontact.de/
.. _`OpenSC`: https://github.com/OpenSC/OpenSC/wiki
.. _`PKCS#11`: https://en.wikipedia.org/wiki/PKCS_11