Bug 2309 - change default PreferredAuthentications order
Summary: change default PreferredAuthentications order
Status: CLOSED INVALID
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 6.7p1
Hardware: Other All
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-08 10:38 AEDT by Christoph Anton Mitterer
Modified: 2016-08-02 10:40 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2014-11-08 10:38:42 AEDT
Hi.

As far as I understand, one cannot "improve" the security of SSH by disabling auth methods or changing their order... on the client side(!).

- Even if one thinks e.g. password or hostbased are insecure, as long as they're enabled on the server side, one cannot "protect" such server by disabling it on the client side.

- Neither can one improve the security of the one's own current session, since that is already fully set up after the KEX (both plain KEX or GSS KEX) and thus *before* auth takes places.


Right so far?

If so, then the only sense of the default order of auth methods is probably usability, i.e. the less interaction necessary by the user, the better.

The current default is: gssapi-with-mic,hostbased,publickey,keyboard-interactive,password


Which is IMHO already close to perfect:

keyboard-interactive,password come last, since they always require manual user input.

publickey - may or may not require manual input (depending on whether the identity key is encrypted or not), thus it should be before the two with passphrase entry


But then I'd swap gssapi-with-mic with hostbased:
gssapi-with-mic: a krb ticket may not be available, if not the user would need create one first likely requires passphrase input as well,... but they ticket may also be already there (thus no further interaction needed) which is why it should come before pubkey

hostkey: well AFAIU, it either works (if enabled and ssh-keysign is activated) or not. No interaction for the user.


Cheers,
Chris.
Comment 1 Christoph Anton Mitterer 2014-11-08 12:40:55 AEDT
Rethinking that again (which I probably should have done more carefully before) I'll close this as invalid:

Both gssapi-with-mic (and gssapi-keyex) and hostbased won't query the user.

- If a kerberos ticket is there, it will be used if gasapi-with-mic comes first and one doesn't need to interact.
- If no kerberos ticket is there, gssapi-with-mic auth will fail (respectively not tried at all) and ssh will try hostbased auth. Thus no interaction either.

And then I think it's better to prefer the gssapi-* methods over anything else, because if forwarding of credentials is enabled then the user probably wants this, which wouldn't happen if hostbased kicks in before.


Sorry for the noise O:-)
Comment 2 Damien Miller 2016-08-02 10:40:51 AEST
Close all resolved bugs after 7.3p1 release