L'option Match de sshd_config

Aujourd’hui je vais vous inviter à vous intéresser à une option méconnue de sshd_config et pourtant qu’elle est bien : Match.

Voici les explications en Anglais tiré du man sshd_config de Debian 8 (c’est la même chose que le man sshd_config de Ubuntu 15.10).

Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. If a keyword appears in multiple Match blocks that are satisfied, only the first instance of the keyword is applied.

The arguments to Match are one or more criteria-pattern pairs or the single token All which matches all criteria. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).

The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. “192.0.2.0/24” or “3ffe:ffff::/32”. Note that the mask length provided must be consistent with the address – it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, “192.0.2.0/33” and “192.0.2.0/8” respectively.

Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AcceptEnv, AllowAgentForwarding, AllowGroups, AllowStreamLocalForwarding, AllowTcpForwarding, AllowUsers, AuthenticationMethods, AuthorizedKeysCommand, AuthorizedKeysCommandUser, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAcceptedKeyTypes, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, IPQoS, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTTY, PermitTunnel, PermitUserRC, PubkeyAcceptedKeyTypes, PubkeyAuthentication, RekeyLimit, RevokedKeys, RhostsRSAAuthentication, RSAAuthentication, StreamLocalBindMask, StreamLocalBindUnlink, TrustedUserCAKeys, X11DisplayOffset, X11Forwarding and X11UseLocalHost.

Ok je vous ai déjà perdu, restez encore un peu, je vais essayer de vous tirer une larme d’émerveillement. Voici le block que j’utilise chez moi. Concrètement ça fait quoi ? Concrètement je ne peux me connecter en root que si mon adresse IP est sur le réseau local (192.168.1.0/24) ou l’adresse IP fixe du boulot (134.22.128.63), aucune autre adresse ne pourra se connecter en root. Sympa non ?

Match Address 192.168.1.0/24,134.22.128.63
PermitRootLogin yes

Match Address *
PermitRootLogin no

Voici le block que j’utilise au boulot. Concrètement ça fait quoi ? La même chose, seules les adresses IP des membres du service Informatique peuvent se connecter en root sur les serveurs.

Match Address 191.168.1.2,192.168.1.3,192.168.1.4
PermitRootLogin yes

Match Address *
PermitRootLogin no

Arrivé là normalement je me fais caillasser « non mais t’as pas honte, t’es sysadmin, tu te connectes directement en root via SSH ! ». Non j’ai même pas honte… et j’aime ça ! Mais bon je vais prendre d’autres exemples pour calmer la foule déchainée.

Voici le block afin de permettre la connexion SSH de l’utilisateur rambo uniquement à partir du poste 192.168.1.22.

Match Address 192.168.1.22
AllowUsers rambo

Voici le block afin que l’utilisateur rambo ne puisse pas utiliser le X11Forwarding.

Match User rambo
X11Forwarding no

On peut complexifier ou sécuriser un peu plus l’exemple précédent. Cette fois John rambo peut utiliser le X11Forwarding mais uniquement à partir d’un poste précis.

Match User rambo Address 192.168.1.22
X11Forwarding yes

Match User rambo Address *
X11Forwarding no

Voici le block afin de permettre à papanoel de travailler dans un environnement sécurisé.

Match User papanoel Host polenord
Banner /home/augier/merciderespectermaviepriveesinonjemords.txt
X11Forwarding no

Les possibilités sont multiples et peuvent répondre à bien des problématiques. Pour ceux qui ne savent pas lire ou qui n’ont pas pris soin de le faire (If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file) donc le block se met à la fin du fichier sshd_config. Avant Ansible j’utilisais ça dans un script à titre d’exemple.

echo -e "\nMatch Address 192.168.1.2,192.168.1.3,192.168.1.4\nPermitRootLogin yes\n\nMatch Address *\nPermitRootLogin no" >> /etc/ssh/sshd_config

Je vous rappelle que pour redémarrer le service SSH c’est systemctl restart sshd et qu’il faut vérifier ensuite qu’il est bien démarré avec systemctl status sshd afin de s’éviter de s’enfermer dehors à cause d’une erreur dans sshd_config.

Bon week-end les filles !