Date: Wed, 1 May 2019 20:07:52 -0500 From: Jim Thompson <jim@netgate.com> To: Alan Amesbury <amesbury@oitsec.umn.edu> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: SIGPIPE from ssh-keyscan [patch] Message-ID: <144583E1-828D-4450-99B0-4FBF7FC35B26@netgate.com> In-Reply-To: <047FD22B-04FB-46EB-96D1-BF6E03080F9F@oitsec.umn.edu> References: <047FD22B-04FB-46EB-96D1-BF6E03080F9F@oitsec.umn.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
The remote closed the session for some reason before ssh-keyscan wrote =
the greening ("SSH-2.0-OpenSSH-keyscan\r\n=E2=80=9D), so you got SIGPIPE =
and ERRNO =3D 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=E2=80=99s a bit less heavy-handed to=20
Int set =3D 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.
Jim
> On May 1, 2019, at 5:05 PM, Alan Amesbury <amesbury@oitsec.umn.edu> =
wrote:
>=20
> 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:
>=20
>=20
> % 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
> %=20
>=20
>=20
> Output from truss confirms it's SIGPIPE:
>=20
> .
> .
> .
> 99597: write(7,"\0\0\^Dd\a\^T\M-Y\M-Jw(E\M-ty"...,1128) =3D 1128 =
(0x468)
> 99597: select(8,{ 7 },0x0,0x0,{ 5.000000 }) =3D 1 (0x1)
> 99597: read(7,"\0\0\^D\M-|\n\^T\M^X\M-N]\M-O\^C"...,8192) =3D 1280 =
(0x500)
> 99597: write(7,"\0\0\0,\^F\^^\0\0\0 0\M^S\M^J#"...,48) =3D 48 (0x30)
> 99597: select(8,{ 7 },0x0,0x0,{ 5.000000 }) =3D 1 (0x1)
> 99597: read(7,"\0\0\0\M-<\b\^_\0\0\0003\0\0\0\v"...,8192) =3D 208 =
(0xd0)
> 99597: write(1,"[REDACTED] ssh-ed255"...,104) =3D 104 (0x68)
> 99597: close(7) =3D 0 (0x0)
> 99597: write(16,"SSH-2.0-OpenSSH-keyscan\r\n",25) ERR#32 'Broken pipe'
> 99597: process killed, signal =3D 13
>=20
>=20
>=20
> The behavior exists in openssh-portable ("$FreeBSD: =
head/security/openssh-portable/Makefile 484842 2018-11-12 21:55:35Z =
bdrewery $") as well.
>=20
> The arguably naive patch I came up with is:
>=20
>=20
> --- /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 =3D 0, log_level =3D SYSLOG_LEVEL_INFO;
> int opt, fopt_count =3D 0, j;
> char *tname, *cp, *line =3D NULL;
>=20
>=20
>=20
>=20
> Straightforward and brutish: it ignores SIGPIPE within the main =
function in ssh-keyscan.c. This appears to work as expected, e.g.:
>=20
>=20
> % ./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
> .
> .
> .
>=20
>=20
>=20
> 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.
>=20
>=20
> --=20
> Alan
>=20
> _______________________________________________
> 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?144583E1-828D-4450-99B0-4FBF7FC35B26>