This change makes me uneasy: - I see no terminal-aware filtering applied in the notify_start() -> xvasprintf() -> writemsg() -> write() path. The remote server may not be entirely untrusted but it's also not exactly trusted, either, especially on the first use. There's a long and glorious history of surprising outcomes due to terminal escape sequences https://www.cyberark.com/resources/threat-research-blog/dont-trust-this- title-abusing-terminal-emulators-with-ansi-escape-characters
- I'm not sure it's even necessary: my phone was easily able to read pure-ascii QR codes as easily as the (admittedly much better looking) utf-8 based codes. Try a few: sudo apt install qrencode u=`cat /proc/sys/kernel/random/uuid` ; for t in ANSI ANSI256 ASCII ASCIIi UTF8 ANSIUTF8 ; do qrencode -t $t $u ; done ; echo $u ; unset u Are ascii-encoded qr codes known to be insufficient? - As for the actual code changes, they seemed fairly straightforward, and I found no issues. I'm very wary about undoing a safety mechanism from the past, put in place by people who thought about this significantly more than I have. - Upstream might have been engaging for a while but now appears entirely silent. This reminds me too much of dpkg+zstd, where a similar train of engagement lead to Ubuntu forking the dpkg ecosystem and carrying a patch without a clear way to reunify the ecosystem. Will we do the same to OpenSSH? (We might have already passed this point if we chose to ship this in Noble rather than wait for Oracular to test this out.) Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2077576 Title: SSH client doesn't handle properly non-ASCII chars Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Focal: Incomplete Status in openssh source package in Jammy: Incomplete Status in openssh source package in Noble: Fix Released Bug description: [ Impact ] Non-ascii visible chars (including back-slashes, new lines and so) are not properly rendered by clients, showing their octal visualization. Such as: Hello SSHD \\ We love \360\237\215\225! Instead of: Hello SSHD \ We love 🍕! This is particularly an issue when a server has configured keyboard interactive authentication and a PAM module wants to show non-ASCII characters such as a QR code for web authentication: When using an ubuntu server running authd for web authentication we may end up having the login qrcode rendered such as \210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210\342\226\210 https://ubuntu.com 1337 Which is clearly unreadable. [ Test case ] ## Server preparation Enable PAM and keyboard interactive authentication in a ssh server: Add a configuration file such as: /etc/ssh/sshd_config.d/test-ssh-pam.conf Containing: UsePAM yes KbdInteractiveAuthentication yes # This was working already; here to check potential regressions ForceCommand bash -c "echo Hello from SSHD \ We also love 🍕!; $SHELL" It's also suggested to check for regressions using a `Banner` option in sshd, pointing to a file with utf-8 contents. Restart the server: sudo systemctl restart ssh.service Edit the sshd PAM configuration file, adding as first line: auth requisite pam_echo.so Hello SSHD \ We love 🍕! Can be done with the command: sudo sed '1 iauth requisite pam_echo.so Hello SSHD! \\ We love 🍕!' \ -i /etc/pam.d/sshd ## Client test In the same host: ssh -o PubkeyAuthentication=no \ -o PasswordAuthentication=no \ -o PreferredAuthentications=keyboard-interactive \ $USER@localhost The client should show: Hello SSHD \ We love 🍕! ($USER@localhost) Password: ... Hello from SSHD \ We also love 🍕! Retry the same with another host and without keyboard authentication enabled in the server side. To verify the fix in more complex scenario it's possible to follow the instructions of configuring authd: - https://github.com/ubuntu/authd/wiki/05--How%E2%80%90to-log-in-over-SSH Once authd is configured, the user should be able to scan a QrCode from a ssh session. ## Cleanup Revert the changes done in the cleanup phase, after test is done sudo sed '/pam_echo\.so/d' -i /etc/pam.d/sshd sudo rm /etc/ssh/sshd_config.d/test-ssh-pam.conf [ Regression potential ] SSH info messages are not shown by the client. Even though those aren't covered by this change, it's important to check for regressions in any output that SSH exposes to the user. So banners and other messages should be checked for regressions. These kind of messages are normally shown only when PAM *and* keyboard interaction are enabled in the server side, so it should not affect the default ubuntu servers behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2077576/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
