Question Comment restreindre l'autorité du tunnel SSH à un certain port?


J'ai un programme fonctionnant sur le port de serveur distant 9999. Comme il ne prend en charge aucun type de cryptage et d'authentification, j'utilise le tunnel ssh pour y accéder.

C'est la commande que j'utilise:

ssh -L 9999:localhost:9999 user@remotehost

Afin de garder ce tunnel en vie. J'écris un script SSH pour surveiller et le redémarrer si quelque chose se passait mal. Donc, je dois stocker le mot de passe dans le script.

Mais, considérant la possibilité que ce client-serveur soit piraté. Je pense que c'est mieux si je peux limiter ce tunnel à une autorité minimale.

Alors, est-il possible de restreindre l'utilisateur remotehost peut uniquement utiliser le transfert de tunnel ssh vers le port 9999?


5
2018-03-29 09:30


origine




Réponses:


Afin de garder ce tunnel en vie. J'écris un script SSH pour surveiller et le redémarrer si quelque chose se passait mal.

Vous devriez envisager d'utiliser autossh au lieu.

Donc, je dois stocker le mot de passe dans le script.

Vous devez utiliser l'authentification par clé publique au lieu d'un mot de passe.

Alors, est-il possible de restreindre l'utilisateur remotehost peut uniquement utiliser le transfert de tunnel ssh vers le port 9999?

Tout d’abord, assurez-vous que l’utilisateur ne peut pas ouvrir un shell interactif sur le serveur machine. Créez simplement un compte spécifique qui n’est utilisé que pour ouvrir ce tunnel si vous n’en utilisez pas déjà un. Définissez le shell par défaut pour ce compte sur /sbin/nologin (ou /bin/false si le premier n'existe pas)

useradd tunnel
usermod -s /sbin/nologin tunnel

Vous devriez aller sur le client machine et générer une paire de clés ssh et copier la clé publique sur le serveur.

ssh-keygen
ssh-copy-id tunnel@server

Enfin, sur le serveur, restreignez la possibilité de tunnelliser autre que localhost: 9999 à l’aide du fichier allowed_keys. Ajouter Ajoutez les éléments suivants à la clé autorisée chargée avec ssh-copy-id.

no-pty,permitopen="localhost:9999"

Le non-pty est un autre paramètre de sécurité qui interdit d'ouvrir un shell interactif. La ligne résultante ressemble à ceci:

no-pty,permitopen="localhost:9999" ssh-rsa AAAAB3NzaC1y...Rdo/R user@clientbox

Il peut y avoir d’autres options utiles que vous pouvez définir dans authorized_keys file. Pour plus d'informations, lisez homme sshd.

En outre, vous pouvez également verrouiller le compte dans le /etc/ssh/sshd_config via un bloc de correspondance pour le compte:

Match User tunnel
   ForceCommand /sbin/nologin # An additional configuration to disable any shell command, superfluous when the user's shell is already set to `/sbin/nologin`
   AllowAgentForwarding no
   AllowTcpForwarding local # Disallow port forwarding of remote ports, superfluous when using the `permitopen` restriction in authorized_keys
   AllowStreamLocalForwarding no # Probably not necessary, as the user needs to have access rights to access the AF_UNIX port
   X11Forwarding no # Because some default configuration files, e.g. from Debian, set it to yes
# Beware: Match does not end with indentation!

Ce ne sont que des conseils pour améliorer la configuration actuelle de votre tunnel ssh. Comme l'a suggéré Dennis, il existe d'autres solutions de tunnelage plus élégantes que vous devriez envisager.


9
2018-03-29 09:54



Permettez-moi de ne jamais savoir ça. Je pense toujours que l'utilisation de ssh pour cela est fausse cependant. Ne devriez-vous pas prévoir ce paramètre si? - Dennis Kaarsemaker
Je conviens que ce n'est pas le bon outil pour le travail. Merci d'avoir repéré l'erreur append. - Kenny Rasschaert
J'ai changé pour utiliser Stunnel, mais j'apprends toujours beaucoup de cela. Merci à vous deux pour votre aide précieuse! - user1914683


Non, ce n'est pas possible. Vous pouvez désactiver le transfert de port, mais cela désactive le transfert de tout port, il n'y a pas de paramètre par port.

Oui, cela est possible en ajoutant un préfixe permitopen="localhost:9999" à la clé ~/.ssh/authorized_keys sur le serveur, voir la page de manuel sshd (merci Kenny!). Vous voudrez également forcer une commande qui ne fait que dormir, pour vous assurer que tout attaquant ne pourra pas obtenir un shell (et supprimera donc cette restriction, et fera d’autres mauvaises choses).

Cela dit, ssh est la mauvaise façon de faire cela. Pourquoi ne pas utiliser stunnel rendre le service disponible sur SSL? Ou configurez une connexion VPN entre les deux ordinateurs avec openvpn?


1
2018-03-29 09:46





Je jetterais un coup d'œil au autossh outil.

La page de manuel est disponible ici:

Je l'utilise pour garder ouverts les ports d'un serveur IMAP et SMTP situés derrière un pare-feu. Par exemple:

% autossh -M 0 -f -N -L 2025:localhost:25 -L 2143:localhost:143 \
          myuser@remoteserver

Il semble que la plupart des référentiels de distributions Linux le soient également.


0
2018-03-29 14:05