9

It's possible to configure a banner for sshd that is to be displayed as a connection is opened, via Banner /etc/motd.ssh in sshd_config. Note that this is displayed before the authentication occurs, and even when an interactive shell is not launched (e.g. via scp).

If this banner contains characters outside of the printable ASCII range, they seem to be escaped, however. Is there any way to either disable this escaping, or an alternative way to send textual output back to the client on connection which supports such characters outside of the printable-ASCII range?

This would be useful both for colour escape sequences and Unicode characters.

  • Related: Colorful ssh banner (not a duplicate, however, as this question is about another kind of banner, not about color)
Improve this question
2
  • This Q is asking if it's possible to display special characters using the SSH Banner feature, right?
    – slm ♦
    Commented Jan 12, 2014 at 21:49
  • 1
    @slm yes, or if there is an alternative to it, if it's not possible. I suspect the answer is 'no', but I couldn't find any definitive answer when searching.
    – FireFly
    Commented Jan 12, 2014 at 21:55

2 Answers 2

Reset to default
9

Mention #1 - LinuxFromScratch project

One place that it's mentioned is in the Linux From Scratch project. I found this page titled: /etc/issue (Customizing your logon).

excerpt

The /etc/issue file is a plain text file which will also accept certain Escape sequences (see below) in order to insert information about the system. There is also the file issue.net which can be used when logging on remotely. ssh however, will only use it if you set the option in the configuration file and will also not interpret the escape sequences shown below.

Mention #2 - SecurityFocus Forum post

As additional evidence that this is not possible there is this excerpt from a forum post titled: Re: ssh and banners Aug 18 2009 01:20PM, that discusses the function that implements the printing of the banner in OpenSSH.

excerpt

After doing some more digging, I found that there is a function in the ssh source (specifically sshconnect2.c) called "input_userauth_banner" that displays the banner from the server. The text of the banner is now being filtered through another function called "strnvis" that encodes non-printable ascii characters as printable text, ie: octal codes. This is why the ansi escape sequence is displayed as "\033[". The documentation for strnvis doesn't mention any security issues, only "unexpected behavior" that could be associated with non-printable characters.

Mention #3 - OpenSSH Release Notes + RFC's

Lastly I encourage you to look through the release notes for OpenSSH. They're here as well as the RFC's that govern the SSH v1 & v2 specifications.

This RFC covers some of the behavior of the Banner feature. This section "5.4. Banner Message" covers the details of why this isn't allowed. This paragraph is where is says this is explicitly disallowed.

excerpt

If the 'message' string is displayed, control character filtering, discussed in [SSH-ARCH], SHOULD be used to avoid attacks by sending terminal control characters.

Additional references (per @hildred)

Improve this answer
5
  • This is exactly what I'm currently using. /etc/issue.net is a common name for Banner, and as mentioned in the question non-printable ASCII characters seem to be escaped by sshd here. Sorry, my question might've been a bit unclear.
    – FireFly
    Commented Jan 12, 2014 at 22:09
  • @FireFly - I think the gist of that comment is that ssh's banner facility will not allow you to include escape sequences by design. That's what you want confirmation of, right?
    – slm ♦
    Commented Jan 12, 2014 at 22:18
  • 1
    Yeah, I suppose. I'll accept this for the time being, but I was of course hoping for a workaround instead. :P but alas, seems it's not possible.
    – FireFly
    Commented Jan 12, 2014 at 22:23
  • @FireFly - I don't think you're going to get what you want. I usually do it in the .bashrc or motd afterwards if I want control chars + colors. See my updates. I added all the details that show that it's not possible.
    – slm ♦
    Commented Jan 12, 2014 at 22:56
  • @FireFly - I remember looking into this several years ago and hitting the wall too and wondering why, I just shelved it, but now we know that it's for security reasons.
    – slm ♦
    Commented Jan 12, 2014 at 23:12
2

The openssh client has a bug in its unsafe character filter which instead of filtering control characters, filters out everything but printable ascii (the spec calls for printable utf8) a patch to the client will fix this.

Improve this answer
9
  • It’s not a bug. It’s unwillingness to make complex investigations about $LANG, $TERM, and correct methods of output in the current environment. As well as a (hyper)caution due to existence of old ASCII- and ISO-8859-oriented terminal emulator software that can be confused by high-bit-set octets, especially from the C1 (\200–\237) range.
    – Incnis Mrsi
    Commented Sep 4, 2015 at 16:48
  • The C1 range is not the issue, it is rejecting everything greater than 0x80. if it was just a C1 issue it would accept properly formatted utf8 as the c1 range is undefined in unicode. $TERM is not an issue as most of C0 is also escaped the $LANG check is simple, either it accepts utf8 or it does not. if it does not the current behavior is only slightly broken. If you are using utf8 the current behavior breaks laws in china and anywhere that legal notices are required in languages other than english. bottom line: bug.
    – hildred
    Commented Sep 4, 2015 at 17:14
  • Did you mention the word octet? Half of UTF-8 continuation byte range (\200–\277) strays into what would be C1 in an ISO-8859-compatible encoding. For example: 2×2 encoded in UTF-8 (can you feed it to “LANG=C od -c”?) contains a “C1” byte.
    – Incnis Mrsi
    Commented Sep 4, 2015 at 17:30
  • No I did not use the word octet, as it does not cleanly apply to variable length encodings like utf8, which is what the network encoding is here, not iso-8859, not latin1, not ascii, utf8. You are correct that the safe character filter does treat it as octets. That is the bug. Further if memory serves it does not check for the C1 range, but any byte with the high bit set.
    – hildred
    Commented Sep 4, 2015 at 17:48
  • We don’t discuss network protocols and conventions. We discuss how to output internationalized characters in an arbitrary terminal environment. Ī̲ agree that $LANG with “utf8” might suggest to proceed with a safe UTF-8 text, but the problem is due to legacy (ISO-8859-oriented and alike) terminal environments. In this case (where we assume a reasonable user won’t set a UTF-8 locale) there are namely unsafe octets, not unsafe characters.
    – Incnis Mrsi
    Commented Sep 4, 2015 at 18:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .