[kwlug-disc] How to ... having ssh key connected ... ask for password, logout if fail?

[bob+kwlug at softscape.ca]

> If I'm following the article correctly, all the article is talking about
> (wrt SSH Certificates) is signing the ssh public key with a CA so that
> when a ssh client first connects they are not prompted to accept the
> server - since the public key used is independently confirmed as correct
> by checking with the CA (the first time that ssh client sees that ssh
> server). [You're definitely connecting to the ssh server you thought you
> were and intended to be.]
> 
> Which is to say, instead of being prompted to add the server to known
> hosts, it is added without prompt.
> 
> Have I missed something?
> 
> If not, then this isn't bringing anything to my search to be prompted
> for userid / password at ssh connect with key file. (But does add
> additional security.)

Disclosure, I didn't read article for applicability, but I though the section about "Signing User Keys" might be closer to what you were looking for.

In scanning it again, it does not seem to give you any more functionality than an ssh public/private key pair did other than not needing individual entries in the authorized_keys.

However, and I'm wildly speculating here, maybe that's what you're looking for.

If your goal is to be able to keep access to your ssh server limited to a number of users and be able to revoke an individual's ability to log in (which is what I think you wanted to do by using a private key to get to a password prompt: so that you could limit arbitrary brute force attacks against user passwords, but still have the ability to lock out a specific user  with a password change). But you didn't want to keep individual public keys in the authorized_keys file, then this would fit the bill.

If I understood the client certificate section correctly, you could issue certificates to clients you allowed login but not need to keep a public key for them (that's what the signing certificate's job becomes). Lockout would need to be done by key revocation list (ie: "RevokedKeys /etc/ssh/revoked-keys") and it's probably a very good idea to keep client certificates to a limited time for validity so this revocation file didn't grow without limit.

Sounds like a PITA in terms of management, but again, might be a good fit if your goal is to not keep a lot of keys in the authorized_keys file. This might also be a good fit if you had something like a class where students would have a limited time to be able to ssh into a server if you set the certificate validity dates on the client cert to the duration of the class.


Can you explain a little more your motivation for your ideal solution? (ie: needing a private key to be prompted for a password) I assume that if you don't have a key, you never get any response from the server.

NB: I consider certificates a black art and my interpretation of how they work in this context could be waaaay off. I know enough to know that I don't know enough to speak with authority so if anyone can contribute, I'd appreciate it. 


(the other) Bob.

PS: I just saw your .bashrc code snippet and I guess my speculation was not correct. Anyway, was a fun exercise.