Logfile encoding question

Darren Tucker dtucker at zip.com.au
Mon Feb 13 19:02:12 AEDT 2017


(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.


More information about the openssh-unix-dev mailing list