Date: Thu, 2 May 2019 11:19:36 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jim Thompson <jim@netgate.com> Cc: Alan Amesbury <amesbury@oitsec.umn.edu>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: SIGPIPE from ssh-keyscan [patch] Message-ID: <20190502081936.GC85201@kib.kiev.ua> In-Reply-To: <144583E1-828D-4450-99B0-4FBF7FC35B26@netgate.com> References: <047FD22B-04FB-46EB-96D1-BF6E03080F9F@oitsec.umn.edu> <144583E1-828D-4450-99B0-4FBF7FC35B26@netgate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 01, 2019 at 08:07:52PM -0500, Jim Thompson wrote:
> The remote closed the session for some reason before ssh-keyscan wrote the greening ("SSH-2.0-OpenSSH-keyscan\r\n”), so you got SIGPIPE and ERRNO = 32 back from the write call.
>
> Arguably the right thing occurred here, with the exception that it killed your ssh-keyscan process.
>
> So perhaps instead of ignoring the signal, you should find out why the remote is exiting before the local can send its greeting.
>
> Otherwise, it’s a bit less heavy-handed to
>
> Int set = 1;
> setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));
>
> Where sd is the descriptor in question (16 in your example below).
>
> But other parts of ssh-keyscan seem to want to know that EPIPE has occurred, so neither is the correction solution here.
>
EPIPE or signal ? SO_NOSIGPIPE only prevents kernel to generate SIGPIPE
when it returns EPIPE to userspace.
> Jim
>
>
> > On May 1, 2019, at 5:05 PM, Alan Amesbury <amesbury@oitsec.umn.edu> wrote:
> >
> > The stock ssh-keyscan bundled with 12.0-RELEASE exits with a SIGPIPE when it receives weird behavior from hosts it's attempting to communicate with. Symptoms look like:
> >
> >
> > % ssh-keyscan -f /tmp/randtargetlist > /dev/null
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > Broken pipe
> > %
> >
> >
> > Output from truss confirms it's SIGPIPE:
> >
> > .
> > .
> > .
> > 99597: write(7,"\0\0\^Dd\a\^T\M-Y\M-Jw(E\M-ty"...,1128) = 1128 (0x468)
> > 99597: select(8,{ 7 },0x0,0x0,{ 5.000000 }) = 1 (0x1)
> > 99597: read(7,"\0\0\^D\M-|\n\^T\M^X\M-N]\M-O\^C"...,8192) = 1280 (0x500)
> > 99597: write(7,"\0\0\0,\^F\^^\0\0\0 0\M^S\M^J#"...,48) = 48 (0x30)
> > 99597: select(8,{ 7 },0x0,0x0,{ 5.000000 }) = 1 (0x1)
> > 99597: read(7,"\0\0\0\M-<\b\^_\0\0\0003\0\0\0\v"...,8192) = 208 (0xd0)
> > 99597: write(1,"[REDACTED] ssh-ed255"...,104) = 104 (0x68)
> > 99597: close(7) = 0 (0x0)
> > 99597: write(16,"SSH-2.0-OpenSSH-keyscan\r\n",25) ERR#32 'Broken pipe'
> > 99597: process killed, signal = 13
> >
> >
> >
> > The behavior exists in openssh-portable ("$FreeBSD: head/security/openssh-portable/Makefile 484842 2018-11-12 21:55:35Z bdrewery $") as well.
> >
> > The arguably naive patch I came up with is:
> >
> >
> > --- /tmp/ssh-keyscan.c 2019-05-01 16:09:11.761587000 -0500
> > +++ ssh-keyscan.c 2019-05-01 16:08:50.425879000 -0500
> > @@ -644,6 +644,8 @@
> > int
> > main(int argc, char **argv)
> > {
> > + // ignore SIGPIPE
> > + signal(SIGPIPE, SIG_IGN);
> > int debug_flag = 0, log_level = SYSLOG_LEVEL_INFO;
> > int opt, fopt_count = 0, j;
> > char *tname, *cp, *line = NULL;
> >
> >
> >
> >
> > Straightforward and brutish: it ignores SIGPIPE within the main function in ssh-keyscan.c. This appears to work as expected, e.g.:
> >
> >
> > % ./ssh-keyscan_PATCHED -f /tmp/randtargetlist -T 15 > /dev/null
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > # [REDACTED]:22 SSH-2.0-OpenSSH_7.4
> > write ([REDACTED]): Broken pipe
> > write ([REDACTED]): Broken pipe
> > write ([REDACTED]): Broken pipe
> > # [REDACTED]:22 SSH-2.0-babeld-81e0741
> > .
> > .
> > .
> >
> >
> >
> > Is this something that's best done by adding it upstream, in the FreeBSD source (and ports), or ??? Also, is this sane? I don't see it as a huge deal because it's not a modification to the actual server or client code, just to the part that grabs host keys, but I freely admit that I'm outta my depth here.
> >
> >
> > --
> > Alan
> >
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190502081936.GC85201>