Est-il possible d'avoir 2 ports ouverts sur SSH avec 2 schémas d'authentification différents?
J'essaie actuellement de configurer un serveur SSH afin que l'accès à celui-ci depuis l'extérieur du réseau soit UNIQUEMENT autorisé à l'aide d'une clé SSH et n'autorise pas l'accès à root ou par toute autre combinaison nom d'utilisateur/mot de passe.
Dans le même temps, les utilisateurs internes au sein du réseau doivent toujours pouvoir se connecter au même système, mais s'attendent à se connecter dans le sens plus traditionnel avec un nom d'utilisateur et un mot de passe.
Les utilisateurs externes et internes accéderont au système à partir de Windows en utilisant PuttySSH et l'accès externe entrera dans le système via un pare-feu de redirection de port qui ouvrira le port source au monde extérieur sur un port numéroté choisi arbitrairement comme 55000 (ou ce que les administrateurs décident)
Le diagramme suivant tente de mieux montrer les flux de trafic.
Je sais comment configurer la connexion réelle pour utiliser uniquement des clés, et je sais comment refuser root, ce que je ne sais pas, c'est comment séparer les deux types de connexion.
J'avais envisagé d'exécuter deux copies de SSHD en écoutant sur différents ports sur la même IP et en ayant deux configurations différentes pour chaque port.
J'ai également envisagé de mettre en place une règle de "correspondance", mais je ne sais pas si je peux séparer les configurations à l'échelle du serveur à l'aide de ces options.
Enfin, la personne externe qui se connectera sera toujours le même utilisateur, appelons-la "Frank" pour les besoins de cette question, donc "Frank" ne sera autorisé à se connecter qu'à partir de l'IP externe, et ne sera jamais réellement assis devant de tout système se connectant en interne, alors que tous les autres utilisateurs du système ne se connecteront qu'en interne et ne se connecteront jamais à partir d'une adresse IP externe.
L'IP Franks à partir duquel il se connecte est attribué dynamiquement, mais l'adresse IP publique à laquelle il se connecte est également statique et ne changera jamais.L'IP interne du port forwarder ne changera pas non plus, et l'adresse IP interne du serveur SSH ne changera pas non plus. .
Les clients internes se connecteront toujours à partir d'une adresse IP dans la plage de réseau privé dont fait partie l'IP des serveurs SSH internes et est un masque 16 bits EG: 192.168.0.0/16
Cette configuration est-elle possible, en utilisant un fichier de configuration et une instance de serveur SSH? Si oui, comment dois-je procéder?
ou
Suis-je beaucoup mieux en utilisant 2 serveurs en cours d'exécution avec une configuration différente?
Pour référence, le serveur SSH fonctionne sur Ubuntu 18.04.
Donc, il s'avère que la réponse était en fait bien plus simple que je ne le pensais.
Je dois cependant remercier '@jeff schaller' pour ses commentaires, si ça n'avait pas été pour lui, je n'aurais pas commencé à chercher comment la configuration SSH 'Match' fonctionne.
En tous cas
L'astuce consiste à définir votre fichier/etc/ssh/sshd_config par défaut pour être la configuration que vous souhaitez avoir pour l'accès provenant de la connexion Internet externe.
Dans mon cas, cela signifiait définir les paramètres suivants
PermitRootLogin no
PasswordAuthentication no
UsePAM no
Ce faisant, je force TOUTES les connexions, peu importe d'où elles viennent, à être des connexions basées sur des clés à l'aide d'une clé SSH.
Ensuite, sur les machines Windows, j'ai utilisé "PuttyGen" pour générer une paire de clés publique/privée que j'ai enregistrée sur le disque, et une entrée ssh appropriée pour mon fichier "authorized_hosts" dans le répertoire personnel des utilisateurs externes.
J'ai collé cette clé ssh au bon endroit dans le dossier d'accueil de mes utilisateurs, puis j'ai configuré PuTTY pour utiliser le fichier privé (ppk) généré par PuttyGen pour la connexion et j'ai enregistré le profil.
J'ai ensuite enregistré le profil et envoyé ce fichier et le fichier de clé ppk à l'utilisateur externe à l'aide d'une méthode sécurisée (courrier électronique crypté avec un fichier Zip protégé par mot de passe joint)
Une fois que l'utilisateur avait le ppk et le profil dans sa copie de PuTTY et qu'il pouvait se connecter, j'ai ensuite ajouté ce qui suit en tant que 2 dernières lignes sur mon fichier sshd_config
Match Host server1,server1.internalnet.local,1.2.3.4
PasswordAuthentication yes
Dans la ligne "Match", j'ai changé les noms de serveur pour protéger les noms de mes propres serveurs.
Notez que chaque domaine de serveur est séparé par une virgule et AUCUN ESPACE, c'est important. Si vous y mettez des espaces, SSHD ne chargera pas la configuration et ne signalera pas d'erreur, les 3 correspondances que j'ai ici font ce qui suit:
server1 - correspond à toute personne utilisant simplement 'server1' sans domaine pour se connecter EG: 'fred @ server1'
server1.internalnet.local - correspond à toute personne utilisant le nom de domaine interne complet EG: '[email protected]' (REMARQUE: vous besoin d'un DNS interne pour que cela fonctionne correctement)
1.2.3.4 - correspond à l'IP spécifique. adresse attribuée au serveur SSH EG: '[email protected]' cela peut utiliser des caractères génériques, ou encore meilleur format cidr net/mask EG: 1.2. * ou 192.168.1.0/8 si vous utilisez des caractères génériques cependant, veuillez lire La réponse de fchurca ci-dessous pour quelques notes importantes.
Si l'un des modèles fournis correspond à l'hôte auquel vous accédez, la seule et unique modification à apporter à la configuration en cours consiste à réactiver la possibilité d'avoir une connexion par mot de passe interactive.
Vous pouvez également insérer d'autres directives de configuration ici, et ces directives seront également réactivées pour les hôtes internes répertoriés dans la liste de correspondance.
lisez cependant ceci:
https://man.openbsd.org/OpenBSD-current/man5/ssh_config.5
soigneusement, comme toutes les options de configuration ne sont pas autorisées à être utilisées dans un bloc de correspondance, je l'ai découvert lorsque j'ai essayé de "UsePAM yes" pour réactiver l'authentification PAM, seulement pour être informé que ce n'était pas autorisé.
Une fois vos modifications effectuées, saisissez
sshd -T
suivi d'un retour pour les tester avant d'essayer de redémarrer le serveur, il signalera toutes les erreurs que vous avez.
En plus de tout ce qui précède, j'ai également obtenu beaucoup d'aide à partir des deux liens suivants:
https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html
1.2. * - correspond à n'importe qui dans le réseau local en utilisant n'importe quelle adresse attribuée au serveur SSH qui est dans le masque de réseau 16 bits pour le serveur EG: '[email protected]'
Prudent! La correspondance de modèles dans .ssh/config est basée sur la globalisation des chaînes, pas nécessairement sur les adresses IP. Selon la même page de manuel que vous lisez:
MOTIFS
Un modèle se compose de zéro ou plusieurs caractères non blancs, "*" (un caractère générique qui correspond à zéro ou plusieurs caractères) ou "?" (Un caractère générique qui correspond exactement à un caractère). Par exemple, pour spécifier un ensemble de déclarations pour tout hôte dans l'ensemble de domaines ".co.uk", le modèle suivant peut être utilisé:
Host *.co.ukLe modèle suivant correspondrait à tout hôte de la plage réseau 192.168.0. [0-9]:
Host 192.168.0.?
Si quelqu'un essaie de se connecter à partir d'une adresse IP qui se résout publiquement en 1.2.badguy.com, il correspondra à votre 1.2.* règle.
https://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#PATTERNS
[Mis à jour pour être complet]
Comme indiqué ailleurs, vous pouvez utiliser Match Address 1.2.0.0/16 au lieu de Match Host 1.2.*
[/Mise à jour]
Je pense que ce que vous devriez regarder est de diviser vos configurations ssh. Par exemple; configurez votre/etc/ssh/ssh_config pour avoir les variables globales dont vous avez besoin pour tous les utilisateurs par défaut (authentification de clé ssh, redirection de port, etc ...).
Ensuite, si votre utilisateur (appelons-le Bob) a un répertoire personnel local (ou monté en nfs), mettez une configuration juste pour lui dans /home/bob/.ssh/. Cette configuration contiendra votre déclaration de correspondance ainsi que si vous avez besoin de lui pour vous connecter avec un mot de passe plutôt qu'un certificat ainsi que ses propres valeurs Keep Alive, etc ...
J'ai fait cela dans le passé et actuellement pour verrouiller certains comptes locaux pour qu'ils proviennent d'une seule adresse IP et n'autoriser que l'authentification basée sur les certificats tandis que d'autres comptes d'utilisateurs peuvent utiliser l'authentification PAM et avoir une authentification par mot de passe.
En bref, la création et la maintenance de fichiers de configuration utilisateur distincts en fonction des besoins des utilisateurs est plus facile à gérer que d'essayer de tout conserver sous le fichier de configuration par défaut pour ssh.