:: Re: [DNG] OT: Descriptions of globa…
Top Page
Delete this message
Reply to this message
Author: Vince Mulhollon
Date:  
To: dng
Subject: Re: [DNG] OT: Descriptions of global /etc/ssh/ssh_config customization?
On Mon, Feb 19, 2024 at 2:45 AM Lars Noodén via Dng <dng@???> wrote:
> If there are any descriptions of how
> computing environments make use of /etc/ssh/ssh_config those would be
> nice to know.


https://gitlab.com/SpringCitySolutionsLLC/ansible/-/blob/master/roles/ssh/files/ssh_config.devuan?ref_type=heads

and its partner for sshd configuration

https://gitlab.com/SpringCitySolutionsLLC/ansible/-/blob/master/roles/ssh/files/sshd_config.devuan?ref_type=heads

The configs linked above assume the use of forwarded X11 (a local
requirement) and permit SSO using Samba-based active directory
authentication and are intended for internal use only; you could make
something exposed to the internet somewhat more secure. For example I
would not put "PermitRootLogin yes" in the sshd of a host out on the
net.

Some random commentary:

Anything configured by ansible (or presumably, puppet, cfengine, etc)
needs a comment line in the config similar to "# Configured
automatically by ansible" or you will drive yourself and the people
around you insane when local changes are overwritten.

The selection of kex, host key, and cipher is not entirely driven by
what's most secure but at least partially driven by the logical set
union of all possible SSH-using apps and clients across all supported
platforms plus or minus the headaches involved in supporting "custom"
kex, host key, and ciphers. From memory "in the old days" it was
possible to make a very secure config that would simply not work with
the putty terminal of that era due to not supporting something or
other.

"VerifyHostKeyDNS" sounds like a great idea but historically did not
work, I don't recall why or even recall the symptoms. Would not mind
using DNSSEC to distribute my set of trusted host keys.

How you distribute your list of trustworthy host keys is an open question.

> current practices?


I wonder about those also.

I 'know' for a fact the special handling for sftp is no longer
required, or maybe it is. It was required in the early 2010s or so,
and works today.

The cipher choices are based on some now ancient blogpost a decade ago
probably named something like "more secure ssh". Wouldn't mind seeing
a 2024 update of what the cool kids think is cool in 2024.