openssh unix dev - May 2018 - Password change required but no TTY available

Hi,

I upgraded for one of our products the SSH server to the portal OpenSSH
7.7p1 release. While testing I observed a change in the behavior for
expired passwords.

The commit 7c8568576071 ("upstream: switch over to the new
authorized_keys options API and") dropped the 'allowed pty' option
when
the password has expired. By adding this hack here, I got it
back to the old behavior:


--- a/auth-passwd.c
+++ b/auth-passwd.c
@@ -62,6 +62,7 @@ extern ServerOptions options;
 extern login_cap_t *lc;
 #endif

+extern struct sshauthopt *auth_opts;

 #define DAY		(24L * 60 * 60) /* 1 day in seconds */
 #define TWO_WEEKS	(2L * 7 * DAY)	/* 2 weeks in seconds */
@@ -122,8 +123,11 @@ auth_password(struct ssh *ssh, const char *password)
 	}
 #endif
 	result = sys_auth_passwd(ssh, password);
-	if (authctxt->force_pwchange)
+	if (authctxt->force_pwchange) {
 		auth_restrict_session(ssh);
+		/* Allow password change via pty */
+		auth_opts->permit_pty_flag = 1;
+	}
 	return (result && ok);
 }


Is this an intentional change (auth_restrict_session) or is just an
oversight to enable the PTY back to allow password changes remotely?

Maybe I should also explain why the change is a problem for us. We have
a product which is configured and controlled via SSH. Although, each
device gets an individual password by the factory, we still would like
to force the customer to set the password new one the initial connection
attempt. 'passwd -e' was our approach so far to expire the password for
the account.

Thanks,
Daniel

On Thu, 24 May 2018, Daniel Wagner wrote:
> Hi,
> 
> I upgraded for one of our products the SSH server to the portal OpenSSH
> 7.7p1 release. While testing I observed a change in the behavior for
> expired passwords.
> 
> The commit 7c8568576071 ("upstream: switch over to the new
> authorized_keys options API and") dropped the 'allowed pty'
option when
> the password has expired. By adding this hack here, I got it
> back to the old behavior:
I think it's probably okay to allow the PTY in restricted sessions
generally.

The global PermitTTY option as well as any authorized_keys options will
still apply.

Does this solve your problem?

diff --git a/auth.c b/auth.c
index 63366768..4fc95457 100644
--- a/auth.c
+++ b/auth.c
@@ -1080,6 +1080,7 @@ auth_restrict_session(struct ssh *ssh)
 
 	/* A blank sshauthopt defaults to permitting nothing */
 	restricted = sshauthopt_new();
+	restricted->permit_pty_flag = 1;
 	restricted->restricted = 1;
 
 	if (auth_activate_options(ssh, restricted) != 0)

Hi Damien,

On 05/25/2018 02:37 AM, Damien Miller wrote:
> I think it's probably okay to allow the PTY in restricted sessions
> generally.
> 
> The global PermitTTY option as well as any authorized_keys options will
> still apply.
> 
> Does this solve your problem?
> 
> diff --git a/auth.c b/auth.c
> index 63366768..4fc95457 100644
> --- a/auth.c
> +++ b/auth.c
> @@ -1080,6 +1080,7 @@ auth_restrict_session(struct ssh *ssh)
>  
>  	/* A blank sshauthopt defaults to permitting nothing */
>  	restricted = sshauthopt_new();
> +	restricted->permit_pty_flag = 1;
>  	restricted->restricted = 1;
>  
>  	if (auth_activate_options(ssh, restricted) != 0)
Yes, this does also work and it looks way better than my hack :)

Thanks,
Daniel