[RPi3] SSH not working via wifi

[dhstolfi]

Hello everyone.

After struggling with my brand new RB PI 3 for all the day I think I have found something interesting to share.

I had the same problem as you, ssh frozen, no ntp, no samba over WiFi.
I tried the "IPQoS cs0 cs0" thing and it worked! Thank you!
However, I still had problems with ntp and smb.
After reading the wikipedia page about type of service (thanks for posting it) I had the idea about changing the QoS set-up of my router (an old Zyxel). Specifically, I've activated "Enable WMM QoS", and voila, everything works, even I removed the IPQoS setting in the sshd config file as it was not necessary any more.

It could well be the explanation to why it was working in some routers.
I hope It will help.

Best regards.
Daniel

[sam-the-man]

I'm having the same problems but not sure how to fix it. My raspberry pi is headless and only uses wifi.

I tried using mosh which works without a hitch. However, I want ssh to work so I can access GitHub. I have 2FA enabled so I can't use https. I don't think there's a workaround so that I can use mosh to access GitHub.

I have tried stopping power saving and updated rpi-update. Not sure if there are other fixes that I should try.

[johni]

Just wanted to add my thanks to everyone who contributed to solving this one.

I came across the ssh problem when I purchased an "official" raspberry PI dongle last year.
I managed to track the cause down to my Orange router (Siemens Gigaset SE572) but in the
absence of a fix the dongle was consigned to a drawer. Came across it today and thought I would see
if anyone else had cracked it yet and bingo. IPQoS works for me too.

I'll pass on the tattoo though if that's OK

[marcelB]

I have the same issue, ssh is fine via Ethernet, but fails over Wifi after password entry, ping is fine, no drops and latency 7ms average. I have tried with a Linux VM and Windows 7 using putty. Output from the end of the ssh -vvv in the Linux box

debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
packet_write_wait: Connection to 192.168.0.140: Broken pipe

Will report back on the QoS settings

[drice]

Can confirm two things:

1. This issue is specific to certain routers.
2. Enabling WMM on the problematic router resolved the issue.

[dharasty]

It's just occurred to me that, AFAICT, that the common factor with non-working SSH appears to be when PuTTY is running on a Windows PC. (I was not able to reproduce the issue with PuTTY on a netbook using Ubuntu Linux). If that's true then is there a "problem" at the "Windows end" too? (Possibly ipv6 related?)
Trev.

I don't think this is a Windows issue;
I'm having the same problem trying to reach RPi3/Jessie from Ubuntu 14.04.

Both cmdline "ssh" and Ubuntu "Putty" fail the exact same way:
- contact the RPi
- prompts for username/password
- never returns after I enter password.

[dharasty]

Alas, the "IPQoS cs0 cs0" trick is NOT working for me. (Running an RPi3 w/NOOBs-based clean install of Jessie)

More observations from this problem:
- I'm finding the same behavior with the "CanaKit" WiFi dongle: ssh works over wired; fails over both WiFi (onboard and CanaKit dongle)
- I installed "telnetd" -- approximately the same behavior! Works over wired; fails over both WiFi.
- I installed Apache -- works fine on ALL THREE interfaces.
UPDATE:
- I installed vnc -- works fine on ALL THREE interfaces.
- some of my custom UDP-based apps work fine on ALL THREE interfaces.

So here is my shot-in-the-dark: could there be some bad interaction from either terminal daemon (sshd or telnetd) between Wifi and starting the login shell? That is one thing that telnetd and sshd need to do, but httpd (and others) do not. OK, OK: I know that is totally far-fetched... but so far "servers that start a shell session" don't work and servers that don't start a shell DO work.

[ncfactory]

The following solved the ssh-issue for my raspberry pi 3.
Rename the raspberry device to the origin name: raspberrypi
Then the device can be seen as >raspberrypi< in the router management and
ssh works, as it did with an unchanged installation.
If you raspberry has the ssh-issue, then please try to confirm this method.
This brings up a question: How is ssh effected by a change of the name of the raspberry device?
Can you give a comment on this?

[ncfactory]

