[RPi3] SSH not working via wifi

[chrisoh]

Tried pi to pi and osx to pi. I'll have a bash with a windows laptop tomorrow.

[zehekaese]

I got ssh to work by adding: IPQoS cs0 cs0
to /etc/ssh/sshd_config

[Tashman]

I got ssh to work by adding: IPQoS cs0 cs0
to /etc/ssh/sshd_config

Me also

[chrisoh]

Add

Code: Select all

IPQoS cs0 cs0

to /etc/ssh/sshd_config

Next you have to restart the daemon:

Code: Select all

sudo service ssh restart

Ok, just an update, I was having a blonde moment lastnight and was editing /etc/ssh/ssh_config. Whereas it should be /etc/ssh/sshd_config as SR-71 indicated. Apologies!

And the iptables mangling is no longer required too.

So, can confirm also, that this work-around is working! Hurrah!

I feel like we've all just graduated an exclusive club, shall we get tatoos?

[SR-71]

Add

Code: Select all

IPQoS cs0 cs0

to /etc/ssh/sshd_config

Next you have to restart the daemon:

Code: Select all

sudo service ssh restart

Ok, just an update, I was having a blonde moment lastnight and was editing /etc/ssh/ssh_config. Whereas it should be /etc/ssh/sshd_config as SR-71 indicated. Apologies!

And the iptables mangling is no longer required too.

So, can confirm also, that this work-around is working! Hurrah!

I feel like we've all just graduated an exclusive club, shall we get tatoos?

Kudos and credits go to lbog that was the first one to discover the binding with the ToS value !
BTW, not even the last update of binary blobs solves the wireless issue.

[chrisoh]

Kudos and credits go to lbog that was the first one to discover the binding with the ToS value !

You're right, thanks lbog!

BTW, not even the last update of binary blobs solves the wireless issue.

Yep, that's the next step, getting a bug report in so it can be resolved rather than worked-around. Seems to be a growing list of WiFi bugs to fix...

[tesche]

chrisoh writes:
I was having a blonde moment lastnight and was editing /etc/ssh/ssh_config. Whereas it should be /etc/ssh/sshd_config as SR-71 indicated.

well, I had to edit /etc/ssh/sshd_config to connect to and /etc/ssh/ssh_config to connect from my rpi3. but now it seems to work.

SR-71 writes:
I feel like we've all just graduated an exclusive club, shall we get tatoos?

no, thanks, but I'll dedicate the next beer to you guys.

what I still don't get: if this is supposedly a problem of the ssh version and/or the wlan router, then why does it work when I use a wifi stick on the same rpi3 with the same raspbian version?

[Gr8mate]

Been traveling and not had a problem with a couple of different routers.
Now back at my son's house this weekend with a Netgear router.
And delighted to confirm it works (Note, I did a complete update first before I read this thread update - probably was unessary)

Worked for me:
sudo nano /etc/ssh/sshd_config
added:
IPQoS cs0 cs0
Then:
sudo service ssh restart

Fired up PuTTY and it connected

Great work everyone!

[tajw]

Hi folks, new to Raspberry Pi world, not new to computers.

Having difficulty where I can't SSH to the Raspberry Pi 3 when it's wireless. It works fine when a wired connection is present. VNC works fine in both situations.

What's really odd is that I received the Raspberry Pi3 a few days ago, installed Raspbian, went through set up on Adafruit. Everything worked perfectly, including SSH via wireless. I renamed the Pi 'Piece-of-Pi' during the process.

Then my WD Pi Drive came in, so I used Berry Boot and installed Raspbian on the hard drive, trying to do exactly the same process I did during the first setup. Everything appears to work just fine except SSH via wireless. When I start Putty on my Windows machine and specify the IP of wireless (no wire connection present) I get a blank Putty screen for a few seconds then receive a "Connection error: Network Connection timed out." message.

ifconfig shows an IP for only the wireless adapter, and my router seems to be DHCP'ing the same IP address to that adapter as the first installation.

I do still have the SD card from the first installation, and can revert to that to check settings if anyone thinks that is helpful.

Thank you for any ideas you send my way!

Tracy

[chrisoh]

what I still don't get: if this is supposedly a problem of the ssh version and/or the wlan router, then why does it work when I use a wifi stick on the same rpi3 with the same raspbian version?

It's a problem with the Pi 3 Broadcom BCM43438 WiFi/BT chip firmware/driver, it was identified as affecting NTP in the same way.

[tajw]

Interesting. I had to manually set NTP via command line. Thanks for heads up

[zihanzzz]

Thank you very much for the solution.

Is there an explanation why

Code: Select all

IPQoS cs0 cs0

would work?

Thanks!

[fogmachine]

Edit: Adding "IPQoS cs0 cs0" to /etc/ssh/sshd_config worked for me, too. It would be nice if the man page for sshd gave a more informative explanation of the various IPQoS config values.

Edit2: https://en.wikipedia.org/wiki/Type_of_service has a good description of the history of this field, which sort of explains why there are issues using it - fields that have been repurposed over their history are bound to lead to problems.

