x509 patch for SSH

[Roumen Petrov]

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


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/