Hello, In our project we connect a cluster of appliances to a central managing system via ssh. When a new appliance is deployed, the administrator provides it with an ip address and a "connection password". Later, the manager connects to the configured ip address (over a supposedly untrusted network), and the "connection password" is used as a shared secret to build a mutual trust and exchange long lived public keys that secure all future communication. [Yes, this provisioning procedure is outdated and should be replaced, e.g. by letting the appliance generate a key pair locally and just transmitting the public key to the managing system over a separate channel, instead of transmitting the shared secret, but for now we can't change the established procedure] Connecting to an untrusted machine via ssh with password authentication will immediately reveal the shared secret to a man-in-the-middle attacker, so using the shared secret this way is out of the question. What we came up with instead is to use the shared secret by deterministically deriving an ssh key pair on both, the appliance and the manager. Each side installs the public key in its authorized_keys file. The manager contacts the applicance first, using the key for pubkey authentication, and transmit its IP address and its (public) host key. Upon reception of the message, the appliance will send another message back in the same way, transmitting is host key. As soon as both sides did receive a message from the other one, they can trust each other and exchange the long lived keys. To support this method of trust establishment, I patched ssh-keygen, supplying an option (-d <data>)to derive a key from a given secret deterministically (by seeding the PRNG). The first version of the patch only worked for ed25519 keys, but I now have a patch that will work for openssl generated keys as well. The patch applies cleanly to the original 8.0p1 sources. Would you consider adding this feature to ssh-keygen? Another possible use case might be human memorizable key pairs, so I think it is not too tightly bound to our specific use case. Best regards, Nils Rennebarth -- Dipl. Math Nils Rennebarth Senior Berater Entwicklung Division Network & Client security secunet Security Networks AG Tel.: +49 201 5454-3976 Fax: +49 711 900300-90 Mobil: +49 174 9750449 E-Mail: nils.rennebarth@xxxxxxxxxxx Neue Brücke 3 70173 Stuttgart www.secunet.com ______________________________________________________________________ Sitz: Kurfürstenstraße 58, 45138 Essen, Deutschland Amtsgericht Essen HRB 13615 Vorstand: Axel Deininger (Vors.), Torsten Henn, Dr. Kai Martius, Thomas Pleines Aufsichtsratsvorsitzender: Ralf Wintergerst ______________________________________________________________________ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
