Mailing List Archive

planning for deprecations
Hi,

    I have a few servers where a lot of different client implementation
connect and I want to proactively see who will break as certain key
exchange protocols and ciphers get deprecated (e.g. rsa-sha1).  One
thing that would be helpful, and perhaps this could be changed going
forward is setting the loglevel to verbose from debug ? e.g. something
like this would make planning / migration a little easier for admins
without having to go full debug level, which brings in a lot more data
than necessary. (diff is from FreeBSD's RELENG_12 copy, but the idea is
the same)

--- crypto/openssh/kex.c.prev   2021-10-14 06:50:53.862633000 -0400
+++ crypto/openssh/kex.c        2021-10-14 06:51:20.902653000 -0400
@@ -761,7 +761,7 @@

        k->name = match_list(client, server, NULL);

-       debug("kex: algorithm: %s", k->name ? k->name : "(no match)");
+       verbose("kex: algorithm: %s", k->name ? k->name : "(no match)");
        if (k->name == NULL)
                return SSH_ERR_NO_KEX_ALG_MATCH;
        if ((kexalg = kex_alg_by_name(k->name)) == NULL)
@@ -777,7 +777,7 @@
 {
        k->hostkey_alg = match_list(client, server, NULL);

-       debug("kex: host key algorithm: %s",
+       verbose("kex: host key algorithm: %s",
            k->hostkey_alg ? k->hostkey_alg : "(no match)");
        if (k->hostkey_alg == NULL)
                return SSH_ERR_NO_HOSTKEY_ALG_MATCH;
@@ -892,7 +892,7 @@
                        peer[ncomp] = NULL;
                        goto out;
                }
-               debug("kex: %s cipher: %s MAC: %s compression: %s",
+               verbose("kex: %s cipher: %s MAC: %s compression: %s",
                    ctos ? "client->server" : "server->client",
                    newkeys->enc.name,
                    authlen == 0 ? newkeys->mac.name : "<implicit>",


    ---Mike


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: planning for deprecations [ In reply to ]
On Thu, Oct 14, 2021 at 7:30 AM mike tancsa <mike@sentex.net> wrote:
> I have a few servers where a lot of different client implementation
> connect and I want to proactively see who will break as certain key
> exchange protocols and ciphers get deprecated (e.g. rsa-sha1). One
> thing that would be helpful, and perhaps this could be changed going
> forward is setting the loglevel to verbose from debug ?

I enthusiastically second this request: it would be tremendously useful
to have sshd log the characteristics of the encryption that is
negotiated with the client without having to raise LogLevel to DEBUG,
because 1) DEBUG logs a lot of unnecessary information, and 2)
sshd_config(5) specifically warns that DEBUG violates user privacy.

One quibble, though: I don’t think this log format:

kex: host key algorithm: %s

…is the best way to do it. Logging just the host key algorithm on a line
by itself makes mass log analysis (e.g. Splunk, Grafana) challenging,
because the necessary information to figure out what host/user
negotiated that algorithm is on a separate line.

What I think would make a lot more sense is to simply log the encryption
characteristics in the "Accepted" summary line. E.g., instead of this
(line folded for readability):

Accepted
gssapi-keyex
for username
from 1.2.3.4
port 12335
ssh2:
username@EXAMPLE.ORG

Log this:

Accepted
method gssapi-keyex
kex gss-group14-sha1-
cipher aes256-gcm@openssh.com
mac implicit
for username
from 1.2.3.4
port 12335
ssh2:
username@EXAMPLE.ORG

This is a trivial amount of information to add to the line, it doesn’t
violate user privacy, and it would already be logged at LogLevel INFO
without administrators specifically needing to move to LogLevel VERBOSE.

If there is a concern that changing the format of the "Accepted" line
will perturb too many people, then perhaps a compromise would be to have
LogLevel VERBOSE log a new line that logs as much useful information
about the incoming connection as it can (anything that doesn’t violate
user privacy), on a single line, specifically to aid mass log analysis.
E.g.:

connection:
method=gssapi-keyex,
kex=gss-group14-sha1-,
cipher=aes256-gcm@openssh.com,
mac=implicit,
from_ip=1.2.3.4,
from_port=12335,
to_ip=5.6.7.8,
to_port=22,
user=username

Or, if administrators just want this information but not the other lines
that setting LogLevel VERBOSE entails, maybe there could be a separate
boolean option to enable logging this line? E.g.:

LogConnectionInfo no (default)
LogConnectionInfo yes

If the administrator sets "LogConnectionInfo yes", then sshd logs the
"connection:" log message at LogLevel INFO (the default LogLevel).

Thoughts?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev