Admin. sys. Nos oignons (version publique) > Services > Debian > ssh

Machines

ssh est installé (ou le sera) sur toutes les machines. Sur bulbe, plusieurs autres services ou applications reposent sur ou interagissent avec ssh:

Fichiers

Configuration

/etc/ssh/sshd_config
le fichier de configuration du serveur. En principe le seul qu'on ait à modifier.

Clefs

/etc/ssh/ssh_host_*_key
/etc/ssh/ssh_host_*_key.pub
les clefs privées et publiques du serveur. Une bonne pratique consiste à en communiquer les empreintes aux personnes auxquelles on ouvre un accès sur une machine, afin qu'elles puissent s'assurer que leur trafic n'est pas détourné.
/home/${user}/.ssh/authorized_keys
trousseau de clefs publiques de ${user} (une clef par ligne), nécessaire pour se connecter.

Configuration

Dans /etc/ssh/sshd_config:

  • On interdit la connexion par root et l'authentification par mot de passe :

      PermitRootLogin no
  PasswordAuthentication no

    Cela signifie que l'authentification par paire de clefs publique/privée est la seule possible (les autres sont désactivées).
    Le paramètre PermitRootLogin no est donc facultatif, puisque root n'a pas de clef SSH.

  • On désactive le trasfert de sessions X11 :

      X11Forwarding no

    Le jeu des dépendances de paquets peut amener à ce qu'un serveur X soit installé sur une machine. Ce paramètre empêche une redirection de X qui pourrait permettre une attaque côté client.

  • On restreint le choix d'algorithmes de chiffrement et d'authentification à ceux considérés sûrs (parmi ceux disponibles).

      Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
  MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
  KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

  • On durcit la séparation des privilèges, pour sshd, avec une option plus sûre mais moins portable que celle par défaut.

      UsePriviledgeSeparation sandbox

  • Enfin, on supprime les clefs DSA.

Accès SFTP restreint

Sur la VM de bureautique, pour permettre aux personnes partageant des tâches administratives au sein de l'association d'accéder par sftp à un espace de stockage qui leur est réservé, et de n'accéder qu'à cet espace, le serveur a fait l'objet d'une configuration spécifique (voir aussi: Stockage de fichiers):

Subsystem sftp internal-sftp

Match Group admin
    AuthorizedKeysFile /etc/ssh/role_keys/%u
    ChrootDirectory /srv/association
    ForceCommand internal-sftp -u 027
    AllowTcpForwarding no

Le choix de internal-sftp dans la directive Subsystem est requis par ce qui suit.

La directive Match permet d'imposer à un user ou à un groupe donné une configuration du service différente de ce qui est défini dans le reste du fichier. Les directives Match doivent figurer à la fin du fichier.

La directive AuthorizedKeysFile /etc/ssh/… permet de versionner les clefs d'accès au service.

Les directives ChrootDirectory DIR et ForceCommand internal-sftp [OPTIONS] fonctionnent de pair. Elles permettent de restreindre l'accès au système de deux façons:

  1. Seuls les accès par sftp sont autorisés.
  2. Le répertoire de chroot devient la racine au niveau du client, qui ne peut donc pas naviguer dans le reste du système. Le répertoire de chroot doit avoir le mode 0755 et doit être propriété de root:root.

Procédures