From ronan at rjp.ie Thu Jun 1 13:40:56 2023 From: ronan at rjp.ie (Ronan Pigott) Date: Thu, 01 Jun 2023 03:40:56 +0000 Subject: Matching the local domain Message-ID: <08c75a6eb88f2d402871110bd794ae6a@rjp.ie> Hey ssh users, I'd really like a method to match my local host domain in my ssh config. Basically if I travel with my laptop I get a domain from dhcp and want to match a Host section based on this domain like *.localdomain. It doesn't seem like this is currently possible? I tried adding a new %D percent token to ssh but Host doesn't accept such tokens, only patterns, so that's a bust. Is this currently possible with openssh? If not, any good ideas for what the config syntax should be? Cheers, Ronan From mike at sentex.net Fri Jun 2 00:54:59 2023 From: mike at sentex.net (mike tancsa) Date: Thu, 1 Jun 2023 10:54:59 -0400 Subject: openssh portable on FreeBSD i386 Message-ID: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> Hi All, ??? I am trying to compile OpenSSH portable 9.3p1 on FreeBSD RELENG_13? but on *i386*.? With the compiler defaults, it errors out with -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c channels.c -o channels.o channels.c:2569:12: error: comparison of integers of different signs: 'time_t' (aka 'int') and 'unsigned int' [-Werror,-Wsign-compare] ??????????????????????????? now >= c->lastused + c->inactive_deadline) { ??????????????????????????? ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Not sure if this is the right approach / patch, but I am able to compile and run with --- channels.c.orig???? 2023-03-15 21:28:19 UTC +++ channels.c @@ -2566,7 +2566,12 @@ channel_handler(struct ssh *ssh, int table, struct tim ??????????????????????? if (table == CHAN_PRE && ??????????????????????????? c->type == SSH_CHANNEL_OPEN && ??????????????????????????? c->inactive_deadline != 0 && c->lastused != 0 && +?????????????????????????? #if defined(__i386__) +?????????????????????????? now >= (time_t) c->lastused + (time_t) c->inactive_deadline) { +?????????????????????????? #else ??????????????????????????? now >= c->lastused + c->inactive_deadline) { +?????????????????????????? #endif + ??????????????????????????????? /* channel closed for inactivity */ ??????????????????????????????? verbose("channel %d: closing after %u seconds " ??????????????????????????????????? "of inactivity", c->self, Is that the right approach, or am I potentially breaking something somewhere else that also needs a cast ? tracked at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271172 for any FreeBSD people ??? ---Mike From t.glaser at tarent.de Fri Jun 2 01:47:54 2023 From: t.glaser at tarent.de (Thorsten Glaser) Date: Thu, 1 Jun 2023 17:47:54 +0200 (CEST) Subject: openssh portable on FreeBSD i386 In-Reply-To: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> References: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> Message-ID: <1ed9b7-98b-e81a-1554-ead72aba866d@tarent.de> On Thu, 1 Jun 2023, mike tancsa wrote: > Not sure if this is the right approach / patch, but I am able to compile No, I?d rather convert the known value to the type-of-unknown-signedness (might even be float). -?????????????????????????? now >= c->lastused + c->inactive_deadline) { +?????????????????????????? now >= c->lastused + (time_t)c->inactive_deadline) { In general, #ifdef i386 is wrong. bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! **************************************************** From mike at sentex.net Fri Jun 2 02:01:44 2023 From: mike at sentex.net (mike tancsa) Date: Thu, 1 Jun 2023 12:01:44 -0400 Subject: openssh portable on FreeBSD i386 In-Reply-To: <1ed9b7-98b-e81a-1554-ead72aba866d@tarent.de> References: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> <1ed9b7-98b-e81a-1554-ead72aba866d@tarent.de> Message-ID: On 6/1/2023 11:47 AM, Thorsten Glaser wrote: > On Thu, 1 Jun 2023, mike tancsa wrote: > >> Not sure if this is the right approach / patch, but I am able to compile > No, I?d rather convert the known value to the type-of-unknown-signedness > (might even be float). > > -?????????????????????????? now >= c->lastused + c->inactive_deadline) { > +?????????????????????????? now >= c->lastused + (time_t)c->inactive_deadline) { > > In general, #ifdef i386 is wrong. Thanks, compile/build and run tested on FreeBSD 13 both i386 and AMD64 with the following patch --- channels.c.orig???? 2023-06-01 15:52:19 UTC +++ channels.c @@ -2566,7 +2566,7 @@ channel_handler(struct ssh *ssh, int table, struct tim ??????????????????????? if (table == CHAN_PRE && ??????????????????????????? c->type == SSH_CHANNEL_OPEN && ??????????????????????????? c->inactive_deadline != 0 && c->lastused != 0 && -?????????????????????????? now >= c->lastused + c->inactive_deadline) { +?????????????????????????? now >= c->lastused + (time_t) c->inactive_deadline) { ??????????????????????????????? /* channel closed for inactivity */ ??????????????????????????????? verbose("channel %d: closing after %u seconds " ??????????????????????????????????? "of inactivity", c->self, ??? ---Mike From Todd.Miller at sudo.ws Fri Jun 2 02:39:41 2023 From: Todd.Miller at sudo.ws (Todd C. Miller) Date: Thu, 01 Jun 2023 10:39:41 -0600 Subject: openssh portable on FreeBSD i386 In-Reply-To: Your message of "Thu, 01 Jun 2023 12:01:44 -0400." References: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> <1ed9b7-98b-e81a-1554-ead72aba866d@tarent.de> Message-ID: My inclination would be to just make the timeout signed to match time_t. No need for ugly casts then and parse_timeout() parses the number as an int anyway (rejecting negative values). As far as I can see there is no way for these values to be larger than an int. - todd Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.430 diff -u -p -u -r1.430 channels.c --- channels.c 10 Mar 2023 03:01:51 -0000 1.430 +++ channels.c 1 Jun 2023 16:32:38 -0000 @@ -146,7 +146,7 @@ struct permission_set { /* Used to record timeouts per channel type */ struct ssh_channel_timeout { char *type_pattern; - u_int timeout_secs; + int timeout_secs; }; /* Master structure for channels state */ @@ -304,11 +304,11 @@ channel_lookup(struct ssh *ssh, int id) */ void channel_add_timeout(struct ssh *ssh, const char *type_pattern, - u_int timeout_secs) + int timeout_secs) { struct ssh_channels *sc = ssh->chanctxt; - debug2_f("channel type \"%s\" timeout %u seconds", + debug2_f("channel type \"%s\" timeout %d seconds", type_pattern, timeout_secs); sc->timeouts = xrecallocarray(sc->timeouts, sc->ntimeouts, sc->ntimeouts + 1, sizeof(*sc->timeouts)); @@ -332,7 +332,7 @@ channel_clear_timeouts(struct ssh *ssh) sc->ntimeouts = 0; } -static u_int +static int lookup_timeout(struct ssh *ssh, const char *type) { struct ssh_channels *sc = ssh->chanctxt; Index: channels.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.h,v retrieving revision 1.149 diff -u -p -u -r1.149 channels.h --- channels.h 4 Mar 2023 03:22:59 -0000 1.149 +++ channels.h 1 Jun 2023 16:28:59 -0000 @@ -207,7 +207,7 @@ struct Channel { /* Last traffic seen for OPEN channels */ time_t lastused; /* Inactivity timeout deadline in seconds (0 = no timeout) */ - u_int inactive_deadline; + int inactive_deadline; }; #define CHAN_EXTENDED_IGNORE 0 @@ -305,7 +305,7 @@ int channel_close_fd(struct ssh *, Chan void channel_send_window_changes(struct ssh *); /* channel inactivity timeouts */ -void channel_add_timeout(struct ssh *, const char *, u_int); +void channel_add_timeout(struct ssh *, const char *, int); void channel_clear_timeouts(struct ssh *); /* mux proxy support */ Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.393 diff -u -p -u -r1.393 servconf.c --- servconf.c 24 May 2023 23:01:06 -0000 1.393 +++ servconf.c 1 Jun 2023 16:31:34 -0000 @@ -908,7 +908,7 @@ process_permitopen(struct ssh *ssh, Serv /* Parse a ChannelTimeout clause "pattern=interval" */ static int -parse_timeout(const char *s, char **typep, u_int *secsp) +parse_timeout(const char *s, char **typep, int *secsp) { char *cp, *sdup; int secs; @@ -934,7 +934,7 @@ parse_timeout(const char *s, char **type if (typep != NULL) *typep = xstrdup(sdup); if (secsp != NULL) - *secsp = (u_int)secs; + *secsp = secs; free(sdup); return 0; } @@ -942,7 +942,8 @@ parse_timeout(const char *s, char **type void process_channel_timeouts(struct ssh *ssh, ServerOptions *options) { - u_int i, secs; + int secs; + u_int i; char *type; debug3_f("setting %u timeouts", options->num_channel_timeouts); From t.glaser at tarent.de Fri Jun 2 02:50:42 2023 From: t.glaser at tarent.de (Thorsten Glaser) Date: Thu, 1 Jun 2023 18:50:42 +0200 (CEST) Subject: openssh portable on FreeBSD i386 In-Reply-To: References: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> <1ed9b7-98b-e81a-1554-ead72aba866d@tarent.de> Message-ID: On Thu, 1 Jun 2023, Todd C. Miller wrote: >My inclination would be to just make the timeout signed to match >time_t. No need for ugly casts then and parse_timeout() parses the For OpenSSH itself, sure. For portable OpenSSH that?s not an option; time_t can be unsigned, signed, or even float. Another option would be to make the variable also time_t, but that would waste much space on contemporary platforms due to Y2038, so I think that, here, the cast is better. bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! **************************************************** From Todd.Miller at sudo.ws Fri Jun 2 03:03:46 2023 From: Todd.Miller at sudo.ws (Todd C. Miller) Date: Thu, 01 Jun 2023 11:03:46 -0600 Subject: openssh portable on FreeBSD i386 In-Reply-To: Your message of "Thu, 01 Jun 2023 18:50:42 +0200." References: <8ddeef8a-ceb6-a02b-d496-0d3f69e141ec@sentex.net> <1ed9b7-98b-e81a-1554-ead72aba866d@tarent.de> Message-ID: On Thu, 01 Jun 2023 18:50:42 +0200, Thorsten Glaser wrote: > For OpenSSH itself, sure. For portable OpenSSH that?s not an option; > time_t can be unsigned, signed, or even float. > > Another option would be to make the variable also time_t, but that > would waste much space on contemporary platforms due to Y2038, so > I think that, here, the cast is better. POSIX stopped allowing time_t to be floating point some time ago (and I don't think anyone ever implemented it that way) but that is completely irrelevant to the diff at hand. Even if time_t was unsigned, this would not be a problem for the comparison in question. The result of "c->lastused + c->inactive_deadline" would be unsigned if time_t is unsigned so there is no need to cast c->inactive_deadline that I can see. - todd From ronan at rjp.ie Mon Jun 5 12:23:06 2023 From: ronan at rjp.ie (Ronan Pigott) Date: Sun, 4 Jun 2023 19:23:06 -0700 Subject: [PATCH] Permite %L and %l percent escapes in Include Message-ID: <20230605022307.32817-1-ronan@rjp.ie> This allows the localhost percent-style escapes in arguments to the Include directive. These are useful for including host-specific ssh configuration. --- readconf.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/readconf.c b/readconf.c index 0816ef6b3873..89ba14535dbe 100644 --- a/readconf.c +++ b/readconf.c @@ -941,7 +941,8 @@ process_config_line_depth(Options *options, struct passwd *pw, const char *host, const char *original_host, char *line, const char *filename, int linenum, int *activep, int flags, int *want_final_pass, int depth) { - char *str, **charptr, *endofnumber, *keyword, *arg, *arg2, *p; + char *str, **charptr, *endofnumber, *keyword, *arg, *arg2, *arg_pre, *p; + char thishost[NI_MAXHOST], shorthost[NI_MAXHOST]; char **cpptr, ***cppptr, fwdarg[256]; u_int i, *uintptr, uvalue, max_entries = 0; int r, oactive, negated, opcode, *intptr, value, value2, cmdline = 0; @@ -1856,6 +1857,12 @@ parse_pubkey_algos: "command-line option"); goto out; } + + if (gethostname(thishost, sizeof(thishost)) == -1) + fatal("gethostname: %s", strerror(errno)); + strlcpy(shorthost, thishost, sizeof(shorthost)); + shorthost[strcspn(thishost, ".")] = '\0'; + value = 0; while ((arg = argv_next(&ac, &av)) != NULL) { if (*arg == '\0') { @@ -1876,11 +1883,14 @@ parse_pubkey_algos: goto out; } if (!path_absolute(arg) && *arg != '~') { - xasprintf(&arg2, "%s/%s", + xasprintf(&arg_pre, "%s/%s", (flags & SSHCONF_USERCONF) ? "~/" _PATH_SSH_USER_DIR : SSHDIR, arg); } else - arg2 = xstrdup(arg); + arg_pre = xstrdup(arg); + arg2 = percent_expand(arg_pre, + "l", thishost, "L", shorthost, (char *) NULL); + free(arg_pre); memset(&gl, 0, sizeof(gl)); r = glob(arg2, GLOB_TILDE, NULL, &gl); if (r == GLOB_NOMATCH) { -- 2.41.0 From yuri at rawbw.com Mon Jun 5 16:24:44 2023 From: yuri at rawbw.com (Yuri) Date: Sun, 4 Jun 2023 23:24:44 -0700 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings Message-ID: I have sshd listening on several ports for various reasons. sshd periodically logs errors like these: > Jun? 4 22:52:52 xx sshd[30708]: error: Fssh_kex_exchange_identification: banner line contains invalid characters This message would be a lot more helpful if it would contain the port number for this connection. It would be easier to figure out where offending connections come from. Thanks, Yuri From dtucker at dtucker.net Mon Jun 5 16:59:48 2023 From: dtucker at dtucker.net (Darren Tucker) Date: Mon, 5 Jun 2023 16:59:48 +1000 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 at 16:29, Yuri wrote: > ssh_kex_exchange_identification: banner line contains invalid characters [...] > It would be easier to figure out where offending connections come from. The subsequent log line from sshpkt_fatal contains the source address and port of that connection: $ sudo `pwd`/sshd -ddd -p 2022 [...] kex_exchange_identification: banner line contains invalid characters banner exchange: Connection from 127.0.0.1 port 52410: invalid format -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From yuri at rawbw.com Mon Jun 5 17:06:20 2023 From: yuri at rawbw.com (Yuri) Date: Mon, 5 Jun 2023 00:06:20 -0700 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: References: Message-ID: On 6/4/23 23:59, Darren Tucker wrote: > The subsequent log line from sshpkt_fatal contains the source address > and port of that connection: > > $ sudo `pwd`/sshd -ddd -p 2022 > [...] > kex_exchange_identification: banner line contains invalid characters > banner exchange: Connection from 127.0.0.1 port 52410: invalid format I am using sshd on FreeBSD 13.2 and it only logs the first line. Does the second line require some special setting values to be printed? Yuri From dtucker at dtucker.net Mon Jun 5 18:11:39 2023 From: dtucker at dtucker.net (Darren Tucker) Date: Mon, 5 Jun 2023 18:11:39 +1000 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 at 17:06, Yuri wrote: > On 6/4/23 23:59, Darren Tucker wrote: > > The subsequent log line from sshpkt_fatal contains the source address > > and port of that connection: [...] > I am using sshd on FreeBSD 13.2 and it only logs the first line. FreeBSD 13's OpenSSH is based on 8.0p1, which is a bit over four years old at this point. > Does the second line require some special setting values to be printed? No. It was added in 2022 in this commit, which was first in OpenSSH 8.3: https://github.com/openssh/openssh-portable/commit/5becbec023f2037394987f85ed7f74b9a28699e0 -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at dtucker.net Mon Jun 5 18:14:23 2023 From: dtucker at dtucker.net (Darren Tucker) Date: Mon, 5 Jun 2023 18:14:23 +1000 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 at 18:11, Darren Tucker wrote: > On Mon, 5 Jun 2023 at 17:06, Yuri wrote: [...] > > Does the second line require some special setting values to be printed? > > No. It was added in 2022 in this commit, which was first in OpenSSH 8.3: correction: 2020. > https://github.com/openssh/openssh-portable/commit/5becbec023f2037394987f85ed7f74b9a28699e0 -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Jochen.Bern at binect.de Mon Jun 5 18:15:39 2023 From: Jochen.Bern at binect.de (Jochen Bern) Date: Mon, 5 Jun 2023 10:15:39 +0200 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings Message-ID: <8a48d54a-c6c5-2cea-9cf3-665949a85d81@binect.de> On 05.06.23 08:59, Darren Tucker wrote: > On Mon, 5 Jun 2023 at 16:29, Yuri wrote: >> ssh_kex_exchange_identification: banner line contains invalid characters > [...] >> It would be easier to figure out where offending connections come from. > > The subsequent log line from sshpkt_fatal contains the source address > and port of that connection: I think that Yuri meant (one of his several) ssh*d*-side port(s). There is SyslogFacility (plus the filtering capabilities of modern syslogd's), but since that would quite likely leak sensitive information out of the (better-protected) /var/log/secure on RHEL-like systems, I can't really recommend (ab)using it. However, I guess that allowing the sysadmin to change the progname/ident parameter of the syslogging (like you can with the "daemon XYZ" setting for multi-instance OpenVPN servers), rather than having it fixed to "sshd", would prove more versatile than specifically adding the Port to selected message( string)s ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: From dtucker at dtucker.net Mon Jun 5 18:56:12 2023 From: dtucker at dtucker.net (Darren Tucker) Date: Mon, 5 Jun 2023 18:56:12 +1000 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: <8a48d54a-c6c5-2cea-9cf3-665949a85d81@binect.de> References: <8a48d54a-c6c5-2cea-9cf3-665949a85d81@binect.de> Message-ID: On Mon, 5 Jun 2023 at 18:37, Jochen Bern wrote: > On 05.06.23 08:59, Darren Tucker wrote: [...] > > The subsequent log line from sshpkt_fatal contains the source address > > and port of that connection: > > I think that Yuri meant (one of his several) ssh*d*-side port(s). Yes he asked about server side ports, but the stated reason was "It would be easier to figure out where offending connections come from" hence my answer. -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dawid.majchrzak at nokia.com Mon Jun 5 20:36:58 2023 From: dawid.majchrzak at nokia.com (Dawid Majchrzak (Nokia)) Date: Mon, 5 Jun 2023 10:36:58 +0000 Subject: [bug][sshd][security] ClientAliveInterval multiplied twice Message-ID: < AM0PR0702MB35393449178F6BC2E9CAEDF9E94DA%AM0PR0702MB3539.eurprd07.prod.outlook.com@mailhub.eait.uq.edu.au> Hello, My team discovered that starting from openssh v9.2 a ClientAliveInterval param from /etc/ssh/sshd_config is interpreted as multiplied twice value. ---- Component: sshd Version: 9.2p1 and higher Hardware: ARM64 OS:Linux ---- sshd_config ---- ClientAliveInterval 5 ClientAliveCountMax 3 --- Debug logs ---- [2023-05-29 12:00:16] debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 [2023-05-29 12:00:26] debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 [2023-05-29 12:00:36] debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 [2023-05-29 12:00:46] debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 ---- Looks like the problem was introduced with commit d478cdc7ad6edd4b1bcd1e86fb2f23194ff33d5a With a new ptimeout api sshd server can double a client probing interval time. commit d478cdc7ad6edd4b1bcd1e86fb2f23194ff33d5a Author: djm at openbsd.org Date: Fri Jan 6 02:38:23 2023 +0000 upstream: replace manual poll/ppoll timeout math with ptimeout API feedback markus / ok markus dtucker OpenBSD-Commit-ID: c5ec4f2d52684cdb788cd9cbc1bcf89464014be2 @@ -251,19 +237,18 @@ wait_until_can_do_something(struct ssh *ssh, *conn_in_readyp = (*pfdp)[0].revents != 0; *conn_out_readyp = (*pfdp)[1].revents != 0; + /* ClientAliveInterval probing */ if (client_alive_scheduled) { time_t now = monotime(); - - /* - * If the ppoll timed out, or returned for some other reason - * but we haven't heard from the client in time, send keepalive. - */ - if (ret == 0 || (last_client_time != 0 && last_client_time + - options.client_alive_interval <= now)) { + if (ret == 0 && + now > last_client_time + options.client_alive_interval) { + /* ppoll timed out and we're due to probe */ client_alive_check(ssh); last_client_time = now; - } else if (*conn_in_readyp) + } else if (ret != 0 && *conn_in_readyp) { + /* Data from peer; reset probe timer. */ last_client_time = now; + } } } This bug can be easily fixed by changing client_alive_check() condition. Proposed soulution/Fix: >From 6cf45ca16c51cc99b5210dea708e22e4dec8b2b0 Mon Sep 17 00:00:00 2001 From: Dawid Majchrzak Date: Wed, 31 May 2023 18:51:53 +0200 Subject: [PATCH] serverloop: Fix ClientAliveInterval probing condition Commit d478cdc7ad6edd4b1bcd1e86fb2f23194ff33d5a introduced ClientAliveInterval parameter regression that can double a probing interval time. Signed-off-by: Dawid Majchrzak --- serverloop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/serverloop.c b/serverloop.c index de5fa2e3..f160550e 100644 --- a/serverloop.c +++ b/serverloop.c @@ -253,7 +253,7 @@ wait_until_can_do_something(struct ssh *ssh, /* ClientAliveInterval probing */ if (client_alive_scheduled) { if (ret == 0 && - now > last_client_time + options.client_alive_interval) { + now >= last_client_time + options.client_alive_interval) { /* ppoll timed out and we're due to probe */ client_alive_check(ssh); last_client_time = now; -- 2.25.1 BR, Dawid From rapier at psc.edu Wed Jun 7 02:02:11 2023 From: rapier at psc.edu (Chris Rapier) Date: Tue, 6 Jun 2023 12:02:11 -0400 Subject: Possible overflow bug? Message-ID: While doing some related work I built openssh 9.3p1 with -fsanitize=address and this came up during compilation. In file included from /usr/include/string.h:535, from kex.c:34: In function 'explicit_bzero', inlined from 'kex_free_newkeys' at kex.c:743:2: /usr/include/bits/string_fortified.h:72:3: warning: '__explicit_bzero_chk' writing 48 bytes into a region of size 8 overflows the destination [-Wstringop-overflow=] 72 | __explicit_bzero_chk (__dest, __len, __glibc_objsize0 (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from kex.c:53: kex.h: In function 'kex_free_newkeys': kex.h:116:18: note: destination object 'name' of size 8 116 | char *name; | ^~~~ /usr/include/bits/string_fortified.h:66:6: note: in a call to function '__explicit_bzero_chk' declared with attribute 'access (write_only, 1, 2)' 66 | void __explicit_bzero_chk (void *__dest, size_t __len, size_t __destlen) Not sure if this is a real problem or not but I thought I'd pass it over just in case. Chris From peter at stuge.se Wed Jun 7 04:59:39 2023 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Jun 2023 18:59:39 +0000 Subject: Possible overflow bug? In-Reply-To: References: Message-ID: <20230606185939.14773.qmail@stuge.se> Chris Rapier wrote: > openssh 9.3p1 .. > In function 'explicit_bzero', > inlined from 'kex_free_newkeys' at kex.c:743:2: kex.c in tag V_9_3_P1 doesn't call explicit_bzero() on line 743, > '__explicit_bzero_chk' writing 48 bytes into a region of size 8 .. > kex.h: In function 'kex_free_newkeys': > kex.h:116:18: note: destination object 'name' of size 8 > 116 | char *name; ... in fact kex_free_newkeys() in tag V_9_3_P1 doesn't ever call explicit_bzero() with an object called 'name'. > Not sure if this is a real problem or not but I thought I'd pass it > over just in case. Could you check if you have any patch applied on top of V_9_3_P1? Thanks //Peter From rapier at psc.edu Wed Jun 7 06:18:26 2023 From: rapier at psc.edu (Chris Rapier) Date: Tue, 6 Jun 2023 16:18:26 -0400 Subject: Possible overflow bug? In-Reply-To: <20230606185939.14773.qmail@stuge.se> References: <20230606185939.14773.qmail@stuge.se> Message-ID: <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> On 6/6/23 2:59 PM, Peter Stuge wrote: > Chris Rapier wrote: >> openssh 9.3p1 > .. >> In function 'explicit_bzero', >> inlined from 'kex_free_newkeys' at kex.c:743:2: > > kex.c in tag V_9_3_P1 doesn't call explicit_bzero() on line 743, >> '__explicit_bzero_chk' writing 48 bytes into a region of size 8 > .. >> kex.h: In function 'kex_free_newkeys': >> kex.h:116:18: note: destination object 'name' of size 8 >> 116 | char *name; > > ... in fact kex_free_newkeys() in tag V_9_3_P1 doesn't ever call > explicit_bzero() with an object called 'name'. > > >> Not sure if this is a real problem or not but I thought I'd pass it >> over just in case. > > Could you check if you have any patch applied on top of V_9_3_P1? I'm using commit cb30fbdbee869f1ce11f06aa97e1cb8717a0b645 (HEAD, tag: V_9_3_P1, openssh-master/V_9_3) and git diff isn't reporting anything applied. And I just realized I grabbed that from the wrong window (which does have patches applied). Same thing exists in the canonical code. Here is the accurate one: In file included from /usr/include/string.h:535, from kex.c:34: In function ?explicit_bzero?, inlined from ?kex_free_newkeys? at kex.c:742:2: /usr/include/bits/string_fortified.h:72:3: warning: ?__explicit_bzero_chk? writing 48 bytes into a region of size 8 overflows the destination [-Wstringop-overflow=] 72 | __explicit_bzero_chk (__dest, __len, __glibc_objsize0 (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from kex.c:53: kex.h: In function ?kex_free_newkeys?: kex.h:116:18: note: destination object ?name? of size 8 116 | char *name; | ^~~~ /usr/include/bits/string_fortified.h:66:6: note: in a call to function ?__explicit_bzero_chk? declared with attribute ?access (write_only, 1, 2)? 66 | void __explicit_bzero_chk (void *__dest, size_t __len, size_t __destlen) | ^~~~~~~~~~~~~~~~~~~~ Sorry about the confusion before. I always have too many terminals open. Chris From sam at gentoo.org Wed Jun 7 06:29:53 2023 From: sam at gentoo.org (Sam James) Date: Tue, 06 Jun 2023 21:29:53 +0100 Subject: Possible overflow bug? In-Reply-To: <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> References: <20230606185939.14773.qmail@stuge.se> <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> Message-ID: <87pm68bag0.fsf@gentoo.org> Chris Rapier writes: > On 6/6/23 2:59 PM, Peter Stuge wrote: >> Chris Rapier wrote: >>> openssh 9.3p1 >> .. >>> In function 'explicit_bzero', >>> inlined from 'kex_free_newkeys' at kex.c:743:2: >> kex.c in tag V_9_3_P1 doesn't call explicit_bzero() on line 743, >>> '__explicit_bzero_chk' writing 48 bytes into a region of size 8 >> .. >>> kex.h: In function 'kex_free_newkeys': >>> kex.h:116:18: note: destination object 'name' of size 8 >>> 116 | char *name; >> ... in fact kex_free_newkeys() in tag V_9_3_P1 doesn't ever call >> explicit_bzero() with an object called 'name'. >> >>> Not sure if this is a real problem or not but I thought I'd pass it >>> over just in case. >> Could you check if you have any patch applied on top of V_9_3_P1? > > > I'm using commit cb30fbdbee869f1ce11f06aa97e1cb8717a0b645 (HEAD, tag: > V_9_3_P1, openssh-master/V_9_3) and git diff isn't reporting anything > applied. > > And I just realized I grabbed that from the wrong window (which does > have patches applied). Same thing exists in the canonical code. Here > is the accurate one: > > > In file included from /usr/include/string.h:535, > from kex.c:34: > In function ?explicit_bzero?, > inlined from ?kex_free_newkeys? at kex.c:742:2: > /usr/include/bits/string_fortified.h:72:3: warning: > ?__explicit_bzero_chk? writing 48 bytes into a region of size 8 > overflows the destination [-Wstringop-overflow=] > 72 | __explicit_bzero_chk (__dest, __len, __glibc_objsize0 (__dest)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from kex.c:53: > kex.h: In function ?kex_free_newkeys?: > kex.h:116:18: note: destination object ?name? of size 8 > 116 | char *name; > | ^~~~ > /usr/include/bits/string_fortified.h:66:6: note: in a call to function > ?__explicit_bzero_chk? declared with attribute ?access (write_only, 1, > 2)? > 66 | void __explicit_bzero_chk (void *__dest, size_t __len, size_t > __destlen) > | ^~~~~~~~~~~~~~~~~~~~ > > Sorry about the confusion before. I always have too many terminals open. Not a comment on this particular bug, but as an FYI, sanitizers are known to sometimes cause false-positive *compile*-time warnings (not runtime failures, which are pretty much always legitimate). > > Chris > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 377 bytes Desc: not available URL: From naddy at mips.inka.de Wed Jun 7 06:46:26 2023 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue, 6 Jun 2023 22:46:26 +0200 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: References: Message-ID: Darren Tucker: > > I am using sshd on FreeBSD 13.2 and it only logs the first line. > > FreeBSD 13's OpenSSH is based on 8.0p1, which is a bit over four years > old at this point. It has been upgraded over the course of the 13.x branch: 13.2 has OpenSSH 9.2p1. -- Christian "naddy" Weisgerber naddy at mips.inka.de From t.glaser at tarent.de Wed Jun 7 07:12:59 2023 From: t.glaser at tarent.de (Thorsten Glaser) Date: Tue, 6 Jun 2023 23:12:59 +0200 (CEST) Subject: Possible overflow bug? In-Reply-To: <87pm68bag0.fsf@gentoo.org> References: <20230606185939.14773.qmail@stuge.se> <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> <87pm68bag0.fsf@gentoo.org> Message-ID: On Tue, 6 Jun 2023, Sam James wrote: >Not a comment on this particular bug, but as an FYI, sanitizers are >known to sometimes cause false-positive *compile*-time warnings Huh, they do? What happens here is that it thinks the pointer to newkeys->enc is a pointer to the first element (name) inside newkeys->enc, which is incorrect but probably correct elsewhere and I don?t know whether it can even distinguish them where it sits. But looking at this? newkeys->enc is an inlined struct sshenc inside struct newkeys, so why not just bzero the entire newkeys at once near the end instead of doing it piecemeal as if it were a pointer? bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! **************************************************** From sam at gentoo.org Wed Jun 7 07:19:13 2023 From: sam at gentoo.org (Sam James) Date: Tue, 06 Jun 2023 22:19:13 +0100 Subject: Possible overflow bug? In-Reply-To: References: <20230606185939.14773.qmail@stuge.se> <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> <87pm68bag0.fsf@gentoo.org> Message-ID: <875y80b82e.fsf@gentoo.org> Thorsten Glaser writes: > On Tue, 6 Jun 2023, Sam James wrote: > >>Not a comment on this particular bug, but as an FYI, sanitizers are >>known to sometimes cause false-positive *compile*-time warnings > > Huh, they do? Yes: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107298#c4. This is not a comment on their runtime effectiveness (and I'm not commenting on the code in question here, just that it's very common to get spurious compile-time warnings you don't get otherwise when building with sanitizers). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 377 bytes Desc: not available URL: From peter at stuge.se Wed Jun 7 08:06:56 2023 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Jun 2023 22:06:56 +0000 Subject: Possible overflow bug? In-Reply-To: References: <20230606185939.14773.qmail@stuge.se> <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> <87pm68bag0.fsf@gentoo.org> Message-ID: <20230606220656.23578.qmail@stuge.se> Thorsten Glaser wrote: > What happens here is that it thinks the pointer to newkeys->enc > is a pointer to the first element (name) inside newkeys->enc, > which is incorrect Yes, so no overflow bug. Too bad it confuses the struct with the first member inside. > But looking at this? newkeys->enc is an inlined struct sshenc > inside struct newkeys, so why not just bzero the entire newkeys > at once near the end instead of doing it piecemeal as if it were > a pointer? Maybe to leak as little information as possible in case of error along the way. //Peter From rapier at psc.edu Wed Jun 7 08:09:14 2023 From: rapier at psc.edu (Chris Rapier) Date: Tue, 6 Jun 2023 18:09:14 -0400 Subject: Possible overflow bug? In-Reply-To: <87pm68bag0.fsf@gentoo.org> References: <20230606185939.14773.qmail@stuge.se> <442b0fd5-b19e-cb1b-b856-0c21e1251f18@psc.edu> <87pm68bag0.fsf@gentoo.org> Message-ID: On Tue, Jun 6, 2023, 16:31 Sam James wrote: > > Chris Rapier writes: > > > On 6/6/23 2:59 PM, Peter Stuge wrote: > >> Chris Rapier wrote: > >>> openssh 9.3p1 > >> .. > >>> In function 'explicit_bzero', > >>> inlined from 'kex_free_newkeys' at kex.c:743:2: > >> kex.c in tag V_9_3_P1 doesn't call explicit_bzero() on line 743, > >>> '__explicit_bzero_chk' writing 48 bytes into a region of size 8 > >> .. > >>> kex.h: In function 'kex_free_newkeys': > >>> kex.h:116:18: note: destination object 'name' of size 8 > >>> 116 | char *name; > >> ... in fact kex_free_newkeys() in tag V_9_3_P1 doesn't ever call > >> explicit_bzero() with an object called 'name'. > >> > >>> Not sure if this is a real problem or not but I thought I'd pass it > >>> over just in case. > >> Could you check if you have any patch applied on top of V_9_3_P1? > > > > > > I'm using commit cb30fbdbee869f1ce11f06aa97e1cb8717a0b645 (HEAD, tag: > > V_9_3_P1, openssh-master/V_9_3) and git diff isn't reporting anything > > applied. > > > > And I just realized I grabbed that from the wrong window (which does > > have patches applied). Same thing exists in the canonical code. Here > > is the accurate one: > > > > > > In file included from /usr/include/string.h:535, > > from kex.c:34: > > In function ?explicit_bzero?, > > inlined from ?kex_free_newkeys? at kex.c:742:2: > > /usr/include/bits/string_fortified.h:72:3: warning: > > ?__explicit_bzero_chk? writing 48 bytes into a region of size 8 > > overflows the destination [-Wstringop-overflow=] > > 72 | __explicit_bzero_chk (__dest, __len, __glibc_objsize0 > (__dest)); > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > In file included from kex.c:53: > > kex.h: In function ?kex_free_newkeys?: > > kex.h:116:18: note: destination object ?name? of size 8 > > 116 | char *name; > > | ^~~~ > > /usr/include/bits/string_fortified.h:66:6: note: in a call to function > > ?__explicit_bzero_chk? declared with attribute ?access (write_only, 1, > > 2)? > > 66 | void __explicit_bzero_chk (void *__dest, size_t __len, size_t > > __destlen) > > | ^~~~~~~~~~~~~~~~~~~~ > > > > Sorry about the confusion before. I always have too many terminals open. > > Not a comment on this particular bug, but as an FYI, sanitizers are > known to sometimes cause false-positive *compile*-time warnings (not > runtime > failures, which are pretty much always legitimate). > > > This doesn't actually surprise me. I'd have expected to see actual > problems during runtime if it really was zeroing out 40 extra bytes each > time it called this function. On the other hand, I wanted to run it by > people in case there really is a problem. > > From yuri at rawbw.com Wed Jun 7 13:59:34 2023 From: yuri at rawbw.com (Yuri) Date: Tue, 6 Jun 2023 20:59:34 -0700 Subject: [feature suggestion] sshd should log the listening port number while logging errors/warnings In-Reply-To: References: Message-ID: <94662bfc-d53d-27bc-5bfc-35186b06458d@tsoft.com> On 6/6/23 13:46, Christian Weisgerber wrote: > It has been upgraded over the course of the 13.x branch: 13.2 has > OpenSSH 9.2p1. The current version of OpenSSH in the FreeBSD 13.x branch is 9.3p1 But the log doesn't contain the listening port information, For example, /var/log/messages has: > Jun? 6 19:05:02 xx sshd[6528]: error: Fssh_kex_exchange_identification: read: Connection reset by peer The same incident also has these lines in /var/log/auth.log: > Jun? 6 19:05:02 xx sshd[6528]: error: Fssh_kex_exchange_identification: read: Connection reset by peer > Jun? 6 19:05:02 xx sshd[6528]: Connection reset by 69.164.217.245 port 47272 But the listening port information isn't printed. What is wrong? Yuri From rapier at psc.edu Sat Jun 10 04:49:40 2023 From: rapier at psc.edu (Chris Rapier) Date: Fri, 9 Jun 2023 14:49:40 -0400 Subject: Question About Dynamic Remote Forwarding Message-ID: <1cff4b7a-d103-1f92-627f-57559bcf5b72@psc.edu> Hi all, When a client requests dynamic remote forwarding with -R it delays forking into the background. In ssh.c we see if (options.fork_after_authentication) { if (options.exit_on_forward_failure && options.num_remote_forwards > 0) { debug("deferring postauth fork until remote forward " "confirmation received"); } else fork_postauth(ssh); } This seems to depend on forwarding_success() for it to then call fork_postauth. If I'm reading this correctly the client sends out a number of forward requests which is tracked via forward_confirms_pending in ssh.c. Is there any equivalent on the server side to track the number of received requests? I ask because I'm trying, for various reasons, to trigger a rekey on the server side *after* the client forks in a dynamic remote forward scenario. I know that the server can't actually know for certain if the client has or hasn't forked but if I could track the number of confirmations the server has sent I can use that as a reasonable proxy. I could use an ssh control message to do this but I'd rather not if I don't have to. Thanks, Chris From djm at mindrot.org Sat Jun 10 10:05:09 2023 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Jun 2023 10:05:09 +1000 (AEST) Subject: Question About Dynamic Remote Forwarding In-Reply-To: <1cff4b7a-d103-1f92-627f-57559bcf5b72@psc.edu> References: <1cff4b7a-d103-1f92-627f-57559bcf5b72@psc.edu> Message-ID: <9c91a89a-8475-c82d-31b0-3bc766e0864b@mindrot.org> On Fri, 9 Jun 2023, Chris Rapier wrote: > Hi all, > > When a client requests dynamic remote forwarding with -R it delays forking > into the background. In ssh.c we see > > if (options.fork_after_authentication) { > if (options.exit_on_forward_failure && > options.num_remote_forwards > 0) { > debug("deferring postauth fork until remote forward " > "confirmation received"); > } else > fork_postauth(ssh); > } > > > This seems to depend on forwarding_success() for it to then call > fork_postauth. > > If I'm reading this correctly the client sends out a number of forward > requests which is tracked via forward_confirms_pending in ssh.c. > > Is there any equivalent on the server side to track the number of received > requests? > > I ask because I'm trying, for various reasons, to trigger a rekey on the > server side *after* the client forks in a dynamic remote forward scenario. I > know that the server can't actually know for certain if the client has or > hasn't forked but if I could track the number of confirmations the server has > sent I can use that as a reasonable proxy. I could use an ssh control message > to do this but I'd rather not if I don't have to. I don't think what you want is possible without a protocol extension. The server has no notion of the client's fork-after-auth behaviour and has no way of knowing if/when another forwarding request will come. Why not have the client ask for the rekey? It's in a better position to know... -d From rapier at psc.edu Sat Jun 10 13:40:38 2023 From: rapier at psc.edu (Chris Rapier) Date: Fri, 9 Jun 2023 23:40:38 -0400 Subject: Question About Dynamic Remote Forwarding In-Reply-To: <9c91a89a-8475-c82d-31b0-3bc766e0864b@mindrot.org> References: <1cff4b7a-d103-1f92-627f-57559bcf5b72@psc.edu> <9c91a89a-8475-c82d-31b0-3bc766e0864b@mindrot.org> Message-ID: Mostly it's about how we handle loading the parallelized ciphers. We can't really effectively start them in preauth as that will result in the threads being lost by main. So after auth happens we rekey and load the parallel ciphers we developed (aes-ctr and now CC20). Either side can trigger this because we don't wasn't to be using the serial cipher on both sides if we don't have to (especially on the receiver sauce as that send to be more resource intensive). This means that OpenSSH can interact with a parallel cipher without any issues. However, this breaks down with dynamic remote forwarding. We can't start the parallel cipher until after the fork. In terms of the dynamic remote forward the server will end up requesting a rekey before the client has forked. Which means the client rekeys into the parallel cipher before the fork and everything goes pear shaped. We can make it so that the server won't issue a rekey but when an openssh client interacts with an hpnssh server our server won't load the parallel cipher until we get a rekey based on the block count. Which isn't awesome in terms of performance. So it's mostly about getting an hpnssh server to recognize when an openssh client is post fork in order to maximize performance. We think this is worth working out as, for example, the parallel CC20 cipher is roughly 50% faster. My thinking is that the client is waiting on a signal from the server to execute the delayed post_authfork() command. If can time it so that the server doesn't rekey until it sends that signal we can handle our situation correctly while retaining compatibility. Dunno, just trying to think this though. If I can figure out something on the server side that's cool. Otherwise I think I need to prevent the server from rekeying into the parallel cipher in a tcpip-forward situation. That's suboptimal but we can make that work On Fri, Jun 9, 2023, 20:05 Damien Miller wrote: > On Fri, 9 Jun 2023, Chris Rapier wrote: > > > Hi all, > > > > When a client requests dynamic remote forwarding with -R it delays > forking > > into the background. In ssh.c we see > > > > if (options.fork_after_authentication) { > > if (options.exit_on_forward_failure && > > options.num_remote_forwards > 0) { > > debug("deferring postauth fork until remote forward " > > "confirmation received"); > > } else > > fork_postauth(ssh); > > } > > > > > > This seems to depend on forwarding_success() for it to then call > > fork_postauth. > > > > If I'm reading this correctly the client sends out a number of forward > > requests which is tracked via forward_confirms_pending in ssh.c. > > > > Is there any equivalent on the server side to track the number of > received > > requests? > > > > I ask because I'm trying, for various reasons, to trigger a rekey on the > > server side *after* the client forks in a dynamic remote forward > scenario. I > > know that the server can't actually know for certain if the client has or > > hasn't forked but if I could track the number of confirmations the > server has > > sent I can use that as a reasonable proxy. I could use an ssh control > message > > to do this but I'd rather not if I don't have to. > > I don't think what you want is possible without a protocol extension. The > server has no notion of the client's fork-after-auth behaviour and has no > way of knowing if/when another forwarding request will come. > > Why not have the client ask for the rekey? It's in a better position to > know... > > -d > From carsten.andrich at tu-ilmenau.de Sat Jun 10 19:19:01 2023 From: carsten.andrich at tu-ilmenau.de (Carsten Andrich) Date: Sat, 10 Jun 2023 11:19:01 +0200 Subject: Minimize sshd log clutter/spam from unauthenticated connections In-Reply-To: <1ED9B05F-170B-4335-97C2-03EDB717DAF8@marek.priv.at> References: <486b174e-80aa-61e7-ed1e-c35fb6349acd@tu-ilmenau.de> <177o0nrr-1s8p-6o31-184n-s84p5824428p@ynat.uz> <8d001164-09ae-05a8-a9e9-bb66e3e4a6ac@tu-ilmenau.de> <1ED9B05F-170B-4335-97C2-03EDB717DAF8@marek.priv.at> Message-ID: On 19.03.23 07:03, Philipp Marek wrote: > I quite like having a process listen on port 53 and wait for a dns > query containing a totp string to grant (temporary) access; that's a > 2fa, and doing a "host 123456. my-ip" is easily automated in a shell > script as well... I have to admit, I *really* like the TOTP idea. For the time being, I've deployed a quasi-knocking KISS solution that sends an unencrypted secret via a single UDP packet. Server side is realized entirely with nftables: table inet filter { # set of IP addresses that have authenticated via knocking set sshauth { type ipv4_addr size 255 flags timeout, dynamic } chain input { type filter hook input priority filter; policy drop; # SSH knocking with single UDP packet containing unencrypted secret udp dport 12345 @ih,0,32 0xdeadbeef add @sshauth { ip saddr timeout 4h } counter # alternatively TCP fast open can be used to knock with firewalls that only permit TCP port 22 tcp dport 22 tcp flags syn @ih,0,32 0xdeadbeef add @sshauth { ip saddr timeout 4h } counter reject with tcp reset # accept new SSH connections from IP addresses that have knocked ip saddr @sshauth tcp dport 22 ct state new counter accept # accept established connections and reject the rest ct state { established, related } accept meta pkttype unicast ip protocol tcp counter reject with tcp reset } } For SSH hosts only accessed by a select few of technically experienced users that approach has worked like a charm. Best regards, Carsten From Jochen.Bern at binect.de Sun Jun 11 18:30:15 2023 From: Jochen.Bern at binect.de (Jochen Bern) Date: Sun, 11 Jun 2023 10:30:15 +0200 Subject: Minimize sshd log clutter/spam from unauthenticated connections Message-ID: <7cef5d7e-3458-5fd8-cff6-a92c5b7e9571@binect.de> On 10.06.23 11:19, Carsten Andrich wrote: > For the time being, I've deployed a quasi-knocking KISS solution that > sends an unencrypted secret via a single UDP packet. Server side is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > realized entirely with nftables ... frankly, for that reason, I like fwknop (in my case, straight from OS repos) better ... I'd still have to see fwknopd exit unexpectedly, which is where a host-firewall-only mechanism on the server side would have an advantage ... http://www.cipherdyne.org/fwknop/ > ~# cd /etc/fwknop > fwknop# diff access.conf.orig access.conf | sed -e '/> .*KEY/s/\t.*/\t.../' > 204,206c204,211 > < SOURCE ANY > < KEY_BASE64 __CHANGEME__ > < HMAC_KEY_BASE64 __CHANGEME__ > --- >> SOURCE ANY >> KEY_BASE64 ... >> HMAC_KEY_BASE64 ... >> REQUIRE_SOURCE_ADDRESS Y >> # fwknopd fiddles with iptables, we need to have nftables modified. >> CMD_CYCLE_OPEN /usr/local/sbin/fwknop2nftables $IP $PORT >> CMD_CYCLE_CLOSE NONE >> CMD_CYCLE_TIMER 30s > fwknop# diff fwknopd.conf.orig fwknopd.conf > 40a41 >> PCAP_INTF enp0s25 > fwknop# cat /usr/local/sbin/fwknop2nftables > #!/bin/sh > > # Syntax: $0 SRC_IP PORT > > NFT="/usr/sbin/nft" > SET="fwkn" > # Note that we are ignoring everything from the accepted fwknop > # requests except the src IP and tgt port to be allowed ... > > PREP=`$NFT list chain inet firewalld filter_IN_public_allow | grep -c "@${SET}_$2"` > > if [ $PREP -eq 0 ]; then > $NFT add set inet firewalld "${SET}_$2" '{ type ipv4_addr ; timeout 30s ; size 32 ; }' > $NFT add rule inet firewalld filter_IN_public_allow ip saddr "@${SET}_$2" tcp dport "$2" accept > fi > > $NFT add element inet firewalld "${SET}_$2" { $1 } > ~$ tail -8 .fwknoprc | sed -e '/^[SKH]/s/\t.*/\t.../' -e '/^\[/s/[a-z][a-z]*/.../g' > [...] > ACCESS tcp/22 > SPA_SERVER ... > #ALLOW_IP TBD > KEY_BASE64 ... > HMAC_KEY_BASE64 ... > USE_HMAC Y > RESOLVE_IP_HTTPS N Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: From ronan at rjp.ie Sat Jun 17 12:19:54 2023 From: ronan at rjp.ie (Ronan Pigott) Date: Fri, 16 Jun 2023 19:19:54 -0700 Subject: [PATCH] ssh-agent: add systemd socket-based activation Message-ID: <20230617022444.58531-1-ronan@rjp.ie> This adds support for systemd socket-based activation in the ssh-agent. When using socket activation, the -a flag value must match the socket path provided by systemd, as a sanity check. Support for this feature is enabled by the --with-systemd configure flag. --- Something tells me upstream would not be interested in this patch, but as it may be useful on linux, I'm submitting it here. Makefile.in | 3 ++- configure.ac | 25 ++++++++++++++++++++++++ ssh-agent.c | 54 +++++++++++++++++++++++++++++++++++++++++++--------- 3 files changed, 72 insertions(+), 10 deletions(-) diff --git a/Makefile.in b/Makefile.in index 70287f51fb81..9bace646fecf 100644 --- a/Makefile.in +++ b/Makefile.in @@ -53,6 +53,7 @@ CHANNELLIBS=@CHANNELLIBS@ K5LIBS=@K5LIBS@ GSSLIBS=@GSSLIBS@ SSHDLIBS=@SSHDLIBS@ +AGENTLIBS=@AGENTLIBS@ LIBEDIT=@LIBEDIT@ LIBFIDO2=@LIBFIDO2@ AR=@AR@ @@ -216,7 +217,7 @@ ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHADD_OBJS) $(LD) -o $@ $(SSHADD_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(CHANNELLIBS) ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHAGENT_OBJS) - $(LD) -o $@ $(SSHAGENT_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(CHANNELLIBS) + $(LD) -o $@ $(SSHAGENT_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(AGENTLIBS) $(LIBS) $(CHANNELLIBS) ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHKEYGEN_OBJS) $(LD) -o $@ $(SSHKEYGEN_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(CHANNELLIBS) diff --git a/configure.ac b/configure.ac index 07893e870659..d12b6e9c0588 100644 --- a/configure.ac +++ b/configure.ac @@ -147,6 +147,16 @@ else AC_MSG_RESULT([no]) fi +systemd=no +AC_ARG_WITH([systemd], + [ --with-systemd Enable use of systemd socket-based activation ], + [ if test "x$withval" = "xyes" ; then + systemd=yes + AC_DEFINE([WITH_SYSTEMD], [1], [enable systemd socket-based activation]) + fi + ] +) + use_stack_protector=1 use_toolchain_hardening=1 AC_ARG_WITH([stackprotect], @@ -3376,6 +3386,18 @@ AC_CHECK_LIB([crypt], [crypt], [ AC_CHECK_FUNCS([crypt]) LIBS="$saved_LIBS" +if test "x$systemd" == "xyes" ; then + # Check for sd_listen_fds in libsystemd for socket activation + saved_LIBS="$LIBS" + AC_CHECK_LIB([systemd], [sd_listen_fds], [ + LIBS="-lsystemd $LIBS" + AGENTLIBS="-lsystemd $AGENTLIBS" + ]) + AC_CHECK_FUNCS([sd_listen_fds]) + LIBS="$saved_LIBS" + AC_SUBST([AGENTLIBS]) +fi + # Check for PAM libs PAM_MSG="no" AC_ARG_WITH([pam], @@ -5632,6 +5654,9 @@ fi if test ! -z "${SSHDLIBS}"; then echo " +for sshd: ${SSHDLIBS}" fi +if test ! -z "${AGENTLIBS}"; then +echo " +for ssh-agent: ${AGENTLIBS}" +fi echo "" diff --git a/ssh-agent.c b/ssh-agent.c index c72518ba3537..eb3a8b022590 100644 --- a/ssh-agent.c +++ b/ssh-agent.c @@ -69,6 +69,9 @@ #include #include #include +#ifdef WITH_SYSTEMD +# include +#endif #include #ifdef HAVE_UTIL_H # include @@ -166,6 +169,11 @@ pid_t cleanup_pid = 0; char socket_name[PATH_MAX]; char socket_dir[PATH_MAX]; +#ifdef WITH_SYSTEMD +/* tracks whether the active AUTH_SOCKET was passed to us by a third party */ +int external_socket = 0; +#endif + /* Pattern-list of allowed PKCS#11/Security key paths */ static char *allowed_providers; @@ -1946,6 +1954,10 @@ cleanup_socket(void) { if (cleanup_pid != 0 && getpid() != cleanup_pid) return; +#ifdef WITH_SYSTEMD + if (external_socket) + return; +#endif debug_f("cleanup"); if (socket_name[0]) unlink(socket_name); @@ -2000,7 +2012,7 @@ int main(int ac, char **av) { int c_flag = 0, d_flag = 0, D_flag = 0, k_flag = 0, s_flag = 0; - int sock, ch, result, saved_errno; + int sock = 0, ch, result, saved_errno; char *shell, *format, *pidstr, *agentsocket = NULL; #ifdef HAVE_SETRLIMIT struct rlimit rlim; @@ -2015,6 +2027,9 @@ main(int ac, char **av) struct pollfd *pfd = NULL; size_t npfd = 0; u_int maxfds; +#ifdef WITH_SYSTEMD + int nfds = 0; +#endif /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -2142,6 +2157,25 @@ main(int ac, char **av) parent_pid = getpid(); +#ifdef WITH_SYSTEMD + nfds = sd_listen_fds(1); + if (nfds > 0) { + sock = SD_LISTEN_FDS_START; + if (agentsocket == NULL) { + fprintf(stderr, "%s not set, cannot use socket-activation", + SSH_AUTHSOCKET_ENV_NAME); + exit(1); + } else if (sd_is_socket_unix(sock, SOCK_STREAM, 1, agentsocket, 0) <= 0) { + fprintf(stderr, "Unexpected auth sock received from systemd. Expected %s\n", agentsocket); + exit(1); + } else if (nfds > 1) { + fprintf(stderr, "too many fds received from systemd (%d)\n", nfds); + exit(1); + } + strlcpy(socket_name, agentsocket, sizeof socket_name); + external_socket = 1; + } +#endif if (agentsocket == NULL) { /* Create private directory for agent socket */ mktemp_proto(socket_dir, sizeof(socket_dir)); @@ -2150,7 +2184,7 @@ main(int ac, char **av) exit(1); } snprintf(socket_name, sizeof socket_name, "%s/agent.%ld", socket_dir, - (long)parent_pid); + (long)parent_pid); } else { /* Try to use specified agent socket */ socket_dir[0] = '\0'; @@ -2161,14 +2195,16 @@ main(int ac, char **av) * Create socket early so it will exist before command gets run from * the parent. */ - prev_mask = umask(0177); - sock = unix_listener(socket_name, SSH_LISTEN_BACKLOG, 0); - if (sock < 0) { - /* XXX - unix_listener() calls error() not perror() */ - *socket_name = '\0'; /* Don't unlink any existing file */ - cleanup_exit(1); + if (sock == 0) { + prev_mask = umask(0177); + sock = unix_listener(socket_name, SSH_LISTEN_BACKLOG, 0); + if (sock < 0) { + /* XXX - unix_listener() calls error() not perror() */ + *socket_name = '\0'; /* Don't unlink any existing file */ + cleanup_exit(1); + } + umask(prev_mask); } - umask(prev_mask); /* * Fork, and have the parent execute the command, if any, or present -- 2.41.0 From djm at mindrot.org Tue Jun 20 10:20:01 2023 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Jun 2023 10:20:01 +1000 (AEST) Subject: [PATCH] ssh-agent: add systemd socket-based activation In-Reply-To: <20230617022444.58531-1-ronan@rjp.ie> References: <20230617022444.58531-1-ronan@rjp.ie> Message-ID: <2b7fc1dc-641e-abb5-a53-e65b5ea780d6@mindrot.org> On Fri, 16 Jun 2023, Ronan Pigott wrote: > This adds support for systemd socket-based activation in the ssh-agent. > When using socket activation, the -a flag value must match the socket > path provided by systemd, as a sanity check. Support for this feature is > enabled by the --with-systemd configure flag. > > --- > Something tells me upstream would not be interested in this patch, but > as it may be useful on linux, I'm submitting it here. yeah - unfortunately libsystemd is under the LGPL and we've tried hard to keep our license free of additional obligations. -d From ronan at rjp.ie Tue Jun 20 10:42:42 2023 From: ronan at rjp.ie (Ronan Pigott) Date: Tue, 20 Jun 2023 00:42:42 +0000 Subject: [PATCH] ssh-agent: add systemd socket-based activation In-Reply-To: <2b7fc1dc-641e-abb5-a53-e65b5ea780d6@mindrot.org> References: <2b7fc1dc-641e-abb5-a53-e65b5ea780d6@mindrot.org> <20230617022444.58531-1-ronan@rjp.ie> Message-ID: June 19, 2023 5:20 PM, "Damien Miller" wrote: > yeah - unfortunately libsystemd is under the LGPL and we've tried hard > to keep our license free of additional obligations. > > -d Ah, I see. No worries then. It should be possible without libsystemd if somebody really wants this in the future, just need to implement the interface as described by sd_listen_fds(3). Cheers, Ronan From demiobenour at gmail.com Wed Jun 21 02:11:25 2023 From: demiobenour at gmail.com (Demi Marie Obenour) Date: Tue, 20 Jun 2023 12:11:25 -0400 Subject: [PATCH] ssh-agent: add systemd socket-based activation In-Reply-To: <2b7fc1dc-641e-abb5-a53-e65b5ea780d6@mindrot.org> References: <20230617022444.58531-1-ronan@rjp.ie> <2b7fc1dc-641e-abb5-a53-e65b5ea780d6@mindrot.org> Message-ID: <62640a25-766f-2665-bf8c-a37e231dab2e@gmail.com> On 6/19/23 20:20, Damien Miller wrote: > > On Fri, 16 Jun 2023, Ronan Pigott wrote: > >> This adds support for systemd socket-based activation in the ssh-agent. >> When using socket activation, the -a flag value must match the socket >> path provided by systemd, as a sanity check. Support for this feature is >> enabled by the --with-systemd configure flag. >> >> --- >> Something tells me upstream would not be interested in this patch, but >> as it may be useful on linux, I'm submitting it here. > > yeah - unfortunately libsystemd is under the LGPL and we've tried hard > to keep our license free of additional obligations. Would a version that reimplemented sd_listen_fds(3) be okay? sd_listen_fds(3) is just a convenience function. The actual protocol is independent of both libsystemd and of systemd itself. -- Sincerely, Demi Marie Obenour (she/her/hers) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB288B55FFF9C22C1.asc Type: application/pgp-keys Size: 4885 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Wed Jun 21 03:55:05 2023 From: peter at stuge.se (Peter Stuge) Date: Tue, 20 Jun 2023 17:55:05 +0000 Subject: [PATCH] ssh-agent: add systemd socket-based activation In-Reply-To: <62640a25-766f-2665-bf8c-a37e231dab2e@gmail.com> References: <20230617022444.58531-1-ronan@rjp.ie> <2b7fc1dc-641e-abb5-a53-e65b5ea780d6@mindrot.org> <62640a25-766f-2665-bf8c-a37e231dab2e@gmail.com> Message-ID: <20230620175505.16799.qmail@stuge.se> Demi Marie Obenour wrote: > >> Something tells me upstream would not be interested in this patch, > >> but as it may be useful on linux, I'm submitting it here. Noone should be interested in linking libsystemd into sshd. Of course this doesn't stop distributions from doing so. > Would a version that reimplemented sd_listen_fds(3) be okay? I sent attached sd_notify() reimplementation (Type=notify sshd.service) five years ago, that didn't go anywhere. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: sd_notify.c Type: text/x-c Size: 2545 bytes Desc: not available URL: From dbelyavs at redhat.com Wed Jun 28 21:51:07 2023 From: dbelyavs at redhat.com (Dmitry Belyavskiy) Date: Wed, 28 Jun 2023 13:51:07 +0200 Subject: Defend against user enumeration timing attacks - overkill In-Reply-To: References: Message-ID: Dear colleagues, May I ask you to explain whether I am wrong in my conclusions? On Wed, Apr 12, 2023 at 11:55?AM Dmitry Belyavskiy wrote: > > Dear colleagues, > > I have a question about this commit: > > https://github.com/openssh/openssh-portable/commit/e9d910b0289c820852f7afa67f584cef1c05fe95#diff-a25e40214ca9c9f78abce22f23bf2abdb2a24384c6610d60bbb314aed534eb48R216 > > The function ensure_minimum_time_since effectively doubles the time > spent in the input_userauth_request (mostly presumably in PAM). So if > PAM processing is really slow, it will cause huge delays - but if it > is so slow, it's more difficult to perform the enumeration attack. > > So doesn't it make sense to provide an upper limit here and if really > spent time is more than this upper limit, to avoid extra sleep? Will > it be still necessary to protect from the attack? Vice versa, when the > auth failure happens fast enough, the doubling will not significantly > slow down the enumerations... > > Any comments will be highly appreciated! > > -- > Dmitry Belyavskiy -- Dmitry Belyavskiy From peter at stuge.se Wed Jun 28 22:01:00 2023 From: peter at stuge.se (Peter Stuge) Date: Wed, 28 Jun 2023 12:01:00 +0000 Subject: Defend against user enumeration timing attacks - overkill In-Reply-To: References: Message-ID: <20230628120100.15000.qmail@stuge.se> Dmitry Belyavskiy wrote: > May I ask you to explain whether I am wrong in my conclusions? I guess it's not clear what problem you are trying to solve. //Peter From dbelyavs at redhat.com Wed Jun 28 22:11:53 2023 From: dbelyavs at redhat.com (Dmitry Belyavskiy) Date: Wed, 28 Jun 2023 14:11:53 +0200 Subject: Defend against user enumeration timing attacks - overkill In-Reply-To: <20230628120100.15000.qmail@stuge.se> References: <20230628120100.15000.qmail@stuge.se> Message-ID: Dear Peter, I'm trying to balance the original problem statement (protection from users enumeration) and avoid doubling time here if the process has already taken a long time to provide faster auth method iteration. I believe that a better solution is to set some arbitrary (probably configurable) timeout and, in case when we spend more time than that value, avoid doubling it. On Wed, Jun 28, 2023 at 2:04?PM Peter Stuge wrote: > > Dmitry Belyavskiy wrote: > > May I ask you to explain whether I am wrong in my conclusions? > > I guess it's not clear what problem you are trying to solve. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Dmitry Belyavskiy From mm1072 at att.com Fri Jun 30 08:06:05 2023 From: mm1072 at att.com (MCMANUS, MICHAEL P) Date: Thu, 29 Jun 2023 22:06:05 +0000 Subject: Subsystem sftp invoked even though forced command created In-Reply-To: References: Message-ID: Folks, I'm curious if the documented behavior of portable OpenSSH (specifically Linux) may be at odds with the actual behavior I have seen in my experiments. Here is the background: I manage an application which collects data from a client script (Korn shell) which runs on Unix and Linux servers across the entire enterprise. The client communicates with a Linux server (currently running RHEL 7.9, reporting OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017) using a technique we call SSH Pass-Through and described in an article in ;login: (Secure Automated File Transfer, vol. 30, no. 4, August 2005, by Mark McCullough who was also the original author of the client). The technique is predicated on using a forced command, which we specify per key with the "command=" directive in the authorized_keys file. (The user ID we use performs several functions, so we cannot use ForceCommand in configuration.) In theory, any SSH connection made to the account with the corresponding private key should be forced to run the command provided, which accepts a fully-qualified domain name, environment, and stream of XML data on standard input and stores the data in a file with a name reflecting the FQDN and environment along with a date stamp. In all documentation I have to hand, the forced command is applied to all sessions including interactive, non-interactive, and *subsystem calls*. An authorized penetration tester brought to my attention that the private key embedded in the application can be extracted and used to launch a WinSCP session against the user ID which the client uses to send the data to the server. This session has the same access to all files on the server which the original user ID does, including the ability to traverse directories. This should not happen if the documentation is correct. To test the theory, I've slightly altered the forced command to output log data to indicate whether the forced command is even executed, and if so, what command line it was passed from the client (or WinSCP). The added code is as follows: LOGFILE=/tmp/name-of-file.log if [[ $SSH_ORIGINAL_COMMAND ]]; then print "Command: $SSH_ORIGINAL_COMMAND" >> $LOGFILE else print "No SSH_ORIGINAL COMMAND set" >> $LOGFILE fi I ran the client as is and received the following entry in the log: Command: 2>/dev/null I then set a flag in the client which removes the redirection to /dev/null and received: No SSH_ORIGINAL COMMAND set Finally, I connected via WinSCP as instructed by the pen tester and received no further data in the log. This indicates to me that the sftp subsystem does not even execute the forced command. The subsystem configuration in sshd_config is # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server I would almost expect this sort of behavior with the internal-sftp subsystem, but not with an external executable. Can anyone shed some light on this situation? Mike McManus Principal - Technology Security GTO Security Governance Team - Unix P: He/Him/His AT&T Services, Inc. 20205 North Creek Pkwy, Bothell, WA 98011 michael.mcmanus at att.com From Jochen.Bern at binect.de Fri Jun 30 18:11:44 2023 From: Jochen.Bern at binect.de (Jochen Bern) Date: Fri, 30 Jun 2023 10:11:44 +0200 Subject: Subsystem sftp invoked even though forced command created Message-ID: <6189ed8c-481b-273c-23ac-ffa7789dcf34@binect.de> On 30.06.23 00:06, MCMANUS, MICHAEL P wrote: > An authorized penetration tester brought to my attention that the private > key embedded in the application can be extracted and used to launch a > WinSCP session against the user ID which the client uses to send the data > to the server. As it happens, I have a system using dedicated keypairs and forced commands configured for them to extract survey data from CentOS 7 boxes, so let me try that ... > $ ssh -t -q autoquest at bongo -p 29056 -i .ssh/id_uptime_ed25519 > 1688110066 > 1684949224 > 685215 > 0 > $ sftp -P 29056 -i .ssh/id_uptime_ed25519 -q autoquest at bongo > Received message too long 825636920 Hm. Some specific quirk of WinSCP, maybe ... ? [grabs Win10 box] [updates WinSCP to 6.1.1] [adds keypair to both ends] ... gets me an error (-> screenshot) suggesting that it received the output from the forced command, and logs that the sshd has indeed run the forced command. Sorry, cannot confirm so far ... > I ran the client as is and received the following entry in the log: > Command: 2>/dev/null That's a weird, I'd even say nonfunctional, remote command, and makes me suspect that your ssh command has a syntax problem ... ? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: From djm at mindrot.org Fri Jun 30 18:56:00 2023 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Jun 2023 18:56:00 +1000 (AEST) Subject: Subsystem sftp invoked even though forced command created In-Reply-To: References: Message-ID: <15ff32a4-806a-ffea-338e-5c847cc9cde@mindrot.org> On Thu, 29 Jun 2023, MCMANUS, MICHAEL P wrote: > Folks, > > I'm curious if the documented behavior of portable OpenSSH (specifically Linux) may be at odds with the actual behavior I have seen in my experiments. Here is the background: [snip] It's very hard to figure out what is happening here without a debug log. You can get one by stopping the listening sshd and running it manually in debug mode, e.g. "/usr/sbin/sshd -ddd" Separate traces from expected vs problematic behaviour would be most helpful. -d From b.candler at pobox.com Fri Jun 30 19:20:45 2023 From: b.candler at pobox.com (Brian Candler) Date: Fri, 30 Jun 2023 10:20:45 +0100 Subject: Subsystem sftp invoked even though forced command created In-Reply-To: <15ff32a4-806a-ffea-338e-5c847cc9cde@mindrot.org> References: <15ff32a4-806a-ffea-338e-5c847cc9cde@mindrot.org> Message-ID: <6f432c4a-30c6-d980-d5c5-740b750196ea@pobox.com> On 30/06/2023 09:56, Damien Miller wrote: > It's very hard to figure out what is happening here without a debug log. > > You can get one by stopping the listening sshd and running it manually > in debug mode, e.g. "/usr/sbin/sshd -ddd" Or starting one in debug mode on a different port, e.g. "-p99 -ddd"