Suggestion: add "IPQoS 0x00" to "/etc/ssh/sshd_config", Rpi3, WiFi SSH issue

[Cyberman-tM]

This probably only affects a few, but it's rather annoying. Details here: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=138631&p=1085534&hilit=qos#p1085534

Short version: Some(?) Raspi 3 stop responding to SSH after the (correct!) password has been entered. Attaching a keyboard works, so it's just SSH.

Adding the line IPQoS 0x00 to the file /etc/ssh/sshd_config solves the issue.

I have no idea what IPQoS is, but I do know it solved the issue of not being able to log in remotely at once. (After restarting the ssh daemon or the raspi.)

[edit]Note: this concerns a fresh install of OctoPi!

[guysoft]

Where exactly do you need to add this? Can you send your /etc/ssh/sshd_config?

[Cyberman-tM]

I've added it near the bottom, above the last paragraph. Can't give you the details right now, I'm at work, sorry. I don't think it matters where it's put, but as I said I don't understand why it solves the issue either.)

[Cyberman-tM]

Finally, here's the sshd_config file content, after image-writing, first boot, changed password, and me inserting the line:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server
IPQoS 0x00
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

[guysoft]

Added it to nightly build, would be appreciated if you could test it helps

[Cyberman-tM]

Sorry, I completely forgot about this :-(

If you still need me to test it, I can probably do that tomorrow - although right now I've got problems reaching the server with the nightlies?

[guysoft]

Ill fix that. Internet is affected by storms here

On Feb 14, 2017 21:42, "Rejutka Lupex" notifications@github.com wrote:

Sorry, I completely forgot about this :-(

If you still need me to test it, I can probably do that tomorrow - although right now I've got problems reaching the server with the nightlies?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/guysoft/OctoPi/issues/294#issuecomment-279813834, or mute the thread https://github.com/notifications/unsubscribe-auth/AAT4JuxrilwrVCfg7zB_dm_SEYPVoXQzks5rcgPCgaJpZM4LmCPQ .

[guysoft]

Fixed the server, try now

[guysoft]

Down again, will fix

[guysoft]

Fixed, sorry for the mess, local connection was a mess here

[timmmmmey]

I can confirm the problem and the fix !

[guysoft]

@timmmmmey @Cyberman-tM I want to close this too, you didn't need to enable anything, right? https://github.com/guysoft/OctoPi/issues/286

[Cyberman-tM]

Update: # IT WORKS!

I'm testing right now - sorry, forgot again - having problems connecting right now - getting "connection refused", but I'm not sure if the problem is the Raspi or my new modem...

I'll keep trying until I figure out what's happening, I'll write again today.

[edit]Octoprint is running and accessible, so connection is there. But Putty can't connect via SSH? [edit2]This image: 2016-11-25-octopi-jessie-lite-0.14.0 [edit3]Slighty off-topic: apparently Raspi 3 doesn't support wifi channel 13

[final edit] # IT WORKS!

Apparently SSH wasn't enabled. I've plugged in a keyboard, went to setup, enabled SSH, and was able to connect via putty from my computer to the raspi - log in worked flawlessly.

Many thanks, you can close this.

[lechu77]

Same here using rpi4, fixed adding " IPQoS 0x00" to /etc/ssh/sshd_config

[guysoft]

@lechu77 What version of OctoPi are you using? because this has been fixed in later versions here: https://github.com/guysoft/CustomPiOS/blob/devel/src/modules/base/start_chroot_script#L77

[morezco]

This works! Many thanks!

[bittorf]

It does not work with the recent OpenSSH update anymore,
but instead of using 0x00 one can use throughput, e.g.:

user@host:~$ cat ~/.ssh/config
Host *
  HostKeyAlgorithms=+ssh-rsa
  PubkeyAcceptedKeyTypes=+ssh-rsa
  IPQoS throughput

At least on my side since the latest debian update, this happens:
(using throughput instead of the former 0x00 let disappear the error)

bastian@ryzen:~$ ssh root@intercity-vpn.de
/home/bastian/.ssh/config line 4: Bad IPQoS value: 0x00
/home/bastian/.ssh/config: terminating, 1 bad configuration options

bastian@ryzen:~$ ssh -V
OpenSSH_9.8p1 Debian-2, OpenSSL 3.2.2 4 Jun 2024

I can't quite work out which change is responsible for this:
http://metadata.ftp-master.debian.org/changelogs/main/o/openssh/unstable_changelog

[guysoft]

@bittorf if this has changed then it needs to be updated here: https://github.com/guysoft/CustomPiOS/blob/devel/src/modules/base/start_chroot_script#L130 Is there some documentation to why/how it was changed?