Konstantin V. Gavrilenko wrote:
> Hash: SHA1
> - -------- Original Message --------
> Subject: Re: x509 patch for SSH
> From: Roumen Petrov
> To: k.gavrilenko@arhont.com
> CC: openssh-unix-dev@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.


Get X.509 certificates support in OpenSSH:

openssh-unix-dev mailing list