https://bugzilla.mindrot.org/show_bug.cgi?id=1733
--- Comment #17 from Philip Prindeville <[email protected]> --- (In reply to comment #16) > You're confusing the settings for the daemon (sshd_config, which > obviously only root should be able to change) with the settings for the > client (ssh_config) when someone makes an outbound connection. I'm not confusing them at all, and if you reread my comments you'll see that I explicitly said "make the compelling argument to me that users should be allowed to have their own .sshd_config file". Not sure what was unclear about that. Moving on... > The settings for the daemon can't be bypassed since obviously it > requires root privileges to launch it to listen on port 22. Or you could read all users' settings and just use the most permissive of the union... Or individual users could run their own instances on ports other than 22... since your argument was that users could have their own binary clients, I'm saying why not take it a step further and have them run their own servers... > The settings for the client should be freely settable by the user, just > as it is with the -S option for telnet. I have no problems with having > smart defaults in ssh_config, but they definitely should be able to be > overridden. You're missing the point that this is largely IRRELEVANT. The network doesn't care if the client or the server is sending mislabeled packets, they both have exactly the same potential to be disruptive to other traffic types like VoIP and IPTV. I would make the argument that letting the user (and client) set the encryption algorithm, cipher strength, etc. was a serious mistake. If the user uses too weak an encryption standard, his connection can be eavesdropped or even subverted. > In the end, there's no sense having a setting which provides no > security whatsoever (but looks like it does). If a user is malicious, > they can compile their own ssh client with the settings they want and > bypass your config anyways. Since the kernel doesn't enforce any > privileges on the setting of the DSCP markings, you shouldn't either. > Thus it only makes sense to provide a configurable default. Did you read comment #9? > Keep in mind it's up to the network to trust and enforce DSCP markings, > so that's the proper place for these kind of access controls to appear. > Otherwise you'll need to convince the various *nix vendors to require > privileges on setting DSCP markings. Again, you're missing the obvious: the settings are more easily and better trusted when they're set by someone who actually had a hand in setting the site network policy! They are more likely to work. You're thinking of these as a per-host setting that only affects the host, and they're not. It's a setting that affects the entire network, and should be set in a consistent and coherent way organization-wide. It's not about what the user might set just because he can. It's about what should be set by the site administrators because they're actually the most clueful. -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
