5

Is it possible to set up SSH (via pam for instance) to check the public key of the connecting client against a CA server? I've tried with gnupg (via gpg-agent --daemon --enable-ssh-support) and also tried working with OpenCA which proved to be a challenge just to install. Also, the documentation is horrific when it comes to both of these.

What I'd like to accomplish is something along the lines of:

[Client] --SSH--> "Server" <---> [CA Server]

The entire platform is *nix based and I'm open to suggestions right about now cause I've been stuck on this for a while now.

GnuPG

I've set it up in as simply as possible following these guides:

My initial thought was to set up my own "key-server" which gpg can send and check for keys, but there's no information about this what so ever (or at least none that I could find).

And from what I understand I should be able to do ssh-add -l to list all my keys, but this gives me: The agent has no identities. which is not so odd because I've never specified where to fetch them but "it should just work"(...?).

The gpg.conf looks like:

... lots of default ...
personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
homedir /etc/gnupg
use-agent

and my gpg-agent.conf:

pinentry-program /usr/bin/pinentry-curses
default-cache-ttl 10800
default-cache-ttl-ssh 10800
write-env-file /etc/gnupg/.gpg-agent-info
enable-ssh-support

And just to verify that i actually have a key and gpg is responding:

~]# gpg --list-keys
/etc/gnupg/pubring.gpg
----------------------
pub    4096R/#######2 2013-12-10 [expired: 2014-12-10]
uid                   Anton (...) <mail>
sub    4096R/#######5 2013-12-10 [expires: 2014-12-10]

OpenCA

When finally everything was in place and started, I get to a website that says my "symmetric keylength is too short" and I can't get past that.

3

I know this is a very old question. However, there are two answers to your question.

Getting GPG working with SSH.

You've done the first step, enabling-ssh-support in your gpg-agent.conf

But, you haven't supplied any PGP keys to use. In order to use PGP keys with ssh, you've got to export the public key in ssh format and add that to your remote host's ~/.ssh/authorized_keys file. Then add the keygrip of the private key to the file ~/.gnupg/sshcontrol.

To export a PGP public key as ssh:

$gpg -a --export-ssh-key [keyid]

To view a PGP keygrip: $gpg --with-keygrip --list-secret-keys [keyid]

I usually create a suitable subkey for use with SSH. If you are using GPG 2.2.1 then you can even use ED25519.

$gpg --expert --edit-key [keyid]
    gpg> addkey
        Option 11 for ECC
        Option A to add authentication
        Option 1 for Curve 25519
        Expire never
        Create yes
    gpg> save

Then export just the authentication subkey:

$gpg -a --export-ssh-key [auth subkeyid]!

The exclamation point selects just the indicated subkey.

You will also need to make sure the environment variables are set in your ~/.bashrc ... If you are running an Xwindow client, this is usually done for you via /etc//X11/Xsession.d/90gpg-agent with the following bash script:

agent_sock=$(gpgconf --list-dirs agent-socket)
export GPG_AGENT_INFO=${agent_sock}:0:1
if [ -n "$(gpgconf --list-options gpg-agent | \
      awk -F: '/^enable-ssh-support:/{ print $10 }')" ]; then
    export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
fi

Once you've ensured the environment variables are set, any keygrips added to the ~/.gnupg/sshcontrol file will appear as authentication keys in the ssh-agent when you list the available identities:

$ssh-add -l

Note, you can change the shown hash via the -E option to show MD5 or SHA256.

Configuring SSH to use certificates

This is a rather complex question. Red Hat has a detailed walkthrough here:

Redhat SSH CA Tutorial

End

It's unclear if it's possible to use PGP keys as the SSH CA keys. I haven't tried that myself. However, I do use PGP keys on the client side. I find that it makes life very easy and is less cumbersome to manage SSH identities than using ssh-genkey generated keys.

  • Well written, thought out, good solution to the problem! Well done! – Torxed Oct 22 '17 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.