jonwatson blog

broadcasting useless crap to the internet since 1200 baud

Expect scripting

I’ve been playing with Expect lately. Expect is an extension of the TCL scripting language developed in the 1990s. It main purpose in life is to automate terminal interactions and it does that job very well.

I spend most of my day in a shell and automate as much as humanly possible so that I can be as lazy as humanly possible. Using tools like ssh and scp it’s very easy to automate simple commands and simple file transfers. But when these tasks become complex enough that they need to respond to terminal prompts, or provide arbitrary changing input, those tools fall apart.

My particular use case was a need to grep through logs on multiple Linux servers looking for PAN (credit card) data as part of a PCI compliance exercise. This would be a trivial task to achieve using plain old ssh except for the fact that I use a Yubi key to log on to the servers and I have to go through a bastion host, so every login happens twice. I need to interactively provide the PIN for my Yubi at each login. The same problem exists for encrypted public keys. For a while I just copied my Yubi PIN and pasted it at every prompt, but that became a pain pretty quickly so I started casting around for other options.



I've lost track how many times someone has come wandering up to me with a bunch of private keys and a cert and thrown it all at me saying “I dunno which key was used!”. The slow way to figure that out is to put them into your web server config and see if it starts. The easier way is to use openssl.

Assuming the certificate is in $CERTFILE and the key is in $KEYFILE, these two openssl commands will extract the modulus out of each:

$ openssl x509 -noout -modulus -in $CERTFILE | openssl md5

$ openssl rsa -noout -modulus -in $KEYFILE | openssl md5

If the moduluses (moduli?) match, then you can be pretty sure that is the key that goes with this cert.

#SSL #sysadmin