[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Patch] Banner should end with CRLF for SSH 2.0
[Thread Prev] | [Thread Next]
- Subject: [Patch] Banner should end with CRLF for SSH 2.0
- From: Yang Yubo <yang@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Sun, 18 Oct 2015 16:41:36 +0800
- To: libssh@xxxxxxxxxx
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.
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 |
Attachment:
patch-endwith-crlf.diff
Description: Binary data
Archive administrator: postmaster@lists.cynapses.org