beltorak
By:
beltorak

Problems with creating an SSH CA, attempting to following the tutorial as a guide

February 12, 2015 2k views

Hi; I am attempting to follow the tutorial posted here as a guide.

I've created three LXC machines to practice with: ssh-ca, ssh-server, and ssh-client.

On ssh-ca I self-signed the "ssh_host_ed25519_key" yielding "ssh_host_ed25519_key-cert.pub".

I transferred the ssh-server "ssh_host_ed25519_key.pub" to the ssh-ca machine as "server.pub", signed it with the ssh-ca's "ssh_host_ed25519_key" yielding "server-cert.pub", and transferred this back to ssh-server as "ssh_host_ed25519_key-cert.pub". I edited ssh-server's "sshd_config" to add HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub and restarted the ssh-server sshd daemon (service ssh restart).

I transferred the ssh-ca "ssh_host_ed25519_key-cert.pub" to ssh-client and stuck it in ~/.ssh/known_hosts file as (roughly)

@cert-authority * ssh-ed25519-cert-v01@openssh.com AAAAIHN ... QFRDQ==  root@trusty-builds

However, attempting to log in from ssh-client to ssh-server (abbreviated ssh -v output):

debug1: Server host key: ED25519-CERT 85:46:34:5f:93:4c:d0:f5:c3:a4:14:87:38:b9:41:7d
debug1: ssh_ed25519_verify: signature correct
debug1: No matching CA found. Retry with plain key
The authenticity of host '10.0.1.222 (10.0.1.222)' can't be established.
ED25519 key fingerprint is 85:46:34:5f:93:4c:d0:f5:c3:a4:14:87:38:b9:41:7d.
Are you sure you want to continue connecting (yes/no)?

What am I doing wrong? Is * a valid hostname wildcard? Is it possible I messed up one of my signing commands? How could I verify that the ssh-server cert is signed by the ssh-ca key?

Thanks

1 comment
1 Answer
byteme September 20, 2016
Accepted Answer

The ssh client tries to validate the hostname given in the certificate the server sent.
The hostname had to be given after the -n switch, when signing the server's public key.

ssh-keygen -s server_ca -I host_host1 -h -n host1.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

If you have forgotten the name, you can also see it in the debug messages when you try to connect to the server via ssh with -vv. (I had the same problem...)

debug1: Server host certificate: ssh-rsa-cert-v01@openssh.com SHA256:...
debug2: Server host certificate hostname: host1.example.com
debug1: No matching CA found. Retry with plain key
The authenticity of host '192.168.33.12 (192.168.33.12)' can't be established.

When trying to connect to the host via IP, one has to give the hostname in the options:

ssh -o HostName=host1.example.com root@192.168.33.12

* is a valid hostname wildcard.

  • Sorry, I had to add IP and hostname to the hosts file. After that the following worked too:

    ssh root@host1.example.com
    
  • Ah; that was the missing key.

    I redid it and added an entry for the ssh-server to the client's /etc/hosts file (as stated in your reply to this answer), that was the only missing piece. Once the IP can be resolved by name, there's little point to using the IP in the ssh command line (especially if you have to use the host name as a command line option).

    I'm not sure what the hostname resolution is supposed to protect against - shouldn't the identity of the server be established by the private key and public cert? This is after all essentially what the regular key verification mechanism (where you eyeball some ascii-art derived from the server keypair) relies on. Although subverting both a server and a DNS system raises the bar a little bit, it does preclude using this for an ssh server behind typical consumer broadband unless you also enlist a dyndns service (or a real DNS service, or are willing to hack your /etc/hosts file periodically).

    Ah well, there's probably something obvious I'm missing in that analysis.

    Thanks again for the help :)

Have another answer? Share your knowledge.