[ssh_x509] logging into server without being asked about host key?

[ssh_x509 at roumenpetrov.info]

Hi Kent.

ssh_x509 at roumenpetrov.info wrote:
> On 10/6/12 5:11 AM, ssh_x509 at roumenpetrov.info wrote:
>>
>> Hi Kent.
>>> I think I configured everything correctly but, when logging into a
>>> server, I'm still asked:
>>>
>>> ----BEGIN----
>>> The authenticity of host '[localhost]:8022 ([::1]:8022)' can't be
>>> established.
>>> RSA+cert key fingerprint is
>>> c0:29:82:d8:26:67:94:8e:1c:b3:90:d3:0e:7a:65:ae.
>>> Distinguished name is
>>> 'C=xx,ST=xxxxxxx,L=xxxxxx,O=xxxxxxx,OU=xxxxx,CN=myhost,emailAddress=xxxx at xxxxxx.net'.
>>> Are you sure you want to continue connecting (yes/no)? yes
>>> -----END-----
>>>
>>> Is it expected that a properly configured system would ask this?
>> No except for first time as host key is new, you use configuration
>> with StrictHostKeyChecking set to ask and user known host file does
>> not list "new" host key.
>> Right ?
>
> Sorry, I should have been more clear.  Yes, StrictHostKeyChecking is
> on and I'm only asked the first time.   But I don't want to be asked
> at all.  Instead, I want it to be like with OpenSSH's native
> certificate support, where only the CA's key needs to be in the
> known_hosts file, thus automatically authenticating any SSH server
> presenting a hostkey signed by that CA.

Ok. You wrote "CA's key needs to be in the known_hosts file,"  Note this .


>> But did you change host key is this scenario . I mean you setup
>> systems (host&client), connect to host many times and after this you
>> change host key. What is result ?
> I ask because, using OpenSSH's native certificates, it's possible to
> log into a server without being prompted, so long as the client's
> known_hosts file has the signing CA's info listed (i.e.
> @cert-authority *.bar.com ssh-rsa AAAAB3[...]== Comment) and the
> principles in the server's cert match the IP/FQDN that the connection
> was to...

So openssh custom certificates use user known host to store information 
-  why sign and what is authorized/signed.


> It does not matter if the host key changes, so long as the new host
> key is signed by the CA my client trusts.  Once configured, my client
> doesn't prompt to accept the  hostkey the first time it connects to
> the server or if ever the server's hostkey changes.  In fact, the
> server's hostkey isn't ever stored in the the known_hosts file...

In scenario with X.509 certificate support if you say yes for first time 
what is content of user known file ? Did record contain server 
certificate ? No ! Record contain distinguished name of certificate . 
For instance one of names used in certificate regression test is
localhost x509v3-sign-dss Subject:C=XX,ST=World,O=OpenSSH Test Team 
cyrillic-\D0\90\D0\91\D0\92\D0\93\D0\B0\D0\B1\D0\B2\D0\B3 
greek-\CE\91\CE\92\CE\93\CE\94\CE\B1\CE\B2\CE\B3\CE\B4,OU=OpenSSH 
Testers cyrillic-\D0\90\D0\91\D0\92\D0\93\D0\B0\D0\B1\D0\B2\D0\B3 
greek-\CE\91\CE\92\CE\93\CE\94\CE\B1\CE\B2\CE\B3\CE\B4-2,OU=OpenSSH 
Testers cyrillic-\D0\90\D0\91\D0\92\D0\93\D0\B0\D0\B1\D0\B2\D0\B3 
greek-\CE\91\CE\92\CE\93\CE\94\CE\B1\CE\B2\CE\B3\CE\B4-1,OU=OpenSSH 
Testers cyrillic-\D0\90\D0\91\D0\92\D0\93\D0\B0\D0\B1\D0\B2\D0\B3 
greek-\CE\91\CE\92\CE\93\CE\94\CE\B1\CE\B2\CE\B3\CE\B4-3,CN=localhost 
DSA(rsa_sha1)


Versions since 2002 use this scenario. Sorry I forgot details which 
version (b,c d.. ?) implement this.
For compatibility users are asked to confirm that they would like to 
connect to a host that offer X.509 certificate as server key. And the 
message is same as for normal authentication for public key and 'host' 
in message could be 'host key alias'.
I understand that message confuse you. Actually request is did user 
trust authenticity of this certificate for "hostname" as host name could 
be 'host key alias'.
If user say yes this is registered in know host file as just 
distinguished name(DN) is written.
After this client will continue to connect to "hostname" until DN is 
same. If host X.509 certificate is changed user will continue to logon 
without to be prompted until DN is same.

Next.
Use X.509 require more complex  validation of a server certificate.  One 
of steps is validation of server fully qualified domain name and history 
of RFC for ssh with X.509 certificates.
One of requirement in draft-ietf-secsh-x509-<NN>.txt is to check with 
rules in RFC2818 (HTTP Over TLS) . wow :( .

So if you check test/CA/ directory you will find extra files with name 
testhostkey* . You could setup apache http server to use those 
key&certificate, to add issuer(CA) certificates to browser store and to 
open https://locahost . Lets use gecko based browsers (seamonkey, 
firefox, etc ....
Next add server alias for instance www.example.com and open page 
https://www.example.com . You browser with ask you to trust connection 
and if you add "security exception" page will be opened .
You could check "exceptions" on tab "servers" in certificate management 
screen - permanent vs temporary.


I think that you would like to ask me why is not implement validation of 
server fully qualified domain name or IP address.
Just because it will add extra complexity.


> Thanks,
> Kent


Roumen