5 votes

Est-ce que Mojave a cassé la connexion SSH ?

J'espère que quelqu'un pourra m'aider à résoudre ce problème de connexion ssh. Dans mon réseau local domestique, je développe des sites Web et j'ai configuré mon routeur pour qu'il transfère les appels SSH externes vers mon ordinateur portable principal à partir de ce port externe.

Donc, si je suis connecté à l'ordinateur d'un client, j'utiliserai ssh ou scp.

$ ssh -p 7219 sam@mycomcastip

qui fonctionnait bien jusqu'à il y a quelques semaines quand je l'ai mis à jour vers Mojave. Maintenant, la connexion est interrompue. Voici les étapes que j'ai suivies pour isoler le problème :

$ ssh -p 7220 sam@mycomcastip

fonctionne parce que mon routeur le transfère en tant que port 22 vers une machine plus ancienne fonctionnant sous High Sierra. Peut-être mon routeur est-il défectueux ? C'est ce que je pensais, alors j'ai installé OpenWRT dessus (qui est très bon, jusqu'à présent) et je ne peux pas me connecter à l'ordinateur portable depuis l'extérieur comme je le pouvais auparavant.

Peut-être que Comcast bloque le port 7219 ? Si c'était le cas, il bloquerait le port 7220 et il ne le bloque pas. La modification du transfert de port vers un autre port échoue avec le même délai d'attente.

Peut-être que c'est mon démon SSH qui s'est planté ? Changer le transfert de port pour router vers le port 80 de l'ordinateur portable (qui a Apache en cours d'exécution), au lieu de 22 ne donne aucune différence dans le résultat.

Je peux confirmer qu'à l'intérieur de mon réseau local, je peux me connecter en SSH à cet ordinateur portable sans aucun problème. Cela m'assure que le démon ssh de l'ordinateur portable fonctionne. Je n'ai aucun problème à sortir de cette machine par SSH.

Je peux confirmer que le routeur ne fait pas le blocage car je peux exécuter tcpdump sur le routeur en recherchant ce port et il le reçoit et le transmet.

J'ai couru tcpdump sur cet ordinateur portable et en examinant le PCAP dans Wireshark, je peux voir le paquet arriver sur le port 22 et les tentatives ultérieures de l'opérateur distant pour réessayer la connexion, mais je n'ai pas trouvé le bon tutoriel sur l'analyse d'un paquet pour ce problème afin de m'aider à voir ce qui pourrait être la cause.

41 3.349934 remoteIP 192.168.1.105 TCP 74 45166 22 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=1415111467 TSecr=0 WS=512

Peut-être quelqu'un peut-il nous éclairer sur ce que cela signifie ?

J'ai essayé d'installer Mojave sur une autre machine pour voir si c'est un problème de Mojave, mais toutes les autres machines sont trop vieilles pour l'exécuter, donc je ne suis pas en mesure d'isoler que c'est le matériel ou le logiciel sur cette machine. En parlant de cela, ce comportement se produit lorsque j'achemine les données vers l'ordinateur portable via les ports sans fil et Ethernet/Thunderbolt de l'ordinateur portable, ce qui suggère que si c'est le matériel, ce ne sont pas les ports réseau qui causent le problème.

Étant donné que les règles de transfert de port sont les mêmes, à l'exception des ports source et destination, je pense que quelque chose a changé dans Mojave, car c'est le seul changement dont je me souvienne que j'ai apporté à l'ordinateur portable lorsque cette fonctionnalité est tombée en panne.

En cherchant sur Internet, j'ai trouvé le plus proche qui suggère qu'Apple a fermé certains dossiers aux utilisateurs distants. Sauf que, comme le détermine cette affiche, SSH permet de contourner ce blocage, donc ce n'est peut-être pas ça.

https://www.sentinelone.com/blog/mojaves-security-hardening-user-protections-bypassed/

J'ai découvert un clone de cette machine sur High Sierra avant de la mettre à niveau vers Mojave. En utilisant ce clone, le comportement attendu se produit. En exécutant tcpdump sur cet ordinateur portable, je peux voir le TCP passé par le routeur vers cet ordinateur portable à partir du serveur distant et je peux voir mon ordinateur portable est ACK en retour, ce qui confirme ce que j'ai vu lorsque je SSH à distance. Cela semble éliminer le fait que ce soit mon pare-feu sur le routeur qui bloque l'un de ces ports étranges vers cet ordinateur portable. Ce qui indique plus probablement que Mojave bloque le port 22 depuis l'extérieur de son sous-réseau.

