[Raspberry Pi 3] SSH via WLAN funktioniert nicht

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Guten Morgen!

    Hat es schon jemand geschafft, sich per SSH mit dem Raspberry Pi 3 zu verbinden, wenn dieser nur per WLAN verbunden ist? Bei mir will es einfach nicht klappen. Mit angeschlossenem LAN-Kabel funktioniert es problemlos!

    Der Pi ist erfolgreich mit meinem WLAN verbunden und kann von anderen Geräten im Netzwerk angepingt werden. Nachdem ich den power_save-Modus des WLAN-Chips deaktiviert habe, funktioniert die Verbindung tadellos: Keine Abbrüche, kurze Ping-Zeiten (immer <10ms).

    Wenn ich mich nun über Putty mit dem Pi verbinden will, soll ich den Benutzernamen eingeben (bei mir noch der standardmäßige "pi") sowie das Kennwort "raspberry". Danach passiert einfach nix mehr. Putty macht keinen Mucks, siehe Bild im Anhang. Ich kann die Verbindung nur trennen, indem ich das Putty-Fenster schließe.

    Folgendes loggt der SSH-Server auf dem Pi:

    Code
    Mar  4 09:16:59 rpi sshd[1368]: Accepted password for pi from 192.168.178.38 port 49886 ssh2 
    
    
    Mar  4 09:16:59 rpi sshd[1368]: pam_unix(sshd:session): session opened for user pi by (uid=0)

    Dies kommt aus dem Log-File von Putty:

    Code
    Event Log: Sent password
    Event Log: Access granted
    Event Log: Opening session as main channel
    Event Log: Opened main channel                            
    Event Log: Allocated pty (ospeed 38400bps, ispeed 38400bps)

    Hat wer Ideen?

  • ich hatte das gleiche Problem ...

    bei mir gab es 2 wlan Einträge (wlan0 und wlan1) in /etc/network/interfaces

    wlan1 habe ich gelöscht und wlan0 um 2 zusätzliche Einträge erweitet
    auto wlan0
    wireless-power off

    /etc/network/interfaces
    auto wlan0
    allow-hotplug wlan0
    iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    wireless-power off

    einmal neugestartet und mit iwconfig kontrolliert
    -> Power Management:off

    und mein ssh connect via wlan klappt wieder

  • Auf jeden Fall vielen Dank für die Antwort. Die Änderungen haben bei mir allerdings leider nicht geholfen. "wireless-power off" hatte ich sowieso schon in der Datei drin. Aber auch mit "auto wlan0" und dem Entfernen von wlan1 hat sich leider nichts geändert.

    Falls es irgendwie hilft, habe ich hier noch das Log vom sshd-Dienst.

    Edit: Gerade habe ich auch den openssh-server nochmal komplett deinstallert und dann neu installiert. Hat auch nichts gebracht :s

    Einmal editiert, zuletzt von A350XWB (5. März 2016 um 13:57)

  • Moin,
    ich beobachte aktuell allgemein ein seltsames Verhalten beim WLAN. Ich hab Raspbian Jessie auf meinem RPI3. Während ich vom RPI alle Clients im LAN & Internet problemlos anpingen kann, habe ich von anderen Clients regelmäßig Aussetzer. beim anpingen des PI. PING Verluste bis hin zu kompletter nicht Erreichbarkeit des RPIs - dann geht auch SSH natürlich nicht mehr obwohl ich vom RPI aus noch pingen kann. Also irgend etwas ist da sehr komisch mit dem WLAN....


  • venice: Nachdem ich eine Änderung in der interfaces-Datei vorgenommen habe, kann ich mich über die Stabilität des WLANs nicht mehr beklagen. Einzig ssh funktioniert nicht. Verbindungen über Samba oder VNC laufen auch problemlos.

    Dank dir das probiere ich mal aus. Bzgl. SSH hast du schonmal in der sshd_config geschaut ob der server ggf. nicht auf dem richtigen interface lauscht?

    Einmal editiert, zuletzt von Venice-89 (5. März 2016 um 14:32)

  • Das Problem mit wlan habe ich in letzter Zeit auch vermehrt. Ein A+ und ein 3er. Beide mit Rasbian Jessie. Habe da die Vermutung das es da im Image vielleicht ein generelles Problem gibt wenn es mehr Leute betrifft.

    Einmal editiert, zuletzt von WaldiBVB (12. März 2016 um 23:43)

  • Hallo A350XWB,
    ich habe auch all das durchexerziert, was du gemacht hast. Nur das hat die Lösung gebracht (Quelle: https://expresshosting.net/ssh-hanging-authentication/:

    Öffne als root die Datei /etc/ssh/sshd_config und füge als letzte Zeile dies ein:

    Code
    IPQoS 0x00

    Danach entweder den ssh.service neu starten mit

    Code
    sudo systemctl restart ssh.service


    oder

    Code
    sudo reboot

    Netzwerkkabel vor dem Beginn des Reboot abziehen und über die WLAN-IP deines Raspis mit dem SSH-Clienten deiner Wahl einloggen. Hat bei mir (Raspi 3, Jessie lite Version vom 25.11.2016 also alles mit systemd-Funktionen) funktioniert. Ich hoffe, es funktioniert auch bei dir. Den Link, den ich oben angegeben habe, fand ich im Forum von raspberrypi.org ziemlich weit unten in dem Feed (https://www.raspberrypi.org/forums/viewtop…0+sshd#p1085534).
    Good luck!


  • Nur das hat die Lösung gebracht ...

    Naja, es gibt bzw. gab auch schon andere Lösungen. Z. B. weiter oben in dem Thread aus dem raspberrypi.org-Forum, den Du gepostet hast:

    Code
    /sbin/iptables -t mangle -I PREROUTING 1 -i wlan0 -p tcp --dport 22 -j TOS --set-tos 0x00
    /sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p tcp --sport 22 -j TOS --set-tos 0x00


    oder lediglich bestimmte Einstellungen/Konfigurationen im WLAN-Router.
    Die von dir genannte Quelle (weiter unten im Thread) hat evtl. auch nur aus dem raspberrypi.org-Forum abgeschrieben.

    BTW: Welchen WLAN-Router hast Du?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Fritzbox 7272 (UI). Ich konfiguriere meine Raspis immer mit festen IPs, weil sie dann deutlich schneller booten. In diesem Fall über dhcpcd.conf und wpa_supplicant. Zwischendurch hatte ich, um irgendwelche Konfigurationsfehler des Interfaces auszuschließen auf DHCP zurückgegriffen. Das hat aber keine Lösung gebracht. Und ja: Ich habe den Thread zu sehr diagonal gelesen ;)


  • Fritzbox 7272 (UI).

    OK, aber ich meinte nicht die festen IPs. Wenn Du in deinem WLAN-Router (FB7272) "Enable WMM QoS" konfigurieren könntest oder deine FB7272 das schon per default unterstützen würde, bräuchtest Du diesen Eintrag (IPQoS 0x00) nicht in der sshd_config oder auch kein "--set-tos 0x00" mit iptables.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Nach meinen Recherchen fallen die QoS Einstellungen auf der FB 7272 unter den Punkt Priorisierung (von Anwendungen und Geräten). Beides habe ich für den Raspi und alle Anwendungen eingestellt, die FB natürlich neu gestartet. Das hat alles nichts gebracht. Nur wenn der Parameter IPQoS 0x00 in der sshd_config gesetzt ist, kann ich über WLAN (ohne LAN) per SSH auf das Gerät zugreifen. Ich kann auch den Zusammenhang nicht ganz nachvollziehen, weil die Priorisierung in den FB Einstellungen nur die Kommunikation mit dem Internet betrifft, aber wohl keine Auswirkung auf das Gerät oder das Heimnetz hat. Denn die Kommunikation des Raspi mit dem Internet war nie gestört. MPD hat nach einem reboot immer zuverlässig die zuletzt eingestellte Internetradiostation abgerufen. Auch die Überprüfung mit nmap, ob der Raspi überhaupt im Netz ist, liefert immer das Ergebnis, dass das Gerät am Netz ist. Sogar die Systeminformationen (nmap -O IP) oder das Abklopfen der höheren Ports (z. B. von MPD Port 6600: nmap -p 6000-7000 IP) über lieferte immer die erwarteten Ergebnisse. Es war ausschließlich das Login mit SSH betroffen, sodass das Problem doch wohl eher beim Raspi selbst bzw. beim SSH-Server liegt. Es bleibt doch merkwürdig, dass wenn ein Netzwerkkabel angeschlossen ist, auch wenn man die LAN-Schnittstelle nicht für das SSH-Login benutzt, der WLAN Login möglich ist. Das deutet doch auch darauf hin, dass das Problem beim Gerät liegt und nicht beim Router, oder?

    Einmal editiert, zuletzt von JoergZ (6. Januar 2017 um 09:41)


  • Nach meinen Recherchen fallen die QoS Einstellungen auf der FB 7272 unter den Punkt Priorisierung (von Anwendungen und Geräten).

    Nein oder nicht nur den Pkt. "Priorisierung" betreffend. Siehe z. B.: QoS. Z. B. in meiner FB6360 ist für die WLAN-Clients nichts priorisiert und für diese wird in der FB bzgl. QoS Folgendes angezeigt:

    Zitat


    QoS (Quality of Service) WMM


    Dementsprechend brauche ich auf meinem PI3, diesen Eintrag in der sshd_config (oder set-tos mit iptables) nicht.



    ..., dass das Problem beim Gerät liegt und nicht beim Router, oder?


    Ja, in diesem Fall liegt das Problem beim Gerät, aber ein workaround ist nicht nur auf dem Gerät (PI) möglich (iptables oder sshd_config), sondern auch mit Hilfe von Einstellungen im WLAN-Router (wie oben gezeigt) und ohne Änderungen am Gerät. Dass nicht jeder WLAN-Router/Firmware das kann, ist mir auch klar.

    EDIT:

    https://de.wikipedia.org/wiki/Wi-Fi_Multimedia

    https://de.wikipedia.org/wiki/Internet_Protocol_Television

    EDIT 2:

    BTW: Der ntpd auf dem PI3, kann bei einer wifi-built-in-Verbindung, auch von diesem "QoS-Problem" betroffen sein/werden. Ein workaround ist dann, mit iptables oder evtl. mit dem Router möglich.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (6. Januar 2017 um 12:36)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!