openssh unix dev - Jun 2023 - Question About Dynamic Remote Forwarding

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.

Thanks,

Chris

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