Un compte de redirection SSH existant peut restreindre les paires de destination utilisées par ses clients SOCKS. Un fragment côté serveur peut autoriser un service nommé :

Match User proxyuser
    PermitOpen api.example.net:443

Intégrez-le à la politique d'authentification et de redirection existante du compte. PermitOpen n'accorde pas lui-même l'autorisation de redirection et ne désactive pas l'accès au shell.

OpenSSH compare les noms de destination fournis sans effectuer de recherche d'adresse pour cette comparaison. Hormis ses formes génériques documentées, la valeur n'est pas un motif général de nom d'hôte.

Cela compte pour SOCKS5. Un client qui envoie api.example.net avec le port 443 peut correspondre à cette paire. Un client qui résout le même nom localement et envoie une IP numérique a fourni une chaîne de destination différente. Un alias qui résout vers la même adresse est différent lui aussi.

Gardez le mode de résolution locale ou via le proxy du client cohérent avec la règle prévue. La résolution ultérieure du nom d'hôte autorisé détermine toujours où le serveur se connecte ; ce réglage n'est pas une interdiction consciente du DNS visant toute adresse privée.

Examinez en parallèle les restrictions propres à chaque clé et les autres réglages de serveur applicables, car toute interdiction supplémentaire de redirection peut encore rejeter la demande.

Articles similaires