Fliquer ses collègues avec SSH 😜

Julien Briault -

Mais faut avouer, lorsque l'on bosse à plusieurs sur un serveur GNU/Linux, c'est toujours chiant de devoir chercher qui blâmer quand une connerie est faite (un redémarrage de service qui ne fallait pas ou encore la modification d'une configuration).

Surtout quand on partage un compte commun, par exemple "admin" pour tous les admins... 😉️

Cet article va expliquer comment avoir un résultat similaire à celui-ci:

Jul 29 18:18:23 NOM_SERVEUR [ADRESSE_IP] admin (julien.briault):/home/admin[14932]: sudo tail -f /var/log/shell.log

De base, il est quasiment impossible de savoir exactement qui fait quoi, on n'a qu'à notre dispo la commande history, qui est très limitée car on ne sait pas qui fait quoi et ni à quelle heure de base (sauf si vous jouez avec la variable $HISTTIMEFORMAT).

Il faut absolument que vos utilisateurs utilisent des clés SSH et non pas de mot de passe, d'ailleurs si vous désactivez cette dernière option, ils n'auront pas besoin de connaître le mot de passe, ce qui simplifie la tâche lors du départ d'un collaborateur!

Générer la paire clé publique/privé et l'envoyer à notre serveur cible

A vrai dire, rien de bien compliqué, pour commencer, on va générer nos clés. Mais avant ça on va se pencher sur les différents types de clés.

Les clés proposées par OpenSSH, sont RSA, DSA, ECDSA et ED25519. Vous pouvez déjà commencer par oublier les clés types DSA, depuis la version 7 d'OpenSSH, ce type est déprécié par cause de faille de sécu... D'ailleurs sur les versions récentes, ce type n'est pas dispo.

Les clés RSA (4096 bits) sont compatibles avec tout, après, c'est un type breveté par le MIT donc la NSA n'est sûrement pas innocente derrière tout ça.

Source intéressante: ici.

À noter que les clés RSA doivent être de taille 2048 bits (par défaut) au minimum si vous souhaitez un minimum de sécu... Mais bon, ça reste faillible!

Et le plus strong est... ED25519, outre son nom imprononçable, il est le type le plus ŝur, celui que je vous conseille par ailleurs. Mais valable que sur les nouvelles bécanes!

On va lister les clés dispo pour notre utilisateur courant:

for key in ~/.ssh/id_*; do ssh-keygen -l -f "${key}"; done | uniq

On va maintenant donc pouvoir générer nos clés publique/privé:

# Pour la compatibilité
ssh-keygen -t rsa -b 4096 -C votre@email.com

# Pour la sécurité (machines récentes, celle que je préfère)
ssh-keygen -t ed25519 -C votre@email.com
Sur les clés type ED25519, la taille est fixe de 256 bits.

Ensuite on pousse notre clé vers notre serveur distant:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@NOM_SERVEUR

La conf du serveur SSH

Je pars du fait que vous n'êtes pas spécialement friand de l'authentification SSH avec mot de passe. Si ce n'est pas le cas, appliquez la configuration suivante:

sudo vi /etc/ssh/sshd_config

Puis, modifiez les valeurs suivante:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitUserEnvironment yes
UsePAM no

Sans oublier de redémarrer le service SSH! 

sudo systemctl restart ssh

On attaque la conf!

Allez let's go, maintenant que tous les prérequis sont en place, on va attaquer la configuration.

On édite le fichier suivant:

sudo vi /etc/profile

Puis on y ajoute à la toute fin:

SSH_IP_CLIENT=$(printf "$SSH_CONNECTION" | awk '{print $1}')
readonly PROMPT_COMMAND='history -a >(logger -i -p local5.info -t "[via: $SSH_IP_CLIENT] $USER ($REALUSER):$PWD"); history -w;'

Lorsqu'on envoie notre clé au serveur distant, celle-ci est ajoutée au fichier ~/.ssh/authorized_keys. Donc pour ce faire, on va donc modifier ce fichier pour y ajouter une variable d'environnement.

environment="REALUSER=julien.briault" ssh-ed25519 AAAA[...] mon@email.com

Maintenant ça fait, on va modifier la configuration de syslog.

sudo echo "local5.*   /var/log/shell.log" > /etc/rsyslog.d/shell.conf

Puis dans le fichier /etc/rsyslog.conf ou /etc/rsyslog.d/50-default.conf, remplacer:

*.*;auth,authpriv.none     -/var/log/syslog`

Par:

*.*;auth,authpriv.none,local5.none     -/var/log/syslog`

Une fois que c'est fait, il faut redémarrer le service syslog.

sudo systemctl restart syslog

Quand tout ça c'est fait, on va créer un logrotate pour avoir de beaux logs qui tournent tous les jours, c'est plutôt pas mal hein!

/var/log/shell.log {
    rotate 30
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
    invoke-rc.d rsyslog rotate > /dev/null
    endscript
    create 644 root adm
}

Il ne vous restera plus qu'à vos déconnecter et vous reconnecter. Puis utiliser la commande suivante pour admirer le travail!

sudo tail -f /var/log/shell.log

En complément

Vous pouvez tout d'abord ajouter ce fameux compte partagé en tant que sudoer, pour ce faire:

su -
usermod -aG sudo admin

Une fois qu'il l'est, on peut désactiver l'accès au compte root, pour ce faire il suffit de remplacer dans /etc/passwd:

root:x:0:0:root:/root:/bin/bash

Par:

root:x:0:0:root:/root:/usr/sbin/nologin

Comme ça, ça vous évitera d'obtenir des logs équivalent à:

Jul 30 14:30:50 NOM_SERVEUR [ADRESSE_IP] root ():/root[20200]: commande

Côté sudo, je vous conseille de journaliser ce qui est fait en plus.  Pour réaliser ça:

sudo visudo

# Ajouter
Defaults        logfile=/var/log/sudo/sudo.log

Et y'a plus qu'à ! 😎️