Single Packet Authorization with GnuPG Keys

If you want to use GnuPG to encrypt
communications from the fwknop client to the
fwknopd server, you will need to first create the necessary
GnuPG keys on both the client and server. If you already have a GnuPG key that you use for
email (or other) encryption, you can safely use this key on the client side
since it will only be used for message signing by fwknop. On the fwknopd
server you will need to create a special GnuPG key that is exclusively used for
fwknop communications. The reason stems from the fact that the password used
to unlock this key must be stored within the /etc/fwknop/access.conf file;
fwknopd must be able to decrypt messages that have been encrypted by an fwknop
client with the server's public key. Hence, it is not a good idea to use a
highly valuable personal GnuPG key on the server. Once you have created the
requisite keys, you will need to import and sign each key into its "opposite"
system; e.g. import and sign the server key into the client's GnuPG key ring,
and vice-versa.

Note

Because SPA messages must fit within a single IP packet, it is recommended to
choose a key size of 2048 bits or less for the fwknopd server
GnuPG key.

The process of generating the necessary GnuPG keys from the perspectives of both
the client and server is outlined below. First we generate GnuPG keys and then
export them to ascii files:

Next, we transfer the ascii files between the two systems. In this example we
use scp (which will presumably be firewalled off after fwknop is deployed!), but
any other transfer mechanism (ftp, http, etc.) will work:

On the server side, we need to add several configuration directives to the
/etc/fwknop/access.conf file so that fwknopd uses GnuPG to verify and decrypt SPA
packets and are signed and encrypted with GnuPG. Note that the server key ID is ABCD1234
and the client key ID is 1234ABCD:

More information on the access.conf directives above can be found in the fwknop
man pages. See
fwknop(8) and
fwknopd(8).

Finally, to see fwknop in action in GnuPG mode, on the client side we execute the
following fwknop command to gain access to sshd after
fwknopd reconfigures the local Netfilter policy. First
we show that nmap is unable to tell that
sshd is even listening: