On Sat, May 21, 2022 at 9:38 AM Peter Stuge <peter@xxxxxxxx> wrote:
>
> Nico Kadel-Garcia wrote:
> > I'm dealing with Azure DevOps git services with which recent, security
> > hardened SSH clients on a RHEL 8 variant cannot stablish public-key
> > based SSH links to the Azure Devops.
>
> How was that security hardning done?
I rather wish I had every detail of the hardening: it's the CIS
published L2 security, RHEL 8 VM image in the Azure Marketplace. I
don't have in my personal hands the precise set of hardening steps. I
wish I did! I'm not a big believer that different vendors or security
staff follow precisely the same steps to follow a published security
standard, even if it's me doing the work, and it has been me on
numerous occasions in my career. It's why when I do those, I publish
the dockerfiles or chef or ansible playbooks applied to the VM image
as a published list, in source control for the employere.
In this case, the Azure VM with which I'm having the issues is listed
by the "az vm image list --all -otsv" command as:
center-for-internet-security-inc:cis-rhel-8-l2:cis-rhel8-l2:1.0.11
> And if it's something RHEL-specific then what about upstream OpenSSH?
It works fine on CentOS and standard RHEL based images, it seems
specific to the CIS published image. I was hoping someone else had
seen the issue.
For reference, I'm an *old* SSH users, and published the first public
ports of ssh-1, ssh-2, and OpenSSH to SunOS back in the day, and still
take potshots at backporting OpenSSH current releases to RHEL.
> > Conversely, Azure Bastion cannot use Azure key vault stored private
> > SSH keys to access the same RHEL 8 based servers,
>
> Try running sshd with -ddd and see what it says?
>
> Although this seems to be a RHEL issue maybe you can debug it yourself..
Since the dominating problem is the git client usage, I'm more
concerned with running:
GIT_SSH_COMMAND='git -v -v -v -v -v' git clone azure-server-git-url
I don't have manual control of the git server enough to tweak the
'sshd' options on it: it's a cloud service, and I suspect I'd need a
much, much larger contract and much more established credentials with
the "Tier 3" engineers on that project to get them to tweak the sshd
options.
It seems CIS specific, above and beyond being RHEL specific. I did
synchronize, and revert, the 'gnutls' configs set by the
'crypto-policies' RPMs, to avoid conflicts among the sets of
encryption protocols listed in
/etc/crypto-policies/back-ends/libssh.config
/etc/crypto-policies/back-ends/openssh.config
/etc/crypto-policies/back-ends/opensshserver.config
I speculated that a published tweak there among the
'PubkeyAcceptedKeyTypes' might be forbidding a required encryption
protocol. I was hoping someone else had already run into the issue and
had a working fix or pointer to specific workarounds. So far, no luck.
I was kind of hoping someone else with my kind of multi-environment
support experience had run into this and had a workaround. I'd also
like a pony....
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@xxxxxxxxxxx
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