Renaming the raspberry-device to the origin name >raspberrypi< solved the ssh-issue on my device.
Now the raspberry can be seen as >raspberrypi< with the router management tool and ssh works, like it did with a fresh, unchanged installation.
Can someone comment, how the name of the raspberry-device effects ssh?

[KevinA]

It is 8/23/2016 and I can't login to the built in WiFi port with SSH. I just downloaded and install the latest Raspbian, I even created a new user that I know the password of since I can't seem to be able to change the pi users password, it always tells me my new password is to much like the old one...
At any rate why can't I login using the built in WiFi and ssh?
I added a USB WiFi dongle with the same results, both ports reject the password. That WiFi dongle has been used on my Raspberry 2 without issues.
And now I have the PI hooked to Ethernet and still can not login with ssh, that is three different network connections, I created a user bob with password bob and added ssh group to bob yet bob can login to the GUI desktop but can not login on either Wifi or the Ethernet port.
I looked at the auth.log file and it fails with the password.

And now I have confirmed all three network connections allow RDP access from my Windows 10 desktop, WiFi0, WiFi1 and Ethernet.

The "IPQos cs0 cs0" does nothing as I'm not going thru the router between machines, there is a switch.

*** After a nights sleep I tried logging in to my PI 2 from my Windows 10 workstation, failed, then from my Ubuntu workstation, it worked, back to PI 3 and using the Ubuntu workstation logging in with ssh worked.
Something in my Windows 10 Pro workstation is stopping Puddy's ssh client from working, I used Puddy to login on the Ubuntu workstation and it worked so it is a combination of Raspian and Windows 10 Pro.
5/27 11:47 Fired up another workstation with windows 10 and tried to ssh to RPI3, same results, not authenticating
Found it:
5/27 16:26 Found the new user bob with password bob which I was allowed to create using adduser and passwd does not have a password that will work from remote access. Change password to thisreallysucks and bob can login without an issue. As far as the user pi. I had changed his password to pi, seemed like it took it and I can use it to login with.

Where are the remote login limits set at?

[anpfeiffer]

It only works with ipv6. For putty you must use the mac-adress in brackets like [fe80::b6be:zzzz:yyyy:xxxx]

[raker]

Hi,
I also have some problems with SSH login but in my case that was something different.
The problem was a charger . I was using some charger that had 0,5A. RPI works but if needed to some operation then everything stoped, disconnected from SSH, etc. So if You don't use some dedicated charger please check power parameters. Now I'm using 2,5A charger and everything works ok.

[shackledtodesk]

After changing a number of parameters on the networking level, it dawned on me after staring at the debug logs on the client and server side of the ssh session, that ssh was possibly doing something wonky. Then I ran across the following:
https://expresshosting.net/ssh-hanging-authentication/

Suffice it to say adding

Code: Select all

IPQoS 0x00

to my /etc/ssh/sshd_config then doing

Code: Select all

$ sudo systemctl daemon-reload ssh
$ sudo systemctl restart ssh

my ssh over wifi issue have been completely alleviated.

For background I was using:

• Raspberry Pi 3 (3 different ones all running Raspbian/Jessie)
• only used onboad wifi
• Switching between either Apple Airport Extreme (2015 version) and AT&T provided UVerse device.
• Client either OS X El Capitan OpenSSH (both wired and wireless on the same AP) or a wired Raspberry Pi 2B.
• No change if disabled ipv6, turning off X11 Forwarding, fixing core_freq=250, messing with MTU

I still see a lot of RX packets dropped through ifconfig for wlan0, but this thread [link]viewtopic.php?f=28&t=44044&start=425[/link] seems to show this to be spurious and performance since the QOS change in ssh seems to match this.

Good luck, YMMV.

[sanb]

I have the same problem: ssh to or from RPi3, connected to my modem-router via on-board WiFi, does not work.

After reading this entire thread and after many trials, the problem remains. The only interesting clue may be, for those who understand all this better, that I can ssh to any machine outside my home network from RPi3. But not to or from any machine within home network. To me this appears to be a problem with the router setup.

Does this show that RPi3's software configuration and the WiFi h/w (the chip) are all ok?

