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 <djm@xxxxxxxxxxx> 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
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
