TL;DR - allez au bas de la réponse, "Appliquer les restrictions".
L'ajout d'un utilisateur restreint se compose de deux parties : 1. Créer l'utilisateur 2. Configuration du démon SSH (sshd)
Configuration de sshd
Le meilleur moyen de se familiariser avec les possibilités de SSH est de lire les pages de manuel correspondantes :
Où le client SSH peut-il effectuer des actions ?
Avant de pouvoir restreindre quelque chose, vous devez connaître les caractéristiques de SSH. Cracher à travers les pages du manuel donne :
- Shell.
- Téléchargement de fichiers par sftp
- Transfert de port
- Le client transmet un port (non) utilisé au serveur.
- Le serveur transmet son port au client
- Le serveur transmet un port d'un autre hôte au client (proxy-ish).
- Transfert X11 (transfert d'affichage)
- Transfert d'agent d'authentification
- Transfert d'un dispositif de tunnel
De la Authentification de la section page de manuel de sshd(8) :
Si le client s'authentifie avec succès, une boîte de dialogue pour la préparation des la session est ouverte. À ce moment, le client peut demander des choses comme allocation d'un pseudo-tty, transfert des connexions X11, transfert des connexions TCP ou le transfert de la connexion de l'agent d'authentification. sur le canal sécurisé.
Après cela, le client peut soit demande un Shell ou l'exécution d'une commande . Les parties passent alors en mode session. Dans ce mode, chaque partie peut envoyer des données à tout moment, et ces données sont transmises vers/depuis le Shell ou la commande du côté serveur, et le terminal utilisateur du côté client.
Options de restriction des fonctions SSH
Les fichiers et leurs options qui modifient le comportement sont :
Application des restrictions
Modifier le fichier de configuration du système /etc/ssh/sshd_config permet à la configuration d'être appliquée même si l'authentification basée sur un mot de passe est appliquée ou si les restrictions de l'option ~/.ssh/authorized_keys sont accidentellement retirés. Si vous avez modifié les valeurs par défaut globales, vous devez décommenter les options en conséquence.
Match User limited-user
#AllowTcpForwarding yes
#X11Forwarding no
#PermitTunnel no
#GatewayPorts no
AllowAgentForwarding no
PermitOpen localhost:62222
ForceCommand echo 'This account can only be used for [reason]'
Maintenant, ajoutez un utilisateur :
sudo useradd -m limited-user
L'option ForceCommand peut être omis si le Shell est défini à un non-Shell comme /bin/false (ou /bin/true ) comme /bin/false -c [command] ne fera rien.
Maintenant, le client peut uniquement se connecter au port 62222 sur l'adresse de bouclage du serveur par SSH (il n'écoutera pas sur l'adresse IP publique).
Désactivation de AllowTcpForwarding interdit également l'utilisation de -R Il est donc impossible d'utiliser un tel compte restreint pour le transfert d'un seul port. PermitOpen localhost:62222 suppose que le port 62222 du serveur n'est jamais utilisé car le client peut s'y connecter et l'écouter également.
Si la redirection TCP est autorisée dans la configuration de l'ensemble du système et que l'authentification par mot de passe est désactivée, vous pouvez également utiliser des paramètres par clé. Modifier ~/.ssh/authorized_keys et ajoutez les options suivantes avant le ssh- (avec un espace entre les options et ssh- ) :
command="echo 'This account can only be used for [reason]'",no-agent-forwarding,no-X11-forwarding,permitopen="localhost:62222"
Vérifier
Pour être sûr qu'il fonctionne comme prévu, certains cas de test doivent être exécutés. Dans les commandes ci-dessous, host doit être remplacé par le nom d'utilisateur réel s'il n'est pas défini dans le champ ~/.ssh/config . Derrière la commande, une commande est affichée qui doit être exécutée soit sur le client, soit sur le serveur (comme spécifié).
# connection closed:
ssh host
# connection closed (/bin/date is not executed):
ssh host /bin/date
# administratively prohibited (2x):
ssh host -N -D 62222 # client: curl -I --socks5 localhost:62222 example.com
ssh host -N -L 8080:example.com:80 # client: curl -I localhost:8080
sftp host
# should be possible because the client should forward his SSH server
ssh host -N -R 8080:example.com:80 # server: curl -I localhost:8080
# This works, it forwards the client SSH to the server
ssh host -N -R 62222:localhost:22
# unfortunately, the client can listen on that port too. Not a big issue
ssh host -N -L 1234:localhost:62222
Conclusion
Liste de contrôle : L'utilisateur SSH ne doit pas pouvoir :
- exécuter des commandes Shell - fait
- accéder aux fichiers ou télécharger des fichiers vers le serveur - fait
- utiliser le serveur en tant que proxy (par exemple, webproxy) - fait
- accéder à des services locaux qui n'étaient pas accessibles au public en raison d'un pare-feu. partiellement le client ne peut pas accéder à d'autres ports que le port 62222, mais il peut écouter et se connecter au port 62222 du serveur.
- tuer le serveur - fait (Notez que ces vérifications sont limitées au serveur SSH. Si vous avez un autre service vulnérable sur la machine, cela pourrait permettre à un attaquant éventuel d'exécuter des commandes, de tuer le serveur, etc. )
