ssh keys 7 December, 2006 at 4:15 pm

most of today, at the office, was spent digging through mysql code, to figure out where and how it authenticates, so i could know where to try putting in the ssh key code

then, once i think i identified the right places in the daemon and the client, it was into the ssh code :o  after much tracing and file changing etc, here’s how SSH handles a key exchange (given public/private RSA keys):

client connects to server, they negotiate their communication, then:

  • client identifies {A} as wanting to login, and chooses “no authentication, just let him in”
  • server tells him where to shove it and offers some auth options
  • client tries blah blah gets to key auth.
    • takes MD5 of the public key
    • hexadec encodes the MD5
    • takes ssh communication ID+HEX and saves it as “msg”
    • uses the private key to cryptographically encode (sign) msg
    • sends msg and signature to server
  • server receives this mess:
    • server knows the ID and the public key, so it generates it’s own copy of MSG
    • compares MSG and msg, if they mismatch, bad auth attempt
    • if they match, and there’s a sig, it generates SIG of it’s own
    • if sig and SIG match, authenticated

my first inclination is the need for a nonce (one-time randomly generated string) to pass back and forth.  but to be useful, server would need to encode it with public key so client can private decode.  but since there can be multiple keys on a single account for different purposes (such as i’ve set up accounts with a key that launches an automatic process and then logs out vs key2 which lets me log in properly), there’s no telling which key should be used for the encryption of the nonce …

and technically there’s no danger in passing around the public key.  it is, after all, public.  and with the (tiny bit of) entropy coming from the SSH communication ID, the signature will change, although the MD5 does not.  in the end, it boils down to, effectively, encrypting a few bytes of information (the ID) as everything else is static across every authentication.  it adds noise, however, since decrypting a bunch of short numeric messages would be easier than a long message, even if you know what the message says (which you do; it’s sent unencrypted first … I wouldn’t've done that either, TBH)

anyway, setting up MySQL should be … interesting.  I’ll have to put the public key in the database (so it can verify against, for a user) or in like /var/mysql/keys/ … pub key is required to verify the sig.  i might use it to encrypt a nonce, since i don’t (AFAICT) have a comm ID like SSH set up for such a purpose.  at which time, i may not bother sending the pubkey around.  server sends pub(nonce), client decrypts and sends pri(nonce), server decrypts and verifies nonce …

i’ll let you know how badly this fucks up ;)  and mysql can’ do SSL encrypted traffic unless client and server both have SSL certs, according to what I’ve read (i thought it could, so I may have found an old archive) … so i can fix that, or make this local-only (which makes more sense anyway)

Leave a Reply

You must be logged in to post a comment.