Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Tue, 5/22/12, Ian Lepore wrote:
> Seeing your example config with the commented-out HostKey
> lines made me
> realize that you probably want to have two HostKey lines,
> one for the
> protocol v1 key and another for the dsa key for v2.
> The 6.x server
> added the v1 key and the v2 dsa key by default, so you could
> have
> existing clients relying on a v1 key. Since you now
> have a HostKey
> statement the new server code won't add the v1 key by
> default so you'd
> need to be explicit about it.
>
> Based on examining the code, I think this will be safe
> because the keys
> have different type-names ("rsa1" vs "rsa") so a client
> wanting to use a
> protocol v2 rsa key won't accidentally match the protcol v1
> rsa key
> named in the config file (and it will still match the dsa
> key).
Well, yes - and after restarting sshd, this was made clear:
Stopping sshd.
Starting sshd.
Disabling protocol version 1. Could not load host key
However, those commented out HostKey lines were always commented out - I did
not comment them out. In fact, my change was to uncomment the last one.
Further, I think the:
/etc/ssh/ssh_host_key
key, for protocol v1, is an RSA key, right ? But you are saying it's an older
rsa1 key ?
Ok, I will uncomment both lines now, and it will read:
# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_dsa_key
I just tried it and it seems to work (no scary key mismatch messages for DSA
clients)
Thanks.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Tue, 2012-05-22 at 09:59 -0700, Jason Usher wrote:
> Hi Ian,
>
> Thank you very much for taking a look at this, and for understanding what I'm
> talking about here.
>
> Comments inline, below...
>
>
> --- On Tue, 5/22/12, Ian Lepore wrote:
>
> > >
> > > >But have you tried it in this order
> > ?
> > > >
> > > >HostKey
> > /usr/local/etc/ssh/ssh_host_key
> > > >HostKey
> > > > /usr/local/etc/ssh/ssh_host_dsa_key
> > > >HostKey
> > > > /usr/local/etc/ssh/ssh_host_rsa_key
> > > >HostKey
> > > > /usr/local/etc/ssh/ssh_host_ecdsa_key
> > > >
> > > > Which is to say, have your sshd_config file list
> > multiple
> > > > hostkey's, and then restart sshd after making that
> > change?
> > > > I tried a similar change and it seemed to have
> > some effect
> > > > on what clients saw when connecting, but I can't
> > tell if
> > > > it has the effect that you want.
> > >
> > >
> > > The order of HostKey directives in sshd_config does not
> > change the actual order. In newer implementations, RSA
> > is provided first, no matter how you configure the
> > sshd_config.
> > >
> > > As I mentioned before, removing RSA completely is sort
> > of a fix, but I can't do that because some people might
> > actually be explicitly using RSA, and they would all break.
> > >
> > > Anyone ?
> >
> > After poking through the sshd code a bit, it looks to me
> > like this is
> > working as designed and it's the clients that are
> > broken. For host key
> > algorithm, and other things where both the server and the
> > client side
> > have a list of possibilities and have to agree on a match
> > from those
> > lists, the client side is completely in control of
> > precedence, by
> > design.
>
>
> OK. That's bad news, as I have no influence on the clients at all.
>
>
>
> > In your case it appears that the client sends "rsa,dsa" as
> > the host key
> > algorithm list. The server has
> > "dsa,rsa,maybe,other,stuff" and since
> > rsa is the client's first choice and exists in the server
> > list, it gets
> > used. Then the client rejects the rsa key because it
> > was really only
> > ever going to be happy with a dsa key. IMO, this is a
> > client-side bug;
> > if it's only going to accept dsa (because that's the only
> > thing in the
> > known_hosts file) then it should only ask for that.
>
>
> Exactly. It would be nice if the client at least tried the other algorithm
> to see if that does indeed match up with the public key it is sitting on ...
> breaking automation out in the field is really problematic.
>
>
>
> > 1) Only offer a dsa key. It appears the right way to
> > do this would be
> > to have just one HostKey statement in the sshd config file
> > that names
> > your dsa key file. The presence of at least one
> > HostKey statement will
> > prevent the code from adding the default keyfile names
> > internally, so
> > you should end up with only a dsa key being offered.
>
>
> Ok, I did this - I explicitly defined a HostKey in sshd_config that happens
> to be my DSA key:
>
> #HostKey for protocol version 1
> #HostKey /etc/ssh/ssh_host_key
> #HostKeys for protocol version 2
> HostKey /etc/ssh/ssh_host_dsa_key
>
> (note the last line is uncommented)
>
> and sshd does indeed just present the DSA key (to clients that were
> previously negotiating the RSA key, after the upgrade).
>
> So this is great... I was originally wary of forcing DSA only like this,
> since there might be clients out in the world that had somehow negotiated an
> RSA key, but based on your further comments, it sounds like that is not the
> case.
>
> So if everyone has DSA keys (we'll find out ...) then we are all set.
>
> Thank you very much for examining this issue - I hope the archives of this
> conversation will help others in the future.
Seeing your example config with the commented-out HostKey lines made me
realize that you probably want to have two HostKey lines, one for the
protocol v1 key and another for the dsa key for v2. The 6.x server
added the v1 key and the v2 dsa key by default, so you could have
existing clients relying on a v1 key. Since you now have a HostKey
statement the new server code won't add the v1 key by default so you'd
need to be explicit about it.
Based on examining the code, I think this will be safe because the keys
have different type-names ("rsa1" vs "rsa") so a client wanting to use a
protocol v2 rsa key won't accidentally match the protcol v1 rsa key
named in the config file (and it will still match the dsa key).
-- Ian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
Hi Ian, Thank you very much for taking a look at this, and for understanding what I'm talking about here. Comments inline, below... --- On Tue, 5/22/12, Ian Lepore wrote: > > > > > But have you tried it in this order > ? > > > > > > HostKey > /usr/local/etc/ssh/ssh_host_key > > > HostKey > > > /usr/local/etc/ssh/ssh_host_dsa_key > > > HostKey > > > /usr/local/etc/ssh/ssh_host_rsa_key > > > HostKey > > > /usr/local/etc/ssh/ssh_host_ecdsa_key > > > > > > Which is to say, have your sshd_config file list > multiple > > > hostkey's, and then restart sshd after making that > change? > > > I tried a similar change and it seemed to have > some effect > > > on what clients saw when connecting, but I can't > tell if > > > it has the effect that you want. > > > > > > The order of HostKey directives in sshd_config does not > change the actual order. In newer implementations, RSA > is provided first, no matter how you configure the > sshd_config. > > > > As I mentioned before, removing RSA completely is sort > of a fix, but I can't do that because some people might > actually be explicitly using RSA, and they would all break. > > > > Anyone ? > > After poking through the sshd code a bit, it looks to me > like this is > working as designed and it's the clients that are > broken. For host key > algorithm, and other things where both the server and the > client side > have a list of possibilities and have to agree on a match > from those > lists, the client side is completely in control of > precedence, by > design. OK. That's bad news, as I have no influence on the clients at all. > In your case it appears that the client sends "rsa,dsa" as > the host key > algorithm list. The server has > "dsa,rsa,maybe,other,stuff" and since > rsa is the client's first choice and exists in the server > list, it gets > used. Then the client rejects the rsa key because it > was really only > ever going to be happy with a dsa key. IMO, this is a > client-side bug; > if it's only going to accept dsa (because that's the only > thing in the > known_hosts file) then it should only ask for that. Exactly. It would be nice if the client at least tried the other algorithm to see if that does indeed match up with the public key it is sitting on ... breaking automation out in the field is really problematic. > 1) Only offer a dsa key. It appears the right way to > do this would be > to have just one HostKey statement in the sshd config file > that names > your dsa key file. The presence of at least one > HostKey statement will > prevent the code from adding the default keyfile names > internally, so > you should end up with only a dsa key being offered. Ok, I did this - I explicitly defined a HostKey in sshd_config that happens to be my DSA key: #HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key #HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_dsa_key (note the last line is uncommented) and sshd does indeed just present the DSA key (to clients that were previously negotiating the RSA key, after the upgrade). So this is great... I was originally wary of forcing DSA only like this, since there might be clients out in the world that had somehow negotiated an RSA key, but based on your further comments, it sounds like that is not the case. So if everyone has DSA keys (we'll find out ...) then we are all set. Thank you very much for examining this issue - I hope the archives of this conversation will help others in the future. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Mon, 2012-05-21 at 14:26 -0700, Jason Usher wrote:
>
> --- On Mon, 5/21/12, Garance A Drosehn wrote:
>
> >But have you tried it in this order ?
> >
> >HostKey /usr/local/etc/ssh/ssh_host_key
> >HostKey
> > /usr/local/etc/ssh/ssh_host_dsa_key
> >HostKey
> > /usr/local/etc/ssh/ssh_host_rsa_key
> >HostKey
> > /usr/local/etc/ssh/ssh_host_ecdsa_key
> >
> > Which is to say, have your sshd_config file list multiple
> > hostkey's, and then restart sshd after making that change?
> > I tried a similar change and it seemed to have some effect
> > on what clients saw when connecting, but I can't tell if
> > it has the effect that you want.
>
>
> The order of HostKey directives in sshd_config does not change the actual
> order. In newer implementations, RSA is provided first, no matter how you
> configure the sshd_config.
>
> As I mentioned before, removing RSA completely is sort of a fix, but I can't
> do that because some people might actually be explicitly using RSA, and they
> would all break.
>
> Anyone ?
After poking through the sshd code a bit, it looks to me like this is
working as designed and it's the clients that are broken. For host key
algorithm, and other things where both the server and the client side
have a list of possibilities and have to agree on a match from those
lists, the client side is completely in control of precedence, by
design.
The server has a list of things it can support, A,B,C,D. The client
sends a list of things it desires, in order of preference, D,A,C. The
server chooses a match as follows:
for each client list item
for each server list item
if current-client-item matches current-server-item
return current-client-item as the match
end if
end for
end for
In your case it appears that the client sends "rsa,dsa" as the host key
algorithm list. The server has "dsa,rsa,maybe,other,stuff" and since
rsa is the client's first choice and exists in the server list, it gets
used. Then the client rejects the rsa key because it was really only
ever going to be happy with a dsa key. IMO, this is a client-side bug;
if it's only going to accept dsa (because that's the only thing in the
known_hosts file) then it should only ask for that.
So I think you have two choices...
1) Only offer a dsa key. It appears the right way to do this would be
to have just one HostKey statement in the sshd config file that names
your dsa key file. The presence of at least one HostKey statement will
prevent the code from adding the default keyfile names internally, so
you should end up with only a dsa key being offered.
2) Try the attached patch to violate the design and force the server's
configuration order to override the precedence implied by the client's
request list. Put HostKey statements the sshd_config file in the order
you want enforced.
I don't think #2 is a good option, but I know how it is in a production
world... sometimes you've got to do things that you know are bad to keep
the show running. Hopefully when you do such things it's just to buy
some time to deploy a better fix (but it doesn't always work out that
way; I still maintain horrible "temporary" hacks like this from years
and years ago).
Maybe option 1 would work okay for you in light of this info: When I
look in the openssh source from freebsd 6.4, it appears that while an
rsa hostkey was supported, it would not be added to the server config by
default; it would only be used if you specifically configured it with a
HostKey statement in sshd_config. So maybe you can safely assume that
nobody was ever connecting to your freebsd 6.x machines using an rsa
hostkey.
Now for The Big Caveat: All of the above is based on code inspection.
I haven't tested anything, including the attached patch.
-- Ian
Index: crypto/openssh/kex.c
===
--- crypto/openssh/kex.c (revision 235554)
+++ crypto/openssh/kex.c (working copy)
@@ -371,7 +371,7 @@
static void
choose_hostkeyalg(Kex *k, char *client, char *server)
{
- char *hostkeyalg = match_list(client, server, NULL);
+ char *hostkeyalg = match_list(server, client, NULL);
if (hostkeyalg == NULL)
fatal("no hostkey alg");
k->hostkey_type = key_type_from_name(hostkeyalg);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Mon, May 21, 2012 at 02:26:27PM -0700, Jason Usher wrote: > > > --- On Mon, 5/21/12, Garance A Drosehn wrote: > > > ???But have you tried it in this order ? > > > > ???HostKey /usr/local/etc/ssh/ssh_host_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_dsa_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_rsa_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_ecdsa_key > > > > Which is to say, have your sshd_config file list multiple > > hostkey's, and then restart sshd after making that change? > > I tried a similar change and it seemed to have some effect > > on what clients saw when connecting, but I can't tell if > > it has the effect that you want. > > > The order of HostKey directives in sshd_config does not change the actual > order. In newer implementations, RSA is provided first, no matter how you > configure the sshd_config. > > As I mentioned before, removing RSA completely is sort of a fix, but I can't > do that because some people might actually be explicitly using RSA, and they > would all break. > > Anyone ? The problem to me seems to be on the client end. Where the new ssh installation is attempting RSA authentication first rather than DSA and your ssh server has just now caught up to the clients. If I were you, I would just make an announcement providing the host fingerprints to clients and asking them to update known_hosts appropriately, rather than creating a virtual fix for sshd that you will have to maintain yourself. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Mon, 5/21/12, Garance A Drosehn wrote: > But have you tried it in this order ? > > HostKey /usr/local/etc/ssh/ssh_host_key > HostKey > /usr/local/etc/ssh/ssh_host_dsa_key > HostKey > /usr/local/etc/ssh/ssh_host_rsa_key > HostKey > /usr/local/etc/ssh/ssh_host_ecdsa_key > > Which is to say, have your sshd_config file list multiple > hostkey's, and then restart sshd after making that change? > I tried a similar change and it seemed to have some effect > on what clients saw when connecting, but I can't tell if > it has the effect that you want. The order of HostKey directives in sshd_config does not change the actual order. In newer implementations, RSA is provided first, no matter how you configure the sshd_config. As I mentioned before, removing RSA completely is sort of a fix, but I can't do that because some people might actually be explicitly using RSA, and they would all break. Anyone ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
I may have missed some emails in this thread, but did you try this suggestion: But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Which is to say, have your sshd_config file list multiple hostkey's, and then restart sshd after making that change? I tried a similar change and it seemed to have some effect on what clients saw when connecting, but I can't tell if it has the effect that you want. -- garance On 5/21/12 12:18 PM, Jason Usher wrote: Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting "rsa, then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Mon, May 21, 2012 at 09:18:32AM -0700, Jason Usher wrote: > > Folks, > > Is there a better list for this - perhaps freebsd-security ? > > I originally posted to -hackers because it *appears* that reverting "rsa, > then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since > that doesn't work, and since I haven't gotten any replies here ... > > Thoughts ? OpenBSD ? http://www.openssh.org/list.html > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > > > I have some old 6.x FreeBSD systems that need > > their > > > > OpenSSH upgraded. > > > > > > > > > > Everything goes just fine, but when I am > > done, existing > > > > clients are now presented with this message: > > > > > > > > > > > > > > > WARNING: DSA key found for host hostname > > > > > in /root/.ssh/known_hosts:12 > > > > > DSA key fingerprint > > 4c:29:4b:6e:b8:6b:fa:49... > > > > > > > > > > The authenticity of host 'hostname > > (10.1.2.3)' can't be > > > > established > > > > > but keys of different type are already known > > for this > > > > host. > > > > > RSA key fingerprint is > > a3:22:3d:cf:f2:46:09:f2.. > > > > > Are you sure you want to continue connecting > > (yes/no) > > > > > > > > > > > > > You must be using different keys for your server > > than the > > > > one that has > > > > been generated before the upgrade. Just copy your > > keys over > > > > to the new > > > > location and restart the server daemon and you > > should be > > > > fine. > > > > > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > > > > > > > You didn't read that error message. > > > > Sorry I misread that. Decieving message... > > > > > > > > That is not the standard "key mismatch" error that you > > assumed it was. Look at it again - it is saying that > > we do have a key for this server of type DSA, but the client > > is receiving one of type RSA, etc. > > > > > > The keys are the same - they have not changed at all - > > they are just being presented to clients in the reverse > > order, which is confusing them and breaking automated, > > key-based login. > > > > > > I need to take current ssh server behavior (rsa, then > > dss) and change it back to the old order (dss, then rsa). > > > > Have you attempted to change that order via sshd_config and > > placing the > > DSA directive before the RSA one ? > > > > > > -- > > > > - (2^(N-1)) > > -- - (2^(N-1)) pgpwYbPqW1wk8.pgp Description: PGP signature
Re: Need to revert behavior of OpenSSH to the old key order ...
Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting "rsa, then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > I have some old 6.x FreeBSD systems that need > their > > > OpenSSH upgraded. > > > > > > > > Everything goes just fine, but when I am > done, existing > > > clients are now presented with this message: > > > > > > > > > > > > WARNING: DSA key found for host hostname > > > > in /root/.ssh/known_hosts:12 > > > > DSA key fingerprint > 4c:29:4b:6e:b8:6b:fa:49... > > > > > > > > The authenticity of host 'hostname > (10.1.2.3)' can't be > > > established > > > > but keys of different type are already known > for this > > > host. > > > > RSA key fingerprint is > a3:22:3d:cf:f2:46:09:f2.. > > > > Are you sure you want to continue connecting > (yes/no) > > > > > > > > > > You must be using different keys for your server > than the > > > one that has > > > been generated before the upgrade. Just copy your > keys over > > > to the new > > > location and restart the server daemon and you > should be > > > fine. > > > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > > > > You didn't read that error message. > > Sorry I misread that. Decieving message... > > > > > That is not the standard "key mismatch" error that you > assumed it was. Look at it again - it is saying that > we do have a key for this server of type DSA, but the client > is receiving one of type RSA, etc. > > > > The keys are the same - they have not changed at all - > they are just being presented to clients in the reverse > order, which is confusing them and breaking automated, > key-based login. > > > > I need to take current ssh server behavior (rsa, then > dss) and change it back to the old order (dss, then rsa). > > Have you attempted to change that order via sshd_config and > placing the > DSA directive before the RSA one ? > > > -- > > - (2^(N-1)) > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Fri, May 18, 2012 at 01:58:01PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher > > wrote: > > > > > > > > > --- On Thu, 5/17/12, Jason Hellenthal > > wrote: > > > > > > > > That is not the standard "key mismatch" error > > that you > > > > assumed it was.? Look at it again - it is saying > > that > > > > we do have a key for this server of type DSA, but > > the client > > > > is receiving one of type RSA, etc. > > > > > > > > > > The keys are the same - they have not changed > > at all - > > > > they are just being presented to clients in the > > reverse > > > > order, which is confusing them and breaking > > automated, > > > > key-based login. > > > > > > > > > > I need to take current ssh server behavior > > (rsa, then > > > > dss) and change it back to the old order (dss, > > then rsa). > > > > > > > > Have you attempted to change that order via > > sshd_config and > > > > placing the > > > > DSA directive before the RSA one ? > > > > > > > > > sshd_config has no such config directive.? > > ssh_config does, but that's for clients, and I have no way > > to interact with the clients. > > > > > > It would indeed be very nice if this key order, which > > seems like a prime candidate for configuration, was a > > configurable option in sshd_config, but it is not. > > > > > > I am fairly certain that I need to hack up some source > > files, and I thought I had it with myproposal.h (see link in > > OP) but there must be more, because that small change does > > not fix things... > > > > You don't have any of this in your config ? > > > > # HostKey for protocol version 1 > > #HostKey /usr/local/etc/ssh/ssh_host_key > > # HostKeys for protocol version 2 > > HostKey /usr/local/etc/ssh/ssh_host_rsa_key > > #HostKey /usr/local/etc/ssh/ssh_host_dsa_key > > #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key > > > Yes, but that doesn't help, for reasons I mentioned earlier. > > Simply removing RSA functionality would (of course) cause it to stop > presenting RSA keys first, but what about clients who (for whatever reason, > who knows) negotiated RSA keys previously ? Then they would break. > > This is a very simple requirement: > > OpenSSH server used to present keys in the order: DSA first, then RSA. I > need to get back to that same behavior. > > How do I do that ? Not sure if you missed what I was saying or if I read that correctly. But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key ??? Just for brevity. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Jason Hellenthal wrote: > On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher > wrote: > > > > > > --- On Thu, 5/17/12, Jason Hellenthal > wrote: > > > > > > That is not the standard "key mismatch" error > that you > > > assumed it was.? Look at it again - it is saying > that > > > we do have a key for this server of type DSA, but > the client > > > is receiving one of type RSA, etc. > > > > > > > > The keys are the same - they have not changed > at all - > > > they are just being presented to clients in the > reverse > > > order, which is confusing them and breaking > automated, > > > key-based login. > > > > > > > > I need to take current ssh server behavior > (rsa, then > > > dss) and change it back to the old order (dss, > then rsa). > > > > > > Have you attempted to change that order via > sshd_config and > > > placing the > > > DSA directive before the RSA one ? > > > > > > sshd_config has no such config directive. > ssh_config does, but that's for clients, and I have no way > to interact with the clients. > > > > It would indeed be very nice if this key order, which > seems like a prime candidate for configuration, was a > configurable option in sshd_config, but it is not. > > > > I am fairly certain that I need to hack up some source > files, and I thought I had it with myproposal.h (see link in > OP) but there must be more, because that small change does > not fix things... > > You don't have any of this in your config ? > > # HostKey for protocol version 1 > #HostKey /usr/local/etc/ssh/ssh_host_key > # HostKeys for protocol version 2 > HostKey /usr/local/etc/ssh/ssh_host_rsa_key > #HostKey /usr/local/etc/ssh/ssh_host_dsa_key > #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Yes, but that doesn't help, for reasons I mentioned earlier. Simply removing RSA functionality would (of course) cause it to stop presenting RSA keys first, but what about clients who (for whatever reason, who knows) negotiated RSA keys previously ? Then they would break. This is a very simple requirement: OpenSSH server used to present keys in the order: DSA first, then RSA. I need to get back to that same behavior. How do I do that ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Jason Hellenthal wrote: > > That is not the standard "key mismatch" error that you > assumed it was. Look at it again - it is saying that > we do have a key for this server of type DSA, but the client > is receiving one of type RSA, etc. > > > > The keys are the same - they have not changed at all - > they are just being presented to clients in the reverse > order, which is confusing them and breaking automated, > key-based login. > > > > I need to take current ssh server behavior (rsa, then > dss) and change it back to the old order (dss, then rsa). > > Have you attempted to change that order via sshd_config and > placing the > DSA directive before the RSA one ? sshd_config has no such config directive. ssh_config does, but that's for clients, and I have no way to interact with the clients. It would indeed be very nice if this key order, which seems like a prime candidate for configuration, was a configurable option in sshd_config, but it is not. I am fairly certain that I need to hack up some source files, and I thought I had it with myproposal.h (see link in OP) but there must be more, because that small change does not fix things... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Garrett Cooper wrote: > > ... but I'm afraid that changing that line in > myproposal.h BACK TO ssh-dss,ssh-rsa does not solve the > problem. I did indeed make that change to > myproposal.h, manually, and then build the openssh-portable > port, but the behavior persists. > > > > If I simply REMOVE the RSA keys, the error goes away, > and existing DSA-using clients no longer bomb out, but this > is NOT a good solution for two reasons: > > > > 1. anytime I HUP, or start sshd, it's going to create > new RSA keys for me > > > > 2. It's possible that some clients out there really > have been using RSA all along (who knows) and now they are > completely broken, since RSA is not there at all. > > > > I'm more than happy to muck around in the source with > further little edits, just like I did with myproposal.h, but > I have no idea what they would be. > > > > Can anyone help me "make new ssh behave like old one" > ? > > You can probably issue an option via -o with ssh to skip the > prompt (see ssh_config… maybe there's something in there > that can help you). No, I'm not referring to > StrictHostKeyChecking either :). That's on the client side. I don't have access to the clients. I have no way to interact with the clients at all. I need a way to configure (or patch) the OpenSSH server such that it presents keys in the same order (first DSS, then RSA) as it used to. Anyone ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Jason Hellenthal wrote: > On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher > wrote: > > I have some old 6.x FreeBSD systems that need their > OpenSSH upgraded. > > > > Everything goes just fine, but when I am done, existing > clients are now presented with this message: > > > > > > WARNING: DSA key found for host hostname > > in /root/.ssh/known_hosts:12 > > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... > > > > The authenticity of host 'hostname (10.1.2.3)' can't be > established > > but keys of different type are already known for this > host. > > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. > > Are you sure you want to continue connecting (yes/no) > > > > You must be using different keys for your server than the > one that has > been generated before the upgrade. Just copy your keys over > to the new > location and restart the server daemon and you should be > fine. > > copy /etc/ssh/* -> /usr/local/etc/ssh/ You didn't read that error message. That is not the standard "key mismatch" error that you assumed it was. Look at it again - it is saying that we do have a key for this server of type DSA, but the client is receiving one of type RSA, etc. The keys are the same - they have not changed at all - they are just being presented to clients in the reverse order, which is confusing them and breaking automated, key-based login. I need to take current ssh server behavior (rsa, then dss) and change it back to the old order (dss, then rsa). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > That is not the standard "key mismatch" error that you > > assumed it was.? Look at it again - it is saying that > > we do have a key for this server of type DSA, but the client > > is receiving one of type RSA, etc. > > > > > > The keys are the same - they have not changed at all - > > they are just being presented to clients in the reverse > > order, which is confusing them and breaking automated, > > key-based login. > > > > > > I need to take current ssh server behavior (rsa, then > > dss) and change it back to the old order (dss, then rsa). > > > > Have you attempted to change that order via sshd_config and > > placing the > > DSA directive before the RSA one ? > > > sshd_config has no such config directive. ssh_config does, but that's for > clients, and I have no way to interact with the clients. > > It would indeed be very nice if this key order, which seems like a prime > candidate for configuration, was a configurable option in sshd_config, but it > is not. > > I am fairly certain that I need to hack up some source files, and I thought I > had it with myproposal.h (see link in OP) but there must be more, because > that small change does not fix things... You don't have any of this in your config ? # HostKey for protocol version 1 #HostKey /usr/local/etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh/ssh_host_rsa_key #HostKey /usr/local/etc/ssh/ssh_host_dsa_key #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Thu, May 17, 2012 at 04:06:11PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher > > wrote: > > > I have some old 6.x FreeBSD systems that need their > > OpenSSH upgraded. > > > > > > Everything goes just fine, but when I am done, existing > > clients are now presented with this message: > > > > > > > > > WARNING: DSA key found for host hostname > > > in /root/.ssh/known_hosts:12 > > > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... > > > > > > The authenticity of host 'hostname (10.1.2.3)' can't be > > established > > > but keys of different type are already known for this > > host. > > > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. > > > Are you sure you want to continue connecting (yes/no) > > > > > > > You must be using different keys for your server than the > > one that has > > been generated before the upgrade. Just copy your keys over > > to the new > > location and restart the server daemon and you should be > > fine. > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > You didn't read that error message. Sorry I misread that. Decieving message... > > That is not the standard "key mismatch" error that you assumed it was. Look > at it again - it is saying that we do have a key for this server of type DSA, > but the client is receiving one of type RSA, etc. > > The keys are the same - they have not changed at all - they are just being > presented to clients in the reverse order, which is confusing them and > breaking automated, key-based login. > > I need to take current ssh server behavior (rsa, then dss) and change it back > to the old order (dss, then rsa). Have you attempted to change that order via sshd_config and placing the DSA directive before the RSA one ? -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher wrote: > I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. > > Everything goes just fine, but when I am done, existing clients are now > presented with this message: > > > WARNING: DSA key found for host hostname > in /root/.ssh/known_hosts:12 > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... > > The authenticity of host 'hostname (10.1.2.3)' can't be established > but keys of different type are already known for this host. > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. > Are you sure you want to continue connecting (yes/no) > You must be using different keys for your server than the one that has been generated before the upgrade. Just copy your keys over to the new location and restart the server daemon and you should be fine. copy /etc/ssh/* -> /usr/local/etc/ssh/ > > And as you can imagine, existing automated jobs now all fail. > > I have no control over the clients.? Assume the clients cannot be touched at > all. > > So, the good news is, this appears to have been discussed/documented here: > > http://www.mail-archive.com/bugs@crater.dragonflybsd.org/msg04860.html > > ... but I'm afraid that changing that line in myproposal.h BACK TO > ssh-dss,ssh-rsa does not solve the problem.? I did indeed make that change to > myproposal.h, manually, and then build the openssh-portable port, but the > behavior persists. > > If I simply REMOVE the RSA keys, the error goes away, and existing DSA-using > clients no longer bomb out, but this is NOT a good solution for two reasons: > > 1. anytime I HUP, or start sshd, it's going to create new RSA keys for me > > 2. It's possible that some clients out there really have been using RSA all > along (who knows) and now they are completely broken, since RSA is not there > at all. > > I'm more than happy to muck around in the source with further little edits, > just like I did with myproposal.h, but I have no idea what they would be. > > Can anyone help me "make new ssh behave like old one" ? > > Thanks. > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- - (2^(N-1)) pgphZW36vGlU7.pgp Description: PGP signature
Need to revert behavior of OpenSSH to the old key order ...
I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. Everything goes just fine, but when I am done, existing clients are now presented with this message: WARNING: DSA key found for host hostname in /root/.ssh/known_hosts:12 DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... The authenticity of host 'hostname (10.1.2.3)' can't be established but keys of different type are already known for this host. RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. Are you sure you want to continue connecting (yes/no) And as you can imagine, existing automated jobs now all fail. I have no control over the clients. Assume the clients cannot be touched at all. So, the good news is, this appears to have been discussed/documented here: http://www.mail-archive.com/bugs@crater.dragonflybsd.org/msg04860.html ... but I'm afraid that changing that line in myproposal.h BACK TO ssh-dss,ssh-rsa does not solve the problem. I did indeed make that change to myproposal.h, manually, and then build the openssh-portable port, but the behavior persists. If I simply REMOVE the RSA keys, the error goes away, and existing DSA-using clients no longer bomb out, but this is NOT a good solution for two reasons: 1. anytime I HUP, or start sshd, it's going to create new RSA keys for me 2. It's possible that some clients out there really have been using RSA all along (who knows) and now they are completely broken, since RSA is not there at all. I'm more than happy to muck around in the source with further little edits, just like I did with myproposal.h, but I have no idea what they would be. Can anyone help me "make new ssh behave like old one" ? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
