Dans quelle mesure SSH ForceCommand est-il sécurisé sur un hôte de saut?

J'ai la configuration suivante sur mon réseau:

Internet <--> Bastion <--> Local Network

J'ai plusieurs utilisateurs et chaque utilisateur est affecté à une machine spécifique. Ou en d'autres termes: chaque utilisateur ne doit avoir accès qu'à l'un de ces serveurs. Par exemple: User1 -> Machine1, User2 -> Machine2 et ainsi de suite.

Ces utilisateurs se connecteront de l'extérieur de mon réseau et j'ai envisagé de nombreuses options pour transférer leurs connexions via mon hôte bastion vers mon réseau.

Finalement, j'ai opté pour Match Blocks et forcecommand.

Ainsi, mon / etc / ssh / sshd_config sur bastion ressemble à ceci:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1 se connecte à l'hôte bastion qui établit automatiquement une connexion avec Machine1.

Pour autant que je comprenne ForceCommand, User1 n'aura aucun accès réel à l'hôte bastion, car toutes ses opérations seront d'abord gérées par le bloc de correspondance, donc redirigées vers Machine1. Mais est-ce vraiment vrai? Est-ce déjà suffisant pour être une configuration sécurisée? L'utilisateur est de toute façon emprisonné sur Machine1, il n'aura donc pas beaucoup de possibilités.

La façon dont j'utilise un hôte bastion utilise ProxyCommandet le -Wdrapeau comme dans cet exemple:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

J'utilise cette approche pour des raisons de sécurité. La communication entre le client et la machine cible est chiffrée et authentifiée de bout en bout, ce qui signifie qu'elle reste sécurisée même si le bastion est compromis. Un hôte bastion compromis ne fournirait pas moins de sécurité que l'utilisation de ssh de bout en bout sans bastion.

Il élimine également la nécessité d'utiliser n'importe quel transfert d'agent. Le client peut utiliser l'authentification basée sur une clé d'abord pour accéder au bastion, puis à nouveau pour accéder à l'hôte cible sans qu'aucun de ceux-ci ne dispose d'une connexion d'agent qui pourrait être utilisée pour abuser de la clé privée présente sur le client.

Cela limite également le code dont je dépend sur l'hôte bastion. Je n'ai pas besoin d'exécuter de commande sur le bastion. -Wimplique aucun indicateur de commande ainsi qu'une seule redirection de port, cette redirection de port est tout ce que l'hôte bastion doit autoriser.

Avec cette approche à l'esprit, ma recommandation serait de verrouiller l'hôte bastion autant que possible en n'utilisant que les commandes de la structure ci-dessus.

Le ~/.ssh/authorized_keysfichier sur le bastion pourrait appartenir à root (comme tous les répertoires sur le chemin de la racine du système de fichiers à celui-ci), cela réduit le risque qu'il puisse être modifié même si quelqu'un réussissait à s'introduire en tant qu'utilisateur non privilégié sur le hôte bastion.

Dans authorized_keyspeuvent être limités les privilèges du client en utilisant les options command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, ainsi que l' utilisation permitopenau port limite réexpéditions d'autoriser l' accès au port 22 sur l'hôte que cet utilisateur est autorisé à accéder.

En principe, cette approche serait sécurisée même si plusieurs utilisateurs partagent le même nom d'utilisateur sur le bastion. Mais vous obtenez un peu plus de séparation en utilisant des noms d'utilisateurs distincts sur le bastion.

Vous pouvez facilement contourner ForceCommand car il intervient lorsque votre shell a démarré. Cela signifie essentiellement que votre fichier shell rc est traité en premier, puis ForceCommand si vous l'autorisez à y arriver. Simple exec shdans votre fichier shell rc va générer un autre shell et laisser ForceCommand attendre jusqu'à ce que vous quittiez ce shell.

Donc, en bout de ligne; si l'utilisateur peut en quelque sorte éditer son shell rc (par exemple .bashrc) via ftp, sftp, scp ou d'une autre manière, alors ForceCommand n'est pas vraiment quelque chose sur lequel s'appuyer.

J'imagine que c'est bien la plupart du temps, mais le problème avec la sécurité, c'est les choses auxquelles personne n'a encore pensé. Il n'y a aucune garantie.

Comme par exemple pendant longtemps, personne n'avait trop réfléchi à la façon dont les fonctions pouvaient être créées à partir de variables d'environnement dans bash, mais récemment, les gens ont réalisé que cela pouvait être inversé, et l'un des effets de cela était que ForceCommand pouvait être contourné (à moins implémenté dans le fichier authorized_keys) si le shell des utilisateurs était bash. Bash a été corrigé, et j'espère que votre version est à jour, mais des choses comme cela se produisent.

Je ne suis pas tout à fait sûr que la définition de ForceCommand soit effectivement la même chose que la définition de ces commandes dans les fichiers authorized_keys. Je n'ai pas regardé ça de près.

Rendez le sshd .bashrcdétenu par root:usergrpmais toujours lisible par le sshd qui s'exécute lorsque l'utilisateur se connecte. Définissez perms / owner sur $ HOME en interdisant la création de nouveaux fichiers par l'utilisateur. De cette façon, root contrôle le contenu de .bashrc, le laissant faire ce dont il a besoin, mais l'utilisateur lui-même ne peut pas modifier ces paramètres ou les autorisations sur les fichiers / répertoires qui leur permettraient indirectement de modifier le contenu de .bashrc.

J'ai une autre idée. Pour chaque utilisateur sur le serveur bastion, vous pouvez définir leur shell dans / etc / passwd comme un script bash qui exécute simplement ssh user1 @ machine1, user2 @ machine2, etc. De cette façon, vous vous assurerez qu'ils n'ont pas de shell sur le serveur lui-même et qu'ils se connectent simplement à la machine à laquelle ils doivent se connecter.