Intentionally top posting. Thanks for the reply!
I'm thinking of two or three paths forward -- one is to give up on this, but I've invested a lot of calandar days (and non-"spare" manhours so far, so I don't want to do that. Another is to make another pass through some of what I consider the best documentation I've found so far and see if I can puzzle out the answers and such that I'm looking for. The third is to ask questions on this list, and I think that is at least part of what I'll try. Some of my questions (and even the entire subject) will probably involve some fairly wordy introduction to the questions. Sorry about that. I'll probably start with a post to describe one of the most surprising things I learned about ssh so far -- to jump ahead and spoil it, it turns out that public key encryption is not used for the exchange of the real "user" / payload data, but instead a symmetric (one of a variety, iiuc) encryption algorithm, with the same encryption key used by both the client and server, but developed by each independently and never exchanged "over the wire". This is done by a process named Diffie_Hellman key exchange, and the Wikipedia article on that (URL below) explains it quite well, with one example done in terms of colors of paint (i.e., that people without an extensive background in math or cryptography can understand). [[https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange][Diffie– Hellman key exchange - Wikipedia]] I guess this serves as that first post I mentioned. No questions so far. Nothing new below this line. On Thursday, July 14, 2022 11:35:50 AM to...@tuxteam.de wrote: > As someone else said, I agree that the certificate way is quite a bit more > complex than just distributing public keys. It'll play out its advantages > if you have many servers /and/ many users -- the disadvantages are clear: > you have to manage your CA (where the root of trust resides), /and/ your > servers need regular access to the CRLs (certificate revocation lists) for > the case anything gets compromised (of course, you could do whithout, but > then, why use certs at all?). > > An alternative for a more central and orderly key distribution is to put > pubkeys in some form of directory service (say, LDAP). In our $COMPANY > (sub-100s of servers, sub-50 of IDs) we chose that path. Newer ssh servers > can delegate the authorized_keys to a script (i.e. the server doesn't > look things up in a file but runs a small program/shell script which is > supposed to output something looking like the authorized_keys file). > > OTOH, if all you want is to learn how this cert stuff works, that's > *always* a strong reason to try! > > Cheers -- rhk If you reply: snip, snip, and snip again; leave attributions; avoid top posting; and keep it "on list". (Oxford comma included at no charge.) If you change topics, change the Subject: line. A picture is worth a thousand words -- divide by 10 for each minute of video (or audio) or create a transcript and edit it to 10% of the original.