Je peux montrer une capture d'écran qui montre que ce pare-feu Mojave est désactivé si c'est important.

C'est pourquoi je pose la question ici, plutôt que sur un autre forum consacré aux réseaux, car il semble que seule la machine Mojave OSX rejette le port 22. Quelles autres étapes de dépannage dois-je essayer ?

5voto

slm Points 4018

1. Longueur des bits de la clé SSH

La longueur des bits de votre clé SSH est-elle > 2048 ? Vous pouvez utiliser cette commande pour le confirmer.

$ ssh-keygen -lf ~/.ssh/id_rsa.pub
4096 SHA256:0f7e9153ec1edf81c224fec24c76d3ab1be7010e joeuser@dom.com (RSA)

Si c'est moins, MacOS refusera de l'autoriser.

2. Support des suites de chiffrement

Vous devez également vérifier, à partir du client où vous exécutez SSH, quelles suites de chiffrement sont présentées au serveur SSH de votre ordinateur portable. Vous pouvez le faire en utilisant ssh -vvvv .... pour voir quels chiffrements sont disponibles sur votre client comme ceci :

$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

Vous voudrez également examiner plusieurs autres composants de la suite de chiffres.

Les détails de la page de manuel sur -Q également :

 -Q query_option
         Queries ssh for the algorithms supported for the specified version 2.  The available features
         are: cipher (supported symmetric ciphers), cipher-auth (supported symmetric ciphers that sup-
         port authenticated encryption), mac (supported message integrity codes), kex (key exchange
         algorithms), key (key types), key-cert (certificate key types), key-plain (non-certificate
         key types), and protocol-version (supported SSH protocol versions).

3. IPQoS

Il y a eu des rapports de versions plus récentes d'OpenSSH concernant des problèmes de connectivité. J'ai trouvé ces exemples :

Pour contourner ce problème, il faut ajouter ce qui suit à votre fichier ~/.ssh/config :

$ cat ~/.ssh/config
...
...
Host *
  IPQoS throughput

J'ai vu des variantes de ceci, donc vous devrez peut-être essayer low au lieu de throughput . Vous pouvez consulter le man ssh_config pour plus de détails, voici l'extrait de cette option :

 IPQoS   Specifies the IPv4 type-of-service or DSCP class for connections.  Accepted values are af11,
         af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4,
         cs5, cs6, cs7, ef, lowdelay, throughput, reliability, a numeric value, or none to use the
         operating system default.  This option may take one or two arguments, separated by white-
         space.  If one argument is specified, it is used as the packet class unconditionally.  If two
         values are specified, the first is automatically selected for interactive sessions and the
         second for non-interactive sessions.  The default is af21 (Low-Latency Data) for interactive
         sessions and cs1 (Lower Effort) for non-interactive sessions.

Vous pouvez bien sûr le passer via CLI de la même manière :

$ ssh -o IPQoS=throughput joeuser@192.168.1.1

Si vous n'avez pas de chance avec ce qui précède, vous pouvez essayer ce formulaire à la place :

Host *
     IPQoS lowdelay throughput

Plusieurs Les fils de discussion mentionnent cette forme fonctionne également.

Références

1voto

Douglas Points 10417

Il y a une phrase clé dans votre question qui saute aux yeux :

Je peux confirmer qu'à l'intérieur de mon réseau local, je peux me connecter en SSH à cet ordinateur portable sans aucun problème. problèmes. Cela m'assure que le démon ssh de l'ordinateur portable fonctionne. I n'ai aucun problème à sortir de cette machine par SSH.

Cela confirme qu'il ne peut pas être un problème de Mojave. Mojave accepte les connexions SSH. Cependant, cela n'a pas exclure d'autres services fonctionnant sur la machine Mojave.

Vos essais avec tcpdump et la configuration d'une autre machine avec des règles de transfert de port confirme que ce n'est pas le routeur.

Votre commentaire concernant l'exécution en mode sans échec vous a conduit au logiciel client VPN qui semblait être le coupable.

Le logiciel VPN (selon sa configuration) peut redéfinir la passerelle pour le trafic. Sur la base de ce que vous avez décrit, il semble que le trafic destiné au port 22 était correctement transféré, mais que le logiciel VPN répondait via la passerelle VPN, et non vers le routeur, d'où le délai d'attente.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X