Password change required but no TTY available

1,684 views
Skip to first unread message

Daniel Wagner

unread,
May 24, 2018, 10:41:56 AM5/24/18
to openssh-...@mindrot.org
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
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Damien Miller

unread,
May 24, 2018, 8:39:07 PM5/24/18
to Daniel Wagner, openssh-...@mindrot.org


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)

Daniel Wagner

unread,
May 25, 2018, 3:07:38 AM5/25/18
to Damien Miller, openssh-...@mindrot.org
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

Damien Miller

unread,
May 25, 2018, 3:18:40 AM5/25/18
to Daniel Wagner, openssh-...@mindrot.org
On Fri, 25 May 2018, Daniel Wagner wrote:

> 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, I've committed this. It will be in OpenSSH 7.8 and I'll also
cherry-pick it for the V_7_7 stable git branch.

-d

----

commit fbb4b5fd4f8e0bb89732670a01954e18b69e15ba (HEAD -> master, origin/master, origin/HEAD)
Author: d...@openbsd.org <d...@openbsd.org>
Date: Fri May 25 07:11:01 2018 +0000

upstream: Do not ban PTY allocation when a sshd session is restricted

because the user password is expired as it breaks password change dialog.

regression in openssh-7.7 reported by Daniel Wagner

OpenBSD-Commit-ID: 9fc09c584c6f1964b00595e3abe7f83db4d90d73
Reply all
Reply to author
Forward
0 new messages