Hello. I've got a question about encoding in sshd's log files. When I try to log in with a "?" username, which is a cyrillic "h" (U+0445), I get this message in a logfile: input_userauth_request: invalid user \\321\\205 [preauth]. I am struggling to understand: is that hex, is that octal? It doesn't map to any encoding that I know of.
On Mon, Feb 13, 2017 at 5:12 PM, Andrey Klimentev <andrei650816 at gmail.com> wrote:> Hello. > > I've got a question about encoding in sshd's log files. > > When I try to log in with a "?" username, which is a cyrillic "h" (U+0445), > I get this message in a logfile: input_userauth_request: invalid user > \\321\\205 [preauth].I'ts run through strnvis[1] with some options with different options depending on whether it's going to syslog or stderr, but both include VIS_OCTAL so that should be what anything unusual ends up as. That said, assuming what you posted is exactly what it logged, it looks to me as if it was sent the literal string "\321\205" and sshd just escaped the backslashes. Are you sure the client is sending what you think it's sending? In log.c: #define LOG_SYSLOG_VIS (VIS_CSTYLE|VIS_NL|VIS_TAB|VIS_OCTAL) #define LOG_STDERR_VIS (VIS_SAFE|VIS_OCTAL) [...] strnvis(fmtbuf, msgbuf, sizeof(fmtbuf), log_on_stderr ? LOG_STDERR_VIS : LOG_SYSLOG_VIS); [1] http://man.openbsd.org/OpenBSD-current/man3/vis.3 -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
(re-adding openssh-unix-dev) On Mon, Feb 13, 2017 at 6:18 PM, Andrey Klimentev <andrei650816 at gmail.com> wrote:> Thank you for a quick response. > > Indeed, it looks like the OpenSSH client sends it as a string: debug1: > Authenticating to jump1-m.vt.ru:22 as '\321\205'Well that's also passed through the same escaping in log.c.> PAM module has no problem with interpreting that value, though. Here is a > full auth.log: > > Feb 13 09:01:02 jump1 sshd[31722]: Invalid user \321\205 from 192.168.54.109This one is encoded as expected.> Feb 13 09:01:02 jump1 sshd[31722]: input_userauth_request: invalid user > \\321\\205 [preauth]This one is double encoded for some reason. What version of sshd are you using?> Feb 13 09:01:06 jump1 sshd[31722]: Failed password for invalid user \321\205 > from 192.168.54.109 port 43826 ssh2This one is also as expected. Anyway, that value is $ perl -le 'printf "%x %x\n", 0321, 0205' d1 85 which seems to be the UTF8 encoding of U+0445: http://www.fileformat.info/info/unicode/char/0445/index.htm> Naturally, the question now arises: how does a client encode it and why does > PAM correctly decode it and write it to the syslog properly?With the exception of one instance of double-encoding in the logging, it seems to be doing what you'd expect. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
(re-added openssh-unix-dev) Oh god, I forgot that UTF-8 is encoded with multiple bytes. My sincerest apologies! I use OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013, if logfile double encoding is a real problem for OpenSSH developers. My question is fully answered. Thanks! 2017-02-13 11:02 GMT+03:00 Darren Tucker <dtucker at zip.com.au>:> (re-adding openssh-unix-dev) > > On Mon, Feb 13, 2017 at 6:18 PM, Andrey Klimentev > <andrei650816 at gmail.com> wrote: > > Thank you for a quick response. > > > > Indeed, it looks like the OpenSSH client sends it as a string: debug1: > > Authenticating to jump1-m.vt.ru:22 as '\321\205' > > Well that's also passed through the same escaping in log.c. > > > PAM module has no problem with interpreting that value, though. Here is a > > full auth.log: > > > > Feb 13 09:01:02 jump1 sshd[31722]: Invalid user \321\205 from > 192.168.54.109 > > This one is encoded as expected. > > > Feb 13 09:01:02 jump1 sshd[31722]: input_userauth_request: invalid user > > \\321\\205 [preauth] > > This one is double encoded for some reason. What version of sshd are you > using? > > > Feb 13 09:01:06 jump1 sshd[31722]: Failed password for invalid user > \321\205 > > from 192.168.54.109 port 43826 ssh2 > > This one is also as expected. Anyway, that value is > > $ perl -le 'printf "%x %x\n", 0321, 0205' > d1 85 > > which seems to be the UTF8 encoding of U+0445: > http://www.fileformat.info/info/unicode/char/0445/index.htm > > > Naturally, the question now arises: how does a client encode it and why > does > > PAM correctly decode it and write it to the syslog properly? > > With the exception of one instance of double-encoding in the logging, > it seems to be doing what you'd expect. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. >-- ? ?????????, ?????? ??????????.