I recently came across an article which tries to address the problem of SSH agent forwarding with screen. Briefly, the problem is that reattaching a screen instance breaks agent forwarding because the required environment variables aren't present in the screen instance. The solution given didn't quite work for me though because I use an SSH wrapper script which automatically runs screen.

My solution is to write a screen wrapper script which stores the environment variables in ~/.sshvars (as export statements) and then starts screen. Running source ~/.sshvars in the shell then makes the variables available. (I created an alias called fixssh to do this.)

I like to put wrapper scripts in ~/bin with the same name. This didn't work out the box however, since ~/bin is only added to PATH in ~/.profile but this file is only sourced if the shell is interactive. The fix is therefore to add the following to ~/.bashrc, but near the top before the [ -z "$PS1" ] && return line.

if [ -d "$HOME/bin" ]; then
    PATH="$HOME/bin:$PATH"
fi

I was looking through a list of DNS record types, and noticed the SSHFP and CERT records. I then proceded to implement these in my domain... just because I can ;-)

SSH Host Keys

The SSHFP record is used to publish the fingerprint of a host's SSH key. When an SSH client connects to a server for the first time, it can verify the host's key by checking for this DNS record. The format of the record is specified in RFC 4255, but there is also a tool which will generate the records for you.

$ sshfp -s mammon.gorven.za.net
mammon.gorven.za.net IN SSHFP 1 1 5e6772b6962f3328a0d73f7765097b7622f21447
mammon.gorven.za.net IN SSHFP 2 1 00e59b1843421f13d75e21abb06bf032a6e60b8b

The SSH client needs to be configured to check these records. Specifying "VerifyHostKeyDNS ask" in ~/.ssh/config will make the client look for SSHFP records, but will still prompt you to accept the key. (It will output a messaging saying that it found a matching key.) Specifying "VerifyHostKeyDNS yes" will skip the prompt if the record exists and matches the key presented by the server.

GPG Keys

The CERT record is used to publish public keys or fingerprints. It can be used for PGP, X.509 or SPKI keys. It is specified in RFC 4398, and there is very little mention of it other than this blog post I found. To generate records you need the make-dns-cert tool which is part of GnuPG. It isn't distributed in the Ubuntu package however, and so I had to compile GnuPG from source.

To determine the name of the record to use, convert your email address into a domain name by replacing the ampersand with a dot¹. To publish your entire public key, run the tool as follows.

$ make-dns-cert -k ~/pubkey -n michael

The first parameter specifies the file containing your public key in binary format, and the second parameter specifies the domain name to use. To publish a reference to your public key, run the tool as follows.

$ make-dns-cert -f BF6FD06EA9DAABB6649F60743BD496BD6612FE85 -u http://michael.gorven.za.net/files/mgorven.asc -n michael

The first parameter specifies the fingerprint of your key, and the second parameter the URL at which the public key can be found. It is also possible to only publish the fingerprint or only the URL. Simply add the record which the tool outputs to your zone file².

There is also another method to publish GPG keys called PKA. The only documentation I can find is a specification in German linked from the blog post mentioned above. I still managed to set it up though. This method uses a TXT record (similar to SPF). Here is my record.

michael._pka.gorven.za.net. TXT
"v=pka1\;fpr=BF6FD06EA9DAABB6649F60743BD496BD6612FE85\;uri=http://michael.gorven.za.net/files/mgorven.asc"

This specifies the fingerprint and URL, just as with the second CERT method above. In order to get gpg to check DNS for keys, you need to specify "--auto-key-locate cert,pka" on the command line or in the configuration file.