The additional information that might be of use is that my router-modem is 10 yr old and has only WEP and I had to make changes in the RPi3's wlan setup to work. It was setup assuming no one would ever want to connect via WEP any more .

Regards

[SurferTim]

Some routers do not allow localnet communication between wifi clients. I use Mikrotik routers, and I can enable or disable this feature called default forwarding. Check your router's setup. If you have a question, post the make and model router you are using.

[sanb]

Turns out that I can login from one laptop to another (both running RHEL6) within the home network. So:

• 1. I can ssh from RPi3 to a machine outside the home network.
  2. I can't ssh to or from RPi3 from within the network.
  3. I can ssh between two other RHEL6 laptops within the network.

By process of elimination, this suggests to me that

• (a) all is well with RPi3 hardware,
  (b) all is well with the router and it's set up,
  (c) something is wrong in the RPi3 software setup that is preventing ssh to/from RPi3 to machines within the network.

Does this you any more clue(s) that would lead to suggests or tests that I could perform to debug the problem?

[SurferTim]

What is the symptom of the fail? Does it fail to connect? Does it refuse the connection? Does it appear to be connecting and freezes?

[sanb]

My ssh to/from RPi3 vai on-board WiFi seems solved. Apologies for having missed seeing the following post earlier in this thread:

viewtopic.php?p=1085534#p1085534

The only differences in what I did and this post are:

1. The "IPQoS 0x00" string had to be added in /etc/ssh/ssh_config as well as in /etc/ssh/sshd_config.
2. Only the following command was required to restart ssh

Code: Select all

 sudo systemctl restart ssh

This fixes the problem and I am freely able to ssh to/from RPi3. Thanks very much for that post (and the link from there to the original source of this information).

I must admit I have no clue of what this fix is about, why it fixes the problem and what exactly was the problem. If anyone knows of a resource which explains this, I would love to read it (or else, the next time around this problem happens, I surely will go in circles for many days, as I did this time ).

Regards

[sanb]

What is the symptom of the fail? Does it fail to connect? Does it refuse the connection? Does it appear to be connecting and freezes?

The symptom was that it appear to be connecting but freezes after I type the correct password.

[maulapi]

I have RPi3 with Raspbian Jessie
- no problem with cabled LAN
- with wifi via USB dongle TL-WN725N no problem with port 80 but not possible to connect via SSH

I search with google for months but trick in this post ( page 4 ) SOLVE!!!:
- i add this line in bottom of /etc/ssh/sshd_config:

Code: Select all

IPQoS cs0 cs0

- restart ssh service and now SSH work also after reboot

Thank you for all

[nulldev]

What is the difference in:

IPQoS cs0 cs0
vs

IPQoS 0x00

[Killertechno]

Ok, not same trouble, but using Zero W (with latest image) connected to home access point I can login from laptop using SSH.
If I try to login using Putty (Windows) it hangs after password request.
Regardless Putty (Windows) or SSH (Ubuntu), I can't connect from wired network (different from wireless network of Zero W).
I supposed something wrong with NAT, but all remaining services were working correctly.
As suggested from SurferTim I added:

Code: Select all

IPQoS cs0 cs0

to ssh configuration files, but without success.

Then I've found different solution online (https://expresshosting.net/ssh-hanging-authentication) where using

IPQoS 0x00 instead IPQoS cs0 cs0, on both files

/etc/ssh/ssh_config
/etc/ssh/sshd_config

and now it's correctly working.

[Davenporten]

I haven't read through all the posts, but I just wanted to say that I thought I was having this problem and it turned out that it just took a few more seconds for the ssh'ing to complete. Not saying that's the case with everyone, but maybe try waiting even 10 seconds to see if it will go through.

Good luck!

[add2rahul]

Some Success! Got a work around.
I've made my Android phone as Hotspot and connected my laptop and pi to it. I could smoothly connect using putty/ssh to pi. Not sure what is the problem with router config. Will post once I am clear about it.
Thanks guys for all the clues.

[SurferTim]

It appears to be a ToS problem that occurs with older routers. Read Killertechno's post above.