On 2014-10-19, Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx> wrote: >> https://tools.ietf.org/html/rfc4253#section-8 > So it's basically the signature s over H, which includes amongst others > K from the server. > Why is there never a step, in which the server S somehow verifies that e > actually comes from C (i.e. authenticating C)? That's just the overall protocol design. There is no client authentication at this stage, only server authentication. Client authentication happens in the SSH authentication protocol https://tools.ietf.org/html/rfc4252 Typical client authentication relies on the user's public key or password. What would be gained by authenticating the client's host? >> https://tools.ietf.org/html/rfc4419 > > So with DH group exchange, I have no way to tell the client to only > accept larger groups, or is there any configuration option where I can > say, e.g. minimal=4096 or whatever? No. > Wouldn't it be nice to have an option to set min/pref/max? No. > And it basically also means, the client checks just for the group > size,... and has no way to accept/reject certain moduli? > Now for ECDH, we know that some curves may be insecure,... is the same > known for DH? I.e. could a server accidentally propose the client an > insecure moduli (which the client takes without any check except for the > group size)? What is your attack scenario here? If the server can't be trusted, your session isn't protected. That is trivial. Hey, the server might accidentally use a weak random number generator. That isn't even hypothetical. -- Christian "naddy" Weisgerber naddy@xxxxxxxxxxxx _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
