This is a discussion on Re: x509 patch for SSH within the OpenSSH Development forums, part of the Networking and Network Related category; Konstantin V. Gavrilenko wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -------- Original Message -------- > Subject: Re: x509 ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Konstantin V. Gavrilenko wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -------- Original Message -------- > Subject: Re: x509 patch for SSH > From: Roumen Petrov <openssh@roumenpetrov.info> > 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. [SNIP] Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org https://lists.mindrot.org/mailman/li...enssh-unix-dev |