пт, 7 сент. 2018 г. в 11:57, Damien Miller <djm@xxxxxxxxxxx>: > > > On Fri, 7 Sep 2018, Alexander E. Patrakov wrote: > > > Hello. > > > > I am trying to play through the following test scenario about > > certificate revocation on Ubuntu 18.04, which has OpenSSH of this > version: > > OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017 > > > > 1. A CA key is created > > ssh-keygen -t ed25519 -f ca > > > > 2. The CA public key is added to ~/.ssh/authorized_keys on some server: > > cert-authority ssh-ed25519 AAAA...e ca@yoga > > > > 3. A user key is created on a different laptop: > > ssh-keygen -t ed25519 -f user > > > > 4. The CA gets user.pub, signs the user key and applies restrictions, > > then transfers user-cert.pub back to the user's laptop > > ssh-keygen -s ca -I user -V 20180906:20180908 -O clear -O permit-pty user > > (yes I know, at this point the CA has made a mistake of not specifying > > the unique serial, but still there is a unique ID supplied with "-I > > user", so nothing fatal) > > > > 5. The CA destroys its copy of the user.pub and user-cert.pub files, > > because a guide (e.g. https://ef.gy/hardening-ssh) says it is a good > idea. > > IMO #4 and #5 are bad CA practices and are the root of your problems. > > That being said, I think it's a great idea for the sshd authentication > log messages to contain enough information to be able to revoke keys > under all circumstances. > > The following patches implement this. They include the cert fingerprint > in the sshd "Accepted publickey ..." message and allow revocation by > the fingerprint hash. E.g. > > Given the log message of: > > Accepted publickey for djm from 127.0.0.1 port 54091 ssh2: RSA-CERT > SHA256:hNggUg6sCnYZFlaauRzwfqVSRsep3OpSngU7xQEj0ac ID regress user key for > djm (serial 19564) CA RSA SHA256:b6AasnX04A2zkjc6oWYEPhI01QsjK0h2YmjWdxCMe2U > > You'll be able to prepare a KRL spec: > > echo "SHA256:hNggUg6sCnYZFlaauRzwfqVSRsep3OpSngU7xQEj0ac" > /tmp/krlspec > ssh-keygen -kf /tmp/krl /tmp/krlspec > > Unfortunately, since I had to add a new KRL section to list keys by > SHA256 hash, these KRLs will only be readable by OpenSSH with the patch > (hopefully it will ship in OpenSSH 7.9). A sshd that gets a KRL with > unknown entries will refuse *all* keys. > Thanks for the patch, I will test it later. However, I don't quite understand why you need a new KRL section (thus, IMHO unnecessarily, introducing incompatibility). A compatible solution would be to put a truncated SHA256 hash in the existing section, and search for it there. The downside would be that old sshds will not refuse that key, though, and I don't know whether it is acceptable. Anyway, this can only happen if the admin uses new ssh-keygen and copies the result to a server with old sshd. -- Alexander E. Patrakov _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
