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)
  • This Q is asking if it's possible to display special characters using the SSH Banner feature, right? – slm Jan 12 '14 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 Jan 12 '14 at 21:55
up vote 8 down vote accepted

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)

  • 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 Jan 12 '14 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 Jan 12 '14 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 Jan 12 '14 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 Jan 12 '14 at 22:56
  • I think you're right. Thanks! – FireFly Jan 12 '14 at 23:07

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.

  • 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 Sep 4 '15 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 Sep 4 '15 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 Sep 4 '15 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 Sep 4 '15 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 Sep 4 '15 at 18:09

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.