sshd-session.exe and LoginGraceTIme

[emad350]

I had initially installed v9.8 and was finding that a connection which connects but doesn't authenticate isn't terminated after 120 seconds, which is the default timeout if LoginGraceTIme isn't' defined. Defining a Value to LoginGraceTime didn't help either.

I upgraded to version 10.0 but the same issue persisted.

I then downgraded to V7.7 (since this is the same as Windows Server 2019). This version does terminate a connection which doesn't authenticate based on LoginGraceTime setting.

In task manager, I then noticed that both version 10 and version 9.8, spawned a 'sshd-session.exe' for a new incoming connection but version 7. spawned a sshd.exe session.

I went through your releases and it looks like sshd-session was introduced in version 9.8 I didn't install 9.5 to look for its behaviour.

Is this a bug in sshd-session.exe?

[tgauth]

Are you saying that with V9.8 and V10.0, you're able to authenticate even after LoginGraceTime expires?

LoginGraceTime should still work with sshd-session.exe. Note there is a jitter that was introduced in upstream's V9.9 so it may not be exactly 120 seconds (if set to the default) - https://www.openssh.org/txt/release-9.9

[emad350]

Good question. The session does terminate in v9.8 and v10 but the sshd-session.exe process which spawns doesn’t terminate and keeps running as a process.

The ssd-session.exe process only terminates after the client input causes it to disconnect due to timeout.

I used sftp command in windows to test this. You can connect via ‘sftp user@sshserver’ and leave it unattended. So while the LoginGraceTime logic is applied and the connection is considered terminated, the spawned process continues to run, until interact with the sftp connection (which is waiting for password). At this point the sftp kicks back to command prompt and the sshd-session.exe process finally terminates.

If I don’t interact with the sftp, and leave it waiting at the password prompt, the sshd-session.exe process will stay active.

[o-sdn-o]

Everything seems to be correct here, but the MSVC debugger is showing something wrong.
Apparently the children variable (struct _children children; in openssh-portable\contrib\win32\win32compat\signal_sigchld.c:36) was not initialized or corrupted when calling sw_child_to_zombie() on grace period timeout in sshd.exe.

[o-sdn-o]

Everything seems to be correct here, but the MSVC debugger is showing something wrong.
I think it shouldn't be like this, or I'm missing something:

[o-sdn-o]

Perhaps this is somehow related. After LoginGraceTime expires, I see endlessly running sshd-auth.exe processes, equal in number to the number of open remote sessions requesting passwords.

[o-sdn-o]

sshd-session.exe does not notify its child processes (sshd-auth.exe) of its abrupt termination in (openssh-portable\sshd-session.c:543), just exits:

/*
 * Signal handler for the alarm after the login grace period has expired.
 * As usual, this may only take signal-safe actions, even though it is
 * terminal.
 */
static void
grace_alarm_handler(int sig)
{
#ifndef WINDOWS
	/*
	 * Try to kill any processes that we have spawned, E.g. authorized
	 * keys command helpers or privsep children.
	 */
	if (getpgid(0) == getpid()) {
		struct sigaction sa;

		/* mask all other signals while in handler */
		memset(&sa, 0, sizeof(sa));
		sa.sa_handler = SIG_IGN;
		sigfillset(&sa.sa_mask);
#if defined(SA_RESTART)
		sa.sa_flags = SA_RESTART;
#endif
		(void)sigaction(SIGTERM, &sa, NULL);
		kill(0, SIGTERM);
	}
#endif /* WINDOWS */
	_exit(EXIT_LOGIN_GRACE);
}