SSH kann nicht nur über WLAN an Raspberry Pi gesendet werden

10

Ich habe Probleme, über SSH eine Verbindung zu meinem Raspberry Pi herzustellen, wenn dieser über WLAN verbunden ist. Wenn das RasPi über Ethernet verbunden ist, funktioniert alles einwandfrei. Wenn es jedoch über den WiFi-Dongle verbunden ist, kann ich den Router (unter 10.0.0.2) anpingen und über RasPi auf das Internet zugreifen, aber ich kann nicht SSH darauf zugreifen (der Befehl ssh antwortet nicht und meldet schließlich "Operation timed" aus"). Ich kann das RasPi auch nicht an die ihm zugewiesene statische IP-Adresse pingen.

Der von mir verwendete WiFi-Dongle ist TP-Link TL-WN823N. Ich habe es mit WICD auf einer statischen IP 10.0.0.28 eingerichtet. Es ist interessant, dass es funktioniert hat, als ich Anfang dieser Woche zum ersten Mal versuchte, eine Verbindung über SSH mit diesem WiFi-Dongle herzustellen. Jetzt, wo ich es erneut versuche, funktioniert es jedoch nicht mehr. Soweit ich das beurteilen kann, habe ich keine Konfigurationsänderungen vorgenommen.

Ich habe einige Befehle ausgeführt, um Ihnen einige Diagnoseinformationen zu liefern. Alle diese Befehle wurden ausgeführt, nachdem ich das RasPi mit angeschlossenem WiFi-Dongle gestartet hatte, jedoch ohne angeschlossenes Ethernet-Kabel. Ich versuche, über 10.0.0.28 eine Verbindung zum Gerät herzustellen (wie Sie unter / etc / network / interfaces feststellen können, habe ich die statische IP 10.0.0.27 für Ethernet konfiguriert. Die statischen IPs für beide Schnittstellen waren früher identisch, als ich hatte zuerst dieses Problem, also habe ich sie geändert, um andere zu haben, nur für den Fall, dass es zu einem Konflikt gekommen sein könnte. Unnötig zu erwähnen, dass das nicht funktioniert hat.

$ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:c2:f1:37  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1104 (1.0 KiB)  TX bytes:1104 (1.0 KiB)

wlan0     Link encap:Ethernet  HWaddr c0:4a:00:1b:32:ca  
          inet addr:10.0.0.28  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:71 errors:0 dropped:95 overruns:0 frame:0
          TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8866 (8.6 KiB)  TX bytes:8377 (8.1 KiB)

$iwconfig
wlan0     IEEE 802.11bg  ESSID:"Mercutech"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:26:F2:26:B4:62   
          Bit Rate:54 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=100/100  Signal level=85/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

lo        no wireless extensions.

eth0      no wireless extensions.

$ cat /etc/network/interfaces
auto lo

iface lo inet loopback
iface eth0 inet static
address 10.0.0.27
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
gateway 10.0.0.2

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

$ cat /etc/resolv.conf
nameserver 10.0.0.2

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.2        0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wlan0

$ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

— bgh
quelle

Sie geben an, dass Sie nicht über "nur WLAN" SSH können - was bedeutet, dass dies über eine andere Methode funktioniert. Haben Sie SSHD gestartet und können Sie SSH über eth0 durchführen?

— Nanzikambe

Ich kann SSH über eth0, aber nicht über wlan0. Ich glaube, dass SSHD dann laufen muss.

— Bgh

Können Sie den Pi anpingen, wenn er über WLAN läuft? Bitte bearbeiten Sie Ihre Frage, um uns die Fehlermeldung anzuzeigen, die Sie erhalten, wenn Sie versuchen, SSH zu verwenden.

— Guntbert

Hallo Guntbert. Ich habe gerade getestet und sehe, dass ich den Pi auch nicht pingen kann, wenn er über WLAN läuft. Ich kann es nur über eth0 pingen. Der Befehl ssh bleibt eine Weile hängen und meldet schließlich "Zeitüberschreitung der Operation". Ich habe die Frage mit diesen Informationen aktualisiert.

— Bgh

2

@bgh Ersetzen Sie "wpa-roam" durch "wpa-conf" in der Datei / etc / network / interfaces für wlan0.

— Gurcanozturk

3

Ich habe (auch) mit diesem Problem zu kämpfen. Wenn ich den PI über ein Kabel von meinem Roadrunner-Router anschließe, ist alles cool.

Meine SSH-Adresse lautet 10.0.1.7und ssh pi@10.0.1.7bringt mich von meinem Apple Mac zum PI. Übrigens verwende ich einen Edimax EW-7811Un Funkdongle im PI. Ich laufe Wheezy auf dem PI.

Es stellt sich heraus, dass das Einfachste funktioniert hat, um über WLAN mit abgezogenem Ethernet-Kabel zu ssh.

Ich ging zur Himbeer-GUI (auf meinem Fernseher) und startete das Programm "WiFi Config" und folgte den Anweisungen, die meinen WLAN-Namen und mein Passwort eingegeben hatten. Ich habe vergessen, mich zu verbinden, nachdem ich alle erforderlichen Informationen eingegeben habe. Sobald ich die CONNECT-Taste gedrückt hatte, war mein WLAN in Betrieb und ich konnte mein Ethernet-Kabel abziehen. Es ist so ein Vergnügen, "kopflos" zu sein. Meine SSH-Adresse lautet 10.0.1.8 für WLAN (war 10.0.1.7 für das Ethernet-Kabel)

— user24246
quelle

Seltsam. Ich habe gerade das LAN / Ethernet-Kabel abgezogen und konnte dann über WLAN eine Verbindung zu SSH herstellen. Steckte es wieder ein, konnte keine Verbindung zu SSH über WiFi herstellen. Seltsames Verhalten, funktioniert besser auf meinem Pi 3 B +.

— Geerlingguy

1

Versuchen Sie, die statische IP-Adresse für eth0 zu entfernen. Ändern Sie Ihre interfacesDatei folgendermaßen:

...
iface eth0 inet dhcp
# Comment all these out
#address 10.0.0.27
#netmask 255.255.255.0
#network 10.0.0.0
#broadcast 10.0.0.255
#gateway 10.0.0.2

Ich hatte ein ähnliches Problem und das hat funktioniert.

Versuchen Sie auch zu prüfen, ob diese Befehle funktionieren (andernfalls erhalten Sie möglicherweise einen Hinweis):

sudo ifdown wlan0
sudo ifup wlan0

— Dunc
quelle

0

Diese Verrücktheit passiert mir auch. Die einzige Problemumgehung, die ich gefunden habe, war das Pingen des Pi über mein Android-Telefon mithilfe eines Terminal-Emulators.

Starten Sie also Ihren Pi neu und verbinden Sie ihn über Wifi. Lassen Sie Ihren PC gegen den Pi pingen. Pingen Sie Ihren Pi mit einem dritten Gerät.

Ihr PC erhält Antworten vom Pi und Sie können es endlich SSH.

0

Das Entfernen des Hostnamens von bekannten_Hosts auf dem Client war meine Lösung dafür. Ich gehe davon aus, dass beim Versuch, ssh von der anderen Netzwerkkarte zu senden, der Schlüssel teilweise aufgrund der geänderten MAC-Adresse nicht übereinstimmt.

ssh-keygen -R Hostname

— Banjo
quelle

0

Auch ich habe Schwierigkeiten, SSH über mein WLAN mit meinem RasPi A + zu verbinden. (Sie werden sich erinnern, dass das A + nur einen USB-Anschluss und kein kabelgebundenes Ethernet hat). - Ich verbinde mich von meinem Heimnetzwerk aus. - Die einzige Router-Einstellung, die ich geändert habe, ist das Erstellen einer statischen IP für das RasPi. - Ich verwende PuTTY von einem Windows-Computer im selben Netzwerk. - Ich habe und EDIMax7811Un WLAN-Adapter für das RasPi. - Ich habe Wheezy und jetzt Jesse mit den gleichen Ergebnissen verwendet. - Ich habe keine speziellen WLAN-Konfigurationseinstellungen (außer das Aktivieren von SSH). - Wenn Sie das RasPi von meinem Desktop aus anpingen, wird das RasPi als nicht erreichbar angezeigt.

Meine derzeitige "Lösung" ist Geduld. Ich brauche 2 bis 8 PuTTY-Timeouts, bevor ich die Verbindung herstelle. Ich habe versucht, verschiedene Dinge aus "SSH pi@192.168.x.xx" ohne erkennbaren Unterschied einzugeben. Ich erhalte die gleichen Ergebnisse, wenn ich mich mit einem noch laufenden tmux-Prozess in das RasPi einlogge. Wenn das RasPi jedoch nicht gesperrt ist, verbinde ich mich schließlich.

JonRob

— JonRob
quelle