SSHD - ONE QUESTION - THIS SHOULD BE AN EASY Q&A

[john guardian]

Pertaining to ssh/sshd client/server defaults for the ssh_config/sshd_config files:

Just because certain vaules are considered defaults, does that also necessarily mean that the keywords DO NOT need to be in these config files?

Thx in advance as this is a hot button topic at one of the sites I support.

[James R. Ferguson]

Hi John:

Why would you *not* want the possible options documented?  No, the keywords don't have to be present.

btw, is your all lowercase keyboard broken and/or CAP LOCKS ON? "-)

Regards!

...JRF...

[Matti_Kurkela]

When the OpenSSH project produces a new release, it includes a set of example configuration files, with all the settings commented out (prefixed with the "#" sign). None of the commented-out lines in the configuration file is meaningful to OpenSSH: they exist only to document the built-in default settings to the system administrators.

When the portable OpenSSH suite is compiled and packaged (e.g. by HP for HP-UX, by RedHat, Suse and others for Linux, etc.) the package maintainers of each vendor/distributor may choose to change some settings. These changes might be applied as source code patches that change the built-in defaults, or as non-comment lines included in the default ssh_config/sshd_config files included in the package.

If you remove a commented-out line from the ssh_config/sshd_config files, the behavior of ssh/sshd will not change. But if you remove a configuration line that is not commented out, a built-in default will be used instead: that default may or may not be the same as on the non-commented-out configuration line.

You can always verify the effective configuration that results from your current sshd configuration file by running "sshd -T". 

[john guardian]

Sorry Jack. CAPS were on. Realized it after the fact. Don't understand the mentality of non-documenting the defaults myself, but it's what the general concensus is, so no sense fighting city hall...

MK, the "T" option... I'll have to check on it next time I'm at the console. Thx.

One last Q: I don't see 3des-ctr listed (supported Ciphers) on the hp man page(s) for ssh(d) support (of protocol 2), yet the generic openssh appears to support it. Is this just an omission on HP's part (supported but left out for some unknown reason) or is it due to HP leaving this feature (3des-ctr) out?

Thx.

[Matti_Kurkela · Accepted solution]

Looks like Debian omits 3des-ctr too.

Hmm... Wikipedia says 3des with keying method 2 has known attacks that reduce it to an effective level of "80 bits of security", according to NIST. Perhaps 3des-cdc is kept because it is specified as REQUIRED in the SSH2 protocol specification, and the omission of 3des-ctr is because the SSH community is seeing 3des in general as a legacy algorithm and is aiming towards wider use of AES and other more secure encryption schemes?

If you have a legitimate business requirement for 3des-ctr (e.g. 3des being absolutely required to comply with legislation or other similar requirement), you might want to tell HP about it: I'd guess enabling 3des-ctr in HP SSH is just a matter of adjusting the compile-time settings.