x509 patch for SSH

Sat Jan 19 03:26:30 EST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roumen,

one last thing, what exactly does MandatoryCRL option sets?

Since when it is set to no, the ssh_crl.pem does get checked whether the
cert is revoked or not.
However, when I set it to yes, I get the following error

I get an error code 3, like this
Jan 17 14:46:12 pingo sshd[25026]: debug3: key_match:found matching
certificate
Jan 17 14:46:12 pingo sshd[25026]: debug1: matching key found: file
/etc/ssh/authorized_keys, line 2
Jan 17 14:46:12 pingo sshd[25026]: Found matching RSA+cert key:
42:1d:66:a3:67:67:e3:82:03:ad:9f:1c:b0:3e:fb:2c
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509cert_check: for
'CN=revoked.arhont.com,OU=IT,O=Arhont Ltd,C=GB'
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Issuer:
CN=Arhont Root CA,O=Arhont Ltd,C=GB
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Subject:
CN=Arhont Root CA,O=Arhont Ltd,C=GB
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_check_crl: Issuer:
CN=Arhont Root CA,O=Arhont Ltd,C=GB; Last Update: Jan 17 13:29:17 2008
GMT; Next Update: Jan 18 13:29:17 2008 GMT
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Issuer:
CN=Arhont Root CA,O=Arhont Ltd,C=GB
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Subject:
CN=revoked.arhont.com,OU=IT,O=Arhont Ltd,C=GB
Jan 17 14:46:12 pingo sshd[25026]: error: ssh_x509revoked_cb: unable to
get issued CRL
Jan 17 14:46:12 pingo sshd[25026]: error: ssh_verify_cert: verify error,
code=3, msg='unable to get certificate CRL'
Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509cert_check: return
- -1(error)
Jan 17 14:46:12 pingo sshd[25026]: x509 certificate check reject
matching key

When I use openssl verify -crl_check everything is fine.

yours,
kos

- -------- Original Message --------
Subject: Re: x509 patch for SSH
From: Roumen Petrov <openssh at roumenpetrov.info>
To: k.gavrilenko at arhont.com
CC: openssh-unix-dev at mindrot.org
Date: Thu Jan 17 2008 20:44:34 GMT+0000 (BST)

> Konstantin V. Gavrilenko wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> - -------- Original Message --------
>> Subject: Re: x509 patch for SSH
>> From: Roumen Petrov <openssh at roumenpetrov.info>
>> To: k.gavrilenko at arhont.com
>> CC: openssh-unix-dev at mindrot.org
>> Date: Wed Jan 16 2008 19:39:22 GMT+0000 (BST)
>>
>>  
>>> Hi Konstantin,
>>>
>>> Please, find answers in quoted text.
>>>
>>>
>>> Konstantin V. Gavrilenko wrote:
>>> Hi guys,
>>>
>>> been trying the x509 patch for ssh from Roumen, it works great.
>>> However, I can't figure out couple of things, and been trying to solve
>>> it for couple of days already.
>>>
>>> I'am using OpenSSH_4.7p1-hpn12v19, OpenSSL 0.9.8g
>>> with 6.1 version of your patch.
>>>
>>> The serverside hostkey is configured correctly, to present
>>> x509v3-sign-rsa
>>>
>>> dynowork / # ssh-keyscan pingo
>>> # pingo SSH-2.0-OpenSSH_4.7p1-hpn12v19
>>> pingo x509v3-sign-rsa Subject:CN=pingo.dmz.arhont.com,OU=IT,O=Arhont
>>> Ltd,C=GB
>>>
>>>
>>> Hoever, in the  situation, when the clients that haven't been patched to
>>> support x509, just could not connect giving the following error:
>>>
>>> no hostkey alg
>>>      
>>>> Correct.
>>>> In sshd_config(HostKey=...) you could list keys from appropriate type.
>>>> Client with x509 support will dive same result if HostKeyAlgorithms is
>>>> set to ssh-rsa,ssh-dss in ~/.ssh/config for that host.
>>>>       
>>
>> Roumen, thanks for the help.
>> I guess I was under assumption that by default all four methods are
>> enabled on the client side, and it will try all of the supported
>> advertised by the server. In my case, x509v3-rsa and ssh-dss, rather
>> then quiting after the first incapable one.
>>   
> Yes, by default client/server send list with all supported key in order
> of preference.
> From OpenSSH server side list depend of host-keys set by sshd_config and
> loaded.
> 
> About "try all of the supported" - No, please read standard - RFC4253
> "The Secure Shell (SSH) Transport Layer Protocol",
> 
> 7.1. Algorithm Negotiation, server_host_key_algorithms:
> The first algorithm on the client's name-list
> that satisfies the requirements and is also supported by the
> server MUST be chosen. If there is no such algorithm, both
> sides MUST disconnect.
> 
> 
>>> Is it possible to circumvent this apart from also specifying the dss
>>> key, that non-patched clients would understand.
>>>
>>>
>>> The second problem is with clients that are patched, but for one reason
>>> or another there is no x509 store setup on the client.
>>>      
>>>> So in this case client could not create trusted certificate chain and
>>>> verification will reject give certificate.
>>>> That is part of PKI and you could test what is result with openssl
>>>> verify ... without trusted certificates.
>>>>       
>>
>> Yes, I understand that it will break the verification check and result
>> in error 20, that is due to the openssl verify behavior.
>>   
> Not openssl, it is PKI requirement.
> 
> 
>>> They just give out the following error:
>>>
>>> ssh_x509store_cb: subject='CN=pingo.dmz.arhont.com,OU=IT,O=Arhont
>>> Ltd,C=GB', error 20 at 0 depth lookup:unable to get local issuer
>>> certificate
>>> ssh_verify_cert: verify error, code=20, msg='unable to get local issuer
>>> certificate'
>>> key_verify failed for server_host_key
>>>
>>>
>>> Is it possible to have a situation when if there is no x509 store set up
>>> on the client, it would simply revert to the password based
>>> authentication?
>>>      
>>>> In reported case client could not trust host key as result will reject
>>>> to continue.
>>>> But you could switch to rsa/dss host-keys (HostKeyAlgorithms
>>>> ssh-rsa,ssh-dss) for that host and then to set order of authentication
>>>> methods in PreferredAuthentications.
>>>>       
>>
>> The funny thing is that when I remove the ssh_ca.pem on the client, this
>> gives out the error 20. Then I set the "HostKeyAlgorithms ssh-dss", it
>> works and allows for a passwordless login using the client cert
>> (providing the client cert is mentioned in the AuthorisedKeyFile)
>> I guess it is a workaround, but can also be considered to be a bug
>>   
> See above (rfc4253...). Don't miss server host-keys and user identities.
> 
> 
> [SNIP]
> Roumen
> 
> 

- --
Respectfully,
Konstantin V. Gavrilenko

Arhont Ltd - Information Security

web:    http://www.arhont.com
        http://www.wi-foo.com
e-mail: k.gavrilenko at arhont.com

tel: +44 (0) 870 44 31337
fax: +44 (0) 117 969 0141

PGP: Key ID - 0xE81824F4
PGP: Server - keyserver.pgp.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHkNM1xwtGg+gYJPQRAuaqAJ4o7ye9JnoNiCNfM1Vf9cJ07uZLRgCeOTZg
ZIJ6SHEzyElGgBsaX2GZzf4=
=Xb0F
-----END PGP SIGNATURE-----