enhancement suggestion

[Greg Troxel]

When doing bup save with -r to an ssh remote, if ssh doesn't know the
key and wants to prompt, you get a failure with no real diagnostic
information. Running ssh manually and accepting the key fixes it.

It would be nice if instead of just failed, the stderr output from ssh
were printed first, and then it would be obvious.

[Johannes Berg]

Funny you should mention that. Rob and I were just discussing if/why/how
we may still need my commit b95fe84526ae ("bup: handle pre-mux messages
more cleanly"), and indeed that basically fixes this problem, but I
couldn't remember it, even had to test it.

Without it, bup eats (about) two lines of the stdout/err from ssh which
is probably enough to hide the error messages for you.

johannes

[Johannes Berg]

On Mon, 2024-02-19 at 09:10 +0100, Johannes Berg wrote:
> On Sun, 2024-02-18 at 10:27 -0500, Greg Troxel wrote:
> > When doing bup save with -r to an ssh remote, if ssh doesn't know the
> > key and wants to prompt, you get a failure with no real diagnostic
> > information. Running ssh manually and accepting the key fixes it.
> >
> > It would be nice if instead of just failed, the stderr output from ssh
> > were printed first, and then it would be obvious.
> >
>
> Funny you should mention that. Rob and I were just discussing if/why/how
> we may still need my commit b95fe84526ae ("bup: handle pre-mux messages
> more cleanly"), and indeed that basically fixes this problem, but I
> couldn't remember it, even had to test it.
>

Wait, no! I tested the wrong thing. It fixes the issue for 'bup on ...
save', but not for 'bup save -r ...', evidently. Sorry. I guess I'd have
to see where it takes away the lines in the -r case, because it's meant
to show them (and I have ssh configured to show the fingerprint picture
of all hosts, and it does show most of it here for me.)

johannes