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@remote decides that the password @remote needs to be changed, and ssh@local and sshd@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@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@xxxxxxxxx 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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
