Is there such a thing as "Password Safe Forwarding"?

[Jochen Bern]

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>