Date: Thu, 2 May 2019 12:17:25 -0500 From: Alan Amesbury <amesbury@oitsec.umn.edu> To: Jim Thompson <jim@netgate.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: SIGPIPE from ssh-keyscan [patch] Message-ID: <0FE5F47E-99EF-4B64-B6AD-E2E6A1754634@oitsec.umn.edu> 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 May 1, 2019, at 20:07 , Jim Thompson <jim@netgate.com> wrote:
> 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.
>=20
> Arguably the right thing occurred here, with the exception that it =
killed your ssh-keyscan process.
>=20
> So perhaps instead of ignoring the signal, you should find out why the =
remote is exiting before the local can send its greeting.
I can't count on the remote side doing the write thing (yes, pun =
intended), as not all of the apparent "SSH servers" I attempt to obtain =
keys from are under my direct control. For me it would be better if =
ssh-keyscan were simply more robust in handling unexpected input.
> Otherwise, it=E2=80=99s a bit less heavy-handed to=20
>=20
> Int set =3D 1;
> setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));
>=20
> Where sd is the descriptor in question (16 in your example below).
>=20
> But other parts of ssh-keyscan seem to want to know that EPIPE has =
occurred, so neither is the correction solution here.
That's why I asked where this was a sane plan. Again, I'm out of my =
depth here, and my solution reflects that.
--=20
Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0FE5F47E-99EF-4B64-B6AD-E2E6A1754634>