Delay in starting programs on FreeBSD via ssh after upgrade OpenBSD from 7.3 to 7.4

[Roger Marsh]

On Thu, 9 Nov 2023 08:21:22 +1100 (AEDT)
Damien Miller <djm at mindrot.org> wrote:

> On Wed, 8 Nov 2023, Roger Marsh wrote:
> 
> > Damien,
> > 
> > Sorry about distributed context.
> >
> > Those discussions told me about the new ObscureKeystrokeTiming
> > argument to the ssh command. One reply suggested I try that because it
> > is easy to test.
> >
> > Most of my xterm ssh command combinations in fvwm configuration file
> > are expressed 'Exec exec xterm -title ... -e ssh <user>@<host>' and do
> > not have a noticable delay.
> >
> > One is expressed 'Exec exec ssh -Y opendev xterm -title
> > roger at opendev', which you mention, and does have a noticable delay. It
> > seemed far easier to find out what was going on by asking about this
> > command rather than the formally identical 'ssh -Y <hostname> idle3.n'
> > command: xterm is in OpenBSD base so asking a Python question on
> > ports@ was probably too wide.
> >
> > It is the 'ssh -Y <hostname> idle3.n' command that worries me, and
> > two scripts with 'ssh -vvv -Y ...' traces follow. The first is for
> > starting idle, and the second is for invoking the open file dialogue.
> >
> > Adding '-o "ObscureKeystokeTiming no"' into the command gets rid
> > of the delay: but I count this as a workaround unless told this is
> > how the command is supposed to be done at OpenSSH 9.5 compared with
> > OpenSSH 9.3.  
> 
> It's possible the timing attack mitigation interacts badly with
> X11 forwarding. Could you try this patch? If you still have problems,
> then please post another -vvv debug trace.
> 

The patch gets rid of the delay.

> diff --git a/channels.c b/channels.c
> index 1b310e3..111c808 100644
> --- a/channels.c
> +++ b/channels.c
> @@ -886,6 +886,23 @@ channel_still_open(struct ssh *ssh)
>  	return 0;
>  }
>  
> +/* Returns true if a channel with a TTY is open. */
> +int
> +channel_tty_open(struct ssh *ssh)
> +{
> +	u_int i;
> +	Channel *c;
> +
> +	for (i = 0; i < ssh->chanctxt->channels_alloc; i++) {
> +		c = ssh->chanctxt->channels[i];
> +		if (c == NULL || c->type != SSH_CHANNEL_OPEN)
> +			continue;
> +		if (c->client_tty)
> +			return 1;
> +	}
> +	return 0;
> +}
> +
>  /* Returns the id of an open channel suitable for keepaliving */
>  int
>  channel_find_open(struct ssh *ssh)
> diff --git a/channels.h b/channels.h
> index 7cfba92..c31733f 100644
> --- a/channels.h
> +++ b/channels.h
> @@ -337,6 +337,7 @@ int	 channel_output_poll(struct ssh *);
>  int      channel_not_very_much_buffered_data(struct ssh *);
>  void     channel_close_all(struct ssh *);
>  int      channel_still_open(struct ssh *);
> +int	 channel_tty_open(struct ssh *);
>  const char *channel_format_extended_usage(const Channel *);
>  char	*channel_open_message(struct ssh *);
>  int	 channel_find_open(struct ssh *);
> diff --git a/clientloop.c b/clientloop.c
> index deebbba..cb69c72 100644
> --- a/clientloop.c
> +++ b/clientloop.c
> @@ -580,7 +580,7 @@ obfuscate_keystroke_timing(struct ssh *ssh, struct timespec *timeout,
>  	if (options.obscure_keystroke_timing_interval <= 0)
>  		return 1;	/* disabled in config */
>  
> -	if (!channel_still_open(ssh) || quit_pending) {
> +	if (!channel_tty_open(ssh) || quit_pending) {
>  		/* Stop if no channels left of we're waiting for one to close */
>  		stop_reason = "no active channels";
>  	} else if (ssh_packet_is_rekeying(ssh)) {

Thanks

Roger