I'm having the same problem using ssh or scp from a MacBook Pro. It gets far enough into the protocol that I don't think it's related to a specific WiFi chip - probably a firewall setting that affects the ports needed after the authentication phase.

Code: Select all

MacBook-Pro: $ ssh -vvv pi@192.168.1.64
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.64 [192.168.1.64] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_rsa-cert type -1
debug1: identity file /Users/lance/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u1
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.64:22 as 'pi'
debug3: hostkeys_foreach: reading file "/Users/lance/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/lance/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from 192.168.1.64
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:leVkdATGokb0gQCkHkTmzQY/jpdlCWSdXal72Q6X4zY
debug3: hostkeys_foreach: reading file "/Users/lance/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/lance/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from 192.168.1.64
debug1: Host '192.168.1.64' is known and matches the ECDSA host key.
debug1: Found key in /Users/lance/.ssh/known_hosts:5
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/lance/.ssh/id_dsa (0x7f8731d048a0),
debug2: key: /Users/lance/.ssh/id_rsa (0x0),
debug2: key: /Users/lance/.ssh/id_ecdsa (0x0),
debug2: key: /Users/lance/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/lance/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/lance/.ssh/id_rsa
debug3: no such identity: /Users/lance/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /Users/lance/.ssh/id_ecdsa
debug3: no such identity: /Users/lance/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/lance/.ssh/id_ed25519
debug3: no such identity: /Users/lance/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
pi@192.168.1.64's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.64 ([192.168.1.64]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env OLDPWD
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env LOGNAME
debug3: Ignored env DISPLAY
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

There's a ~30 second delay:

Code: Select all

packet_write_wait: Connection to 192.168.1.64: Broken pipe

[SR-71]

Edit: Adding "IPQoS cs0 cs0" to /etc/ssh/sshd_config worked for me, too. It would be nice if the man page for sshd gave a more informative explanation of the various IPQoS config values.

I'm having the same problem using ssh or scp from a MacBook Pro. It gets far enough into the protocol that I don't think it's related to a specific WiFi chip - probably a firewall setting that affects the ports needed after the authentication phase.

Code: Select all

MacBook-Pro: $ ssh -vvv pi@192.168.1.64
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.64 [192.168.1.64] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_rsa-cert type -1
debug1: identity file /Users/lance/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/lance/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u1
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.64:22 as 'pi'
debug3: hostkeys_foreach: reading file "/Users/lance/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/lance/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from 192.168.1.64
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:leVkdATGokb0gQCkHkTmzQY/jpdlCWSdXal72Q6X4zY
debug3: hostkeys_foreach: reading file "/Users/lance/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/lance/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from 192.168.1.64
debug1: Host '192.168.1.64' is known and matches the ECDSA host key.
debug1: Found key in /Users/lance/.ssh/known_hosts:5
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/lance/.ssh/id_dsa (0x7f8731d048a0),
debug2: key: /Users/lance/.ssh/id_rsa (0x0),
debug2: key: /Users/lance/.ssh/id_ecdsa (0x0),
debug2: key: /Users/lance/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/lance/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/lance/.ssh/id_rsa
debug3: no such identity: /Users/lance/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /Users/lance/.ssh/id_ecdsa
debug3: no such identity: /Users/lance/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/lance/.ssh/id_ed25519
debug3: no such identity: /Users/lance/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
pi@192.168.1.64's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.64 ([192.168.1.64]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env OLDPWD
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env LOGNAME
debug3: Ignored env DISPLAY
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

There's a ~30 second delay:

Code: Select all

packet_write_wait: Connection to 192.168.1.64: Broken pipe

The same port (tcp/22) is used even after the auth.
What is changing is the IP packet ToS: this is the standard behaviour of OpenSsh since ages.
I have other boards around running, in the same network,
with Linux and no one shows such ill behaviour.

[DVR]

Hey Guys,

I get Access denied via SSH (Putty) and cannot log in via GUI (Jessie). I am sure about the password.
SO I basically cant access my RPI (2, model B).

Is there any master user/password for GUI? or can I stop the process of opening the GUI during the boot?

Thanks in advance

[DougieLawson]

The default userid is: pi
The default password is: raspberry

Those are the "master" credentials unless you've changed either one. If you've lost your password for pi you have a few options
1. Reformat, re-install, try harder to remember it next time
2. Boot into single user mode with a root shell, reset the pi password
3. Build a rescue system on another SDcard, mount the broken system in a USB SDCard reader, mount the root filesystem fiddle with /etc/shadow to fix the password to a known value

Option 1 is easy if you have NOOBS, but it is extremely destructive - NOOBS recovery can trash & re-install your system, you WILL lose everything.
Option 2 can be done with the NOOBS config editor or by pulling the card and mounting it on windows you have to change

Code: Select all

...  fsck.repair=yes rootwait

to

Code: Select all

...  fsck.repair=yes rootwait init=/bin/bash

in your /boot/cmdline.txt boot the system and you're running as root.
Option 3 is easiest, and you gain a way to take backups in future. Boot the rescue system, mount the broken root filesystem, start a root shell, start a chroot session, fix the password with the passwd program, exit the chroot, shutdown the rescue system swap the cards back.

Everyone should have a USB SDCard reader and a second SDCard so they can frequently clone their system with dd or copy with rsync to a bootable rescue system.

I backup all of my SDCards to my NAS drive every three months. I can always find a good copy as a starting point for a rescue system.

[DVR]

Hi DougieLawson. Many thanks for your attention.

I will try now the option 3, since I have a second sd already with raspbian. Will share here if it worked.

What happened to my pi was:
1. Since I installed tightvnc it stopped going automatically to the GUI, asking user and password instead. It didn't accept the standard ones, and I didn't change it. It is known it changes something on the user interface. For example, after installing tightvnc I always needed to access it from the client as IP:1 (192.168.1.101:1)... But always worked.
2. So I needed to access via ssh (Putty) and launch tightvnc, so could access it via tightvnc client, and then start running a certain Python and then leaving it running forever (differently that ssh. If you leave it, it stops).
3. I had it running for weeks with Influxdb and Grafana, and suddenly stopped. So I tried to access via ssh just to run it again (thought was a power down, whatever). Same way I always did. But this time it returned 'Access Denied' on Putty, even I am sure about the password and typed it somewhere else to make sure was not a keyboard issue.
4. Took the SD card to another RPI. Same thing.

So the issue was that via ssh, it accesses the pi, ask for user and password, but suddenly started now to return 'Access Denied'.

As I said, I will try the options you gently mentioned, starting by the 3rd.

Thanks again.

[DougieLawson]

You could simply copy the /etc/shadow entry for your pi user from the good system to the bad system.

It should look something like

Code: Select all

pi:$6$9InZyXww$EDirvX/bYirZCnGVq6TNysfRffphoW83VkEzspr2UWdDXK8v4koQ/7ek28LhJOk/jvP.2J66RTlwDYPOic.pe1:16901::::::

[DVR]

Hi Dougie,

Copying the /etc/shadow from one to another SD has worked! I could access it now. Many thanks!

[PeterB2]

Thanks SR-71 and others who tested the 'IPQoS cs0 cs0' fix.

Delighted to confirm it works on my setup - RPi 3 with updated Jessie, Windows 10, DrayTek Vigor 2130 router. In my case PuTTY was fine, but Filezilla was failing with connection timeout errors.

I also had the ntp-not-synchronising problem, resolved using the workaround '/sbin/iptables -t mangle' etc. etc. proposed in the thread 'Time does not sync on Pi 3 and with official dongle'.

Cheers,
Peter

[Mansome]

Just letting you all know I ran into the same issue with arch linux on the pi. However the changing of the sshd and ssh files do not fix the issue. I can use the ipv6 address to get into the pi 3.

[p0mpi]

My RPi3 just started getting this problem today. Worked fine for the past week (that's how long I've had it). Only things that have changed are that I did an apt-get update, installed dhcpd and also created a DHCP reservation on my router which forced the pi to change it's IP (obtained via DHCP still).

The QoS fix also worked for me.

WLAN access point is an airport express (but it was working fine with that up until the changes I made mentioned above).

[LBS]

If I have my RPi3 connected with ethernet, both the ethernet and the WiFi interface works. I can connect with ssh, no problem.
If I remove the ethernet cable, the ssh session over WiFi dies.
I plug the ethernet cable back in, the WiFi connection comes alive again (same session, as before)
Can be reproduced on 2 different routers

Looks like the problem is on the RPi3 side ...

[LloydBayley]

Greetings All,

I have been experiencing the same problem with the RPi3 and wifi SSH access (and SMB).
Upon reading this thread, I was happy to find that I had test-hardware in the Good and Bad categories and can confirm that with the Apple Time Capsule, there is a problem with the pausing and losing-the-plot and with the Fritz, the problem vanishes.

I know it has been said before but I just thought I'd confirm that it is the same for me as well.

Now that makes it all very curious.
I also experienced a problem (same one) using one of my Pi2's with an EdiMax (EW-7811Un) mini wifi adapter but put it, initially, down to a faulty adapter and swapped it out for a different model.

I shall do some more testing, however, this leads me to believe that there's something scary going on, and I'm looking at the Apple Time Capsule communication as a potential culprit. Not the Time Capsule, itself, but rather the way the Pi3 and perhaps other non-specific adapters work with it.

Will do some more testing at some stage and reveal findings, should I have any Eureka-moments.

Cheers!

[bi.er]

If I have my RPi3 connected with ethernet, both the ethernet and the WiFi interface works. I can connect with ssh, no problem.
If I remove the ethernet cable, the ssh session over WiFi dies.
I plug the ethernet cable back in, the WiFi connection comes alive again (same session, as before)
Can be reproduced on 2 different routers...

Same behaviour here:
SSH via Ethernet (static ip) working
SSH via WIFI (dhcp) working perfectly at same time
Unplug eth0, both ssh sessions die, reconnect SSH via WIFI not possible until plugged in again...
During whole procedure the Pi is visible with wifi-ip in the router. One is able to ping sucessfully the pi.

After adding IPQoS cs0 cs0 in /etc/ssh/sshd_config SSH via wifi is working, as far I can tell