Hi, According to the standards of SSH protocol, both server and client banners should end with CRLF if SSH 1.0 is disabled on configuration.
When the connection has been established, both sides MUST send an
identification string. This identification string MUST be
SSH-protoversion-softwareversion SP comments CR LF
Since the protocol being defined in this set of documents is version
2.0, the 'protoversion' MUST be "2.0". The 'comments' string is
OPTIONAL. If the 'comments' string is included, a 'space' character
(denoted above as SP, ASCII 32) MUST separate the 'softwareversion'
and 'comments' strings. The identification MUST be terminated by a
single Carriage Return (CR) and a single Line Feed (LF) character
(ASCII 13 and 10, respectively).And OpenSSH also implements this behavior: static void send_client_banner(int connection_out, int minor1) { /* Send our own protocol version identification. */ if (compat20) { xasprintf(&client_version_string, "SSH-%d.%d-%.100s\r\n", PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION); } else { xasprintf(&client_version_string, "SSH-%d.%d-%.100s\n", PROTOCOL_MAJOR_1, minor1, SSH_VERSION); } if (roaming_atomicio(vwrite, connection_out, client_version_string, strlen(client_version_string)) != strlen(client_version_string)) fatal("write: %.100s", strerror(errno)); chop(client_version_string); debug("Local version string %.100s", client_version_string); } Libssh on the other hand, banners always end with LF. In the most of case, it’s not a problem. But if a firewall / IPS analyses the package, only do a immediate packet relay for which payload end with CRLF (e.g. 80 and 443 ports opened by firewall), there will be a big problem. In attached patch, libssh banners end with “\r\n” if SSH 1 disabled in configuration, but keep origin behavior (send “\n”) if SSH 1 still allowed. Cheers, Yang |
patch-endwith-crlf.diff
Description: Binary data
