openssh unix dev - Jun 2018 - Is there such a thing as "Password Safe Forwarding"?

Hello everyone,

I work in a setting where remote logins are usually authenticated with
SSH user keypairs, but many target accounts need to have a password set
nonetheless (to use with sudo, log in via remote KVM, etc.) and cannot
be put under a central user administration like LDAP.

Enter a corporate password policy that requires passwords to be complex,
different everywhere, and of limited lifetime. It helpfully suggests the
use of password safes, but doesn't allow the lifetime to be extended by
making the password *really* complex.

It seems that most, if not all, systems in question have sufficiently
advanced PAM to enforce the "complex" part of the policy, *and* to
provide even users logging in with SSH keypair auth with early warnings
and automatic you-need-to-change-your-password-NOW prompts.

However, when that happens, users will need to *manually* transfer the
new password from the (local) generator to the (remote)
password-changing mechanism and, upon success, back into their (local)
password safe. Given that many such users are supporters having a
customer on the phone, I'm a bit wary of this procedure introducing
typos/truncations and leading to
oh-I-cannot-SSH-now-and-don't-have-a-working-password-either situations.

Hence my question: Are there ideas/plans/projects to have an OpenSSH
connection provide a communication channel between password safe(*) and
the remote password-changing mechanisms, similar to how Authentication
Agent Forwarding mediates communication between a local ssh-agent and
remote ssh/scp/sftp/... clients? Would there be suitable pre-existing
protocols to communicate stuff like "password change needed yes/no",
"new password failed, please retry" etc. etc. between the end points?

(*) A still-to-be-written/-patched one, if need be ...

(Yes, I'm pondering U2F, but *that* is *missing entirely* from the
policy and would probably require a rewrite to happen upstairs ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180619/ee0fcccc/attachment.p7s>

On Tue, Jun 19, 2018 at 02:13:56AM +0200, Jochen Bern
wrote:
> Enter a corporate password policy that requires passwords to be complex,
> different everywhere, and of limited lifetime. It helpfully suggests the
> use of password safes, but doesn't allow the lifetime to be extended by
> making the password *really* complex.
A sufficiently advanced password vault (e.g. CyberArk EPV) will allow a
user to request the current password and then will reset the password
some time later (eg 24 hours)... and can ensure passwords are reset
every 80 days (or whatever) so they don't expire.  There's a number
of products on the market that can do this.  In the worst case they
ssh into the account with the old password, run the "passwd" command
and set a new one.  In a good case they have access to a privileged
account (eg one with "sudo passwd") so they can reset the password
even if the old one doesn't work.

In this way the password is only known for a short period of time.
> Hence my question: Are there ideas/plans/projects to have an OpenSSH
> connection provide a communication channel between password safe(*) and
> the remote password-changing mechanisms, similar to how Authentication
> Agent Forwarding mediates communication between a local ssh-agent and
> remote ssh/scp/sftp/... clients? Would there be suitable pre-existing
> protocols to communicate stuff like "password change needed
yes/no",
> "new password failed, please retry" etc. etc. between the end
points?
If you go down this route then it sounds like a a PAM password change
module that can push the new password into the vault might be a better
option, so if the "passwd" command is run then it'll also push it.

I don't think sshd is the right place for this.

-- 

rgds
Stephen

On 06/19/2018 02:36 AM, Stephen Harris wrote:
> On Tue, Jun 19, 2018 at 02:13:56AM +0200, Jochen Bern wrote:
>> Enter a corporate password policy that requires passwords to be
complex,
>> different everywhere, and of limited lifetime. It helpfully suggests
the
>> use of password safes, but doesn't allow the lifetime to be
extended by
>> making the password *really* complex.
> 
> A sufficiently advanced password vault (e.g. CyberArk EPV) will allow a
> user to request the current password and then will reset the password
> some time later (eg 24 hours)... and can ensure passwords are reset
> every 80 days (or whatever) so they don't expire.  There's a number
> of products on the market that can do this.  In the worst case they
> ssh into the account with the old password, run the "passwd"
command
> and set a new one.  In a good case they have access to a privileged
> account (eg one with "sudo passwd") so they can reset the
password
> even if the old one doesn't work.
Hmmmm, noted. I'm afraid that as-is, said company policy is not willing
to give the nod to a *central* password storage, much less one that
actively *uses* them (to change them in time) ...

(It *also* fails to even mention tokens, OTPs, biometry, 2FA as a whole,
etc.. As I said, it was written "upstairs". Password safes for those
who
would otherwise need to memorize dozens of passwords appear in a single
sentence tacked onto the end of a paragraph, clearly an afterthought ...)
>> Hence my question: Are there ideas/plans/projects to have an OpenSSH
>> connection provide a communication channel between password safe(*) and
>> the remote password-changing mechanisms, similar to how Authentication
>> Agent Forwarding mediates communication between a local ssh-agent and
>> remote ssh/scp/sftp/... clients? Would there be suitable pre-existing
>> protocols to communicate stuff like "password change needed
yes/no",
>> "new password failed, please retry" etc. etc. between the end
points?
> 
> If you go down this route then it sounds like a a PAM password change
> module that can push the new password into the vault might be a better
> option, so if the "passwd" command is run then it'll also
push it.
> 
> I don't think sshd is the right place for this.
The scenario is that the user has a password safe at hand (whether it is
actually *running* locally or not), PAM at remote decides that the password
@remote needs to be changed, and ssh at local and sshd at remote have *just*
established and fully authenticated a connection between the two hosts.

(Add to that that "local" is a workplace in a fully SNATed LAN,
"remote"
includes customer premises installations somewhere over the Internet,
some even requiring use of a remote jump host, and I do *not* want to
Just Trust(tm) PAM at remote not to finger whichever entry it pleases if I
were to give it a separate, transparent, agnostic connection to the
password safe.)

I'm sort of seeing the ssh client as the component that can authenticate
(PAM@)remote to the password safe and authorize access to the *one*
correct entry, because it *already has* most of the information&channels
needed to do that.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Fon:    +49 6151 9067-231
Fax:    +49 6151 9067-290
E-Mail: jochen.bern at binect.de

www.binect.de
www.facebook.de/binect

Binect ist ausgezeichnet:
Sieger INNOVATIONSPREIS-IT 2017 | Das B?ro: Top 100 B?roprodukte 2017

Binect GmbH

Robert-Koch-Stra?e 9, 64331 Weiterstadt, DE

Gesch?ftsf?hrung: Dr. Frank Wermeyer, Nils Manegold
Unternehmenssitz: Weiterstadt
Register:         Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID:  DE 221 302 264

MAX 21-Unternehmensgruppe
?
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgf?ltig erstellt worden, dennoch
schlie?en wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrs?blichen Ma?nahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anh?nge an dieser Nachricht durchzuf?hren.
Wir schlie?en, au?er f?r den Fall von Vorsatz oder grober
Fahrl?ssigkeit, die Haftung f?r jeglichen Verlust oder Sch?den durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180619/64e6c251/attachment.p7s>