(this is getting a bit off topic, I'll try to drag it back ontopic later) On Sun, Oct 23, 2005 at 08:35:23PM -0800, Ethan Benson wrote: > On Mon, Oct 24, 2005 at 12:36:17PM +1000, Ian Mortimer wrote: > > > > This is not how ssh authentication works with public keys. > > What happens is along this lines: > > I believe this is backwards. [...] You're both partly right, depending on which version of the SSH protocol you were referring to. SSHv1 [1] 1. client sends RSA auth request with actual public key 2. server checks for corresponding public key in user's public key file, responds with failure or challenge encrypted with public key 3. client decrypts challenge, sends md5(sessionid, challenge) to server 4. server verifies md5 hash SSHv2 [2] 1. client sends "will you accept this key" pubkey auth request (which includes the algorithm and actual public key in question). 2. server replies whether or not it will 3. client signs packet which contains sessionid, username and public key 4. server verifies public key is permitted access and signature is valid (note that steps 1 and 2 are optional) So, for SSHv1 possession of the private key is proved by decrypting the challenge sent by the server. For SSHv2, possession of the private key is proved by the ability to sign the public-key authentication request with the correct key. (The latter allows the use of sign-only algorithms.) OK, dragging this back on topic, if you were to want a PAM module to perform the public key authentication, you would need to: a) pass the session identifier, public key algorithm type and actual public key to the module(s), b) make the conversation function mechanism understand public keys in addition to text, and c) provide some way for PAM to say "yes I would accept that key" (step 2 in the SSHv2 example, above). For a), this would probably mean defining some new types for pam_set_item. (The sessionid is derived during the initial part of the SSH protocol and is sensitive information, so passing it via the environment would be bad.) For b) you would need to define some new message types for the conversation structs. For c), you would probably need a new return value for pam_authenticate. Then you'd need to teach sshd to use all of these, and the result would be something that works on your box and nowhere else. It sounds like an awful lot of work for not very much gain. If the objective of the exercise is centralised public key management then the LDAP/nss method seems like a much simpler path. [snippage] > You can only encrypt with a public key, you cannot decrypt. That's not correct (for RSA at least). You can only do the inverse of the operation performed by the private key. A "sign" operation is encrypting with the private key, anyone with the public key can decrypt it, thus verifying the signature (see Schneier Ch 2.6 & Ch 19.3). > > At no stage does the client send the public key to the server. > > true, the server already has the public key (its in authorized_keys). > the client also never sends the private key to the server, it only > sends the Comment string so the server knows which key in > authorized_keys one wishes to use. That's not correct, both protocols involve sending the public key to the server. [1] http://www.zip.com.au/~dtucker/openssh/ssh-rfc-v1.txt [2] http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-27.txt -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
