Pourquoi Ubuntu ne peut-il pas accéder à mon Raspberry Pi sur un réseau local?
D'accord, j'ai récemment eu un Raspberry Pi et je l'ai connecté à mon réseau Wi-Fi - j'ai activé le SSH et installé Hiawatha, et je pouvais y accéder très facilement à partir de mon ordinateur de bureau, qui exécutait Puppy Linux à ce moment-là.
Je pouvais également y accéder parfaitement au démarrage de Windows (PuTTY sous Win XP Pro,) et le Netbook pouvait également y accéder via PuTTY. (Win 7 Starter)
Cependant, lorsque j'ai démarré sous Ubuntu, toutes les connexions SSH, HTTP et HTTPS ont été refusées. Pour confirmer qu’il s’agissait des problèmes de connexion liés à Ubuntu, et seulement à Ubuntu, j’ai redémarré dans Puppy Linux - connected bien, et sous Windows -. Le Netbook pourrait se connecter aux 3 services sans problème non plus. C'est juste Ubuntu que cette connexion a été refusée.
J'aimerais savoir ce qui ne va pas - j'ai déjà fait tout le dépannage de base: redémarrer le RPi, redémarrer mon ordinateur, redémarrer le routeur sans fil, etc. Raspberry Pi n'a pas de pare-feu activé, et mon routeur offre tous les périphériques connectés à Accès LAN sans restriction les uns aux autres. J'ai fait des tests approfondis , et Ubuntu a été prouvé de manière irréfutable qu'il était le seul à ne pas vouloir se connecter.
MISE À JOUR: Je viens juste de tester l'accès via mon IP externe, et tout se passe bien sous Ubuntu! Cependant, Ubuntu ne peut toujours pas accéder au Pi de tout ce qui est local, et je viens de reconfirmer que mon autre système d’exploitation peut . Je pense que c'est étrange qu'Ubuntu ait des difficultés à se connecter localement (contrairement à mon autre système d'exploitation), mais il est tout à fait correct d'accéder au Pi via mon adresse IP externe.
MISE À JOUR 2: La désactivation de mon pare-feu me permet d'accéder au périphérique, mais le mot de passe est incorrect tous. célibataire. heure. J'ai essayé de le saisir dans Gedit, puis de le glisser-déposer dans l'invite de mot de passe lors de la connexion à SSH, et il l'autorise lors de l'accès à [email protected], mais PAS lors de l'accès à [email protected]. C'est incroyablement frustrant.
Ainsi, jusqu'à ce que vous ayez activé ufw avec les paramètres par défaut sur votre machine Ubuntu, la connexion a toujours signalé Connection refused. Une fois que vous avez désactivé ufw sur votre client, la connexion est établie mais le mot de passe est toujours rejeté.
Je suppose que dans ce cas, votre problème est que l'adresse IP 192.168.2.128 est redirigée vers votre ordinateur client Ubuntu et que vous vous connectez au serveur ssh qui s'exécute sur votre ordinateur Ubuntu. Cela expliquerait:
Pourquoi vous êtes en mesure de vous connecter à partir d'Internet.
Pourquoi votre connexion a été refusée lorsque le pare-feu était activé sur votre client Ubuntu.
Pourquoi la connexion n'est plus rejetée alors que le pare-feu du client est désactivé.
Pourquoi maintenant, la connexion est établie, mais l'authentification échoue.
Pour résoudre ce cas:
Vérifiez la clé d'hôte du serveur avec
ssh -v [email protected]pour une connexion locale et pour une connexion Internet. Signale-t-il la même clé?Ou alors que vous vous connectez depuis un local et que vous êtes à l'invite pour taper votre mot de passe depuis un autre terminal:
Sudo netstat -tupanet voyez si une connexion est établie avec lesshdsur votre Ubuntu.
Bien que ce cas puisse tout expliquer, mais il est si étrange que je doute que ce soit votre problème.
Il est tout à fait possible que votre machine Ubuntu reçoive une adresse IP de réseau différente de celle attendue. Essayez ce qui suit:
- Sur le raspi, vérifiez son adresse IP avec
ifconfig | grep 192.168 - sur la machine Ubuntu, vérifiez son adresse IP avec
ifconfig | grep 192.168
Pour pouvoir communiquer entre eux sur votre réseau local, ils doivent tous deux utiliser le même sous-réseau. Consultez la troisième section de l'adresse IP pour voir si c'est le cas. Dans votre cas, ils doivent tous deux appartenir au sous-réseau 192.168.2. *.
Assurez-vous qu'ils ont bien différents adresses IP aussi. Cela peut sembler évident, mais cela peut arriver si l’un d’eux utilise DHCP et que l’autre est réglé de manière statique.
Si cela se vérifie, exécutez la commande suivante pour voir où vos paquets sont censés aller:
route -n
Recherchez dans la sortie le sous-réseau de destination qui s’applique à votre Raspberry Pi. Il ne devrait y avoir que 3 rangées:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
Si vous avez plus de rangées ou que des objets vont à des endroits étranges, c'est la solution.
Je suppose que votre connexion SSH finit par toucher un serveur SSH différent de celui de votre Raspberry Pi. C'est pourquoi la modification du pare-feu Ubuntu l'a affecté et que vos identifiants de connexion ne fonctionnent pas.
Sur Ubuntu 13.10, je ne pouvais pas utiliser ssh pour ma pi, alors que je pouvais auparavant le 13.04 et la Monnaie 16. Lorsqu’on essaie
ssh -vvv user@Host
J'ai eu :
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Je suis tombé sur une suggestion qui dit de définir MTU pour la machine (pas le pi) à 1200 au lieu de automatique. Je l'ai fait, éteint -> puis sur mon wifi, et connecté avec SSH à PI sur le premier essai. J'espère que ça aide quelqu'un.
Selon ce qui se trouve dans votre Pastebin, la "connexion refusée" indique que vous obtenez une réinitialisation de TCP de la part de ce qui se trouve à cette adresse IP.
Contrôle de santé: pendant le dépannage, DÉSACTIVEZ ufw.
Avec votre pare-feu de bureau désactivé, pouvez-vous envoyer une requête ping au Pi depuis votre bureau? Pouvez-vous cingler le bureau à partir de votre Pi?
Après avoir tenté le ping dans les deux sens, regardez le résultat de 'arp -n' sur les deux machines. Est-ce qu'ils voient les adresses MAC (matériel Ethernet) de l'autre ou est-ce que quelque chose redirige/intercepte le trafic?
Si vous pouvez faire un ping dans les deux sens et que 'arp -n' indique que les adresses MAC appropriées sont utilisées (cochez la case 'ifconfig' sur la machine opposée), l'étape suivante consiste à examiner /var/log/auth.log sur le Pi. Il devrait vous dire ce qui ne va pas avec la tentative de connexion.
Si ce qui précède n'aide pas, affichez-nous le résultat des commandes suivantes sur le Pi:
Sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
Sudo iptables-save
Sudo grep ssh /var/log/auth.log | tail -50
Et sur votre bureau:
Sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
Sudo iptables-save
Je vois une partie de cela collé dans les commentaires ci-dessus, mais il est important de commencer par garder le pare-feu désactivé. Si vous pouvez le faire fonctionner avec le pare-feu désactivé, vous pouvez alors procéder au dépannage de vos règles de pare-feu.
De plus, même si vous ciblez une adresse IP, les paramètres DNS restent importants, car SSH utilise DNS lors de la validation de la clé de l'hôte.
Supprimez le fichier ~/.ssh/known_hosts et réessayez. Si auparavant un hôte avec la même adresse IP ssh était accessible, vous pouvez conserver une empreinte digitale non valide.