SSH Login Issues from the shell via PEM cert, but not with Ansible playbook or inspec shell #703
Comments
|
Hi @aaronlippold, I'm not entirely sure exactly what you're running into, as we do not use the ansible-lockdown scripts. But the SPEL images do have FIPS enabled out of the box, and that does impose a number of restrictions on the allowed ciphers. It might be that your ssh cert is not using an allowed cipher. For example, ED25519 keys are not allowed when FIPS is enabled. Also, SHA1 ciphers will be rejected. As well as keys with a length less than 2048 bits. One thing from the logs:
The default user for spel images is |
|
Hello,
I appreciate you responding, as my inquiry is embarrassing, but out of
frustration because I’m not seeing the obvious.
I know I did update the user to maintuser users so perhaps I copied The
incorrect log I will double check that.
I do see the logic of your suggestion, however, I am surprised that the
verbose logs if that was the issue wouldn’t have complained about the
cipher. But I will definitely look into the generation of test kitchen and
AWS defaults to And see if I can overwrite it to use a known good
encryption
It’s also good to know that you guys use those scripts so the only
difference in my process is that I’m using test kitchen to orchestrate the
workflow and at least now I have a deviation point for the introduction of
possible.
I will look at it this afternoon and again thank you and I will let you
know what I find out
…--------
Aaron Lippold
***@***.***
260-255-4779
twitter/aim/yahoo,etc.
'aaronlippold'
On Fri, Sep 13, 2024 at 18:29 Loren Gordon ***@***.***> wrote:
Hi @aaronlippold <https://github.com/aaronlippold>, I'm not entirely sure
exactly what you're running into, as we do not use the ansible-lockdown
scripts. But the SPEL images do have FIPS enabled out of the box, and that
does impose a number of restrictions on the allowed ciphers. It *might*
be that your ssh cert is not using an allowed cipher. For example, ED25519
keys are not allowed when FIPS is enabled. Also, SHA1 ciphers will be
rejected. As well as keys with a length less than 2048 bits.
One thing from the logs:
debug1: Authenticating to 54.242.90.186:22 as 'ec2-user'
The default user for spel images is maintuser, not ec2-user. Perhaps you
are using your own images and changing the default user, but if not, then
try using maintuser.
—
Reply to this email directly, view it on GitHub
<#703 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALK42BIWKV5BKNZYUA2XOLZWNRMRAVCNFSM6AAAAABOEHQBUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJQGUZDSNRZGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I did a little hacking and found that this command ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -o LogLevel=VERBOSE -o [email protected],aes256-ctr,[email protected],aes128-ctr -o [email protected],hmac-sha2-256,[email protected],hmac-sha2-512 -o KexAlgorithms=ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 -p 22 -i .kitchen/hardened-rhel-9.pem maintuser@<myip>works The SSHD runtime is, the thing that jumps out to me is the `gssapikexalgorithms' I can't find anything in the ansible with respect to gssapikeyalgorithms but at least I can ssh into it now and not have to try to debug over the inspec shell Any thing jump out to you guys on this? port 22
addressfamily any
listenaddress [::]:22
listenaddress 0.0.0.0:22
usepam yes
logingracetime 120
x11displayoffset 10
x11maxdisplays 1000
maxauthtries 6
maxsessions 10
clientaliveinterval 600
clientalivecountmax 1
requiredrsasize 2048
streamlocalbindmask 0177
permitrootlogin no
ignorerhosts yes
ignoreuserknownhosts yes
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
kerberosuniqueccache no
kerberosusekuserok yes
gssapienablek5users no
gssapiauthentication no
gssapicleanupcredentials no
gssapikeyexchange no
gssapistrictacceptorcheck yes
gssapistorecredentialsonrekey no
gssapikexalgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-
group14-sha1-,gss-gex-sha1-
passwordauthentication yes
kbdinteractiveauthentication no
printmotd no
printlastlog yes
x11forwarding yes
x11uselocalhost yes
permittty yes
permituserrc yes
strictmodes yes
tcpkeepalive yes
permitemptypasswords no
compression no
gatewayports no
usedns no
allowtcpforwarding yes
allowagentforwarding yes
disableforwarding no
allowstreamlocalforwarding yes
streamlocalbindunlink no
fingerprinthash SHA256
exposeauthinfo no
pidfile /var/run/sshd.pid
modulifile /etc/ssh/moduli
xauthlocation /usr/bin/xauth
ciphers [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
macs [email protected],hmac-sha2-256,[email protected],hmac-sha2-512,hmac-sha1-etm@o
penssh.com,[email protected],hmac-sha1,[email protected]
banner /etc/issue
forcecommand none
chrootdirectory none
trustedusercakeys none
revokedkeys none
securitykeyprovider internal
authorizedprincipalsfile none
versionaddendum none
authorizedkeyscommand none
authorizedkeyscommanduser none
authorizedprincipalscommand none
authorizedprincipalscommanduser none
hostkeyagent none
kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,
diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
casignaturealgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512
hostbasedacceptedalgorithms [email protected],[email protected]
m,[email protected],[email protected],[email protected]
om,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256
hostkeyalgorithms ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,ecdsa-sha
[email protected],ecdsa-sha2-nistp521,[email protected],rsa-sha2-256,rs
[email protected],rsa-sha2-512,[email protected]
pubkeyacceptedalgorithms ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,ec
[email protected],ecdsa-sha2-nistp521,[email protected],rsa-sha2
-256,[email protected],rsa-sha2-512,[email protected]
loglevel VERBOSE
banner /etc/issue
forcecommand none
chrootdirectory none
trustedusercakeys none
revokedkeys none
securitykeyprovider internal
authorizedprincipalsfile none
versionaddendum none
authorizedkeyscommand none
authorizedkeyscommanduser none
authorizedprincipalscommand none
authorizedprincipalscommanduser none
hostkeyagent none
kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,
diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
casignaturealgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512
hostbasedacceptedalgorithms [email protected],[email protected]
m,[email protected],[email protected],[email protected]
om,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256
hostkeyalgorithms ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,ecdsa-sha
[email protected],ecdsa-sha2-nistp521,[email protected],rsa-sha2-256,rs
[email protected],rsa-sha2-512,[email protected]
pubkeyacceptedalgorithms ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,ec
[email protected],ecdsa-sha2-nistp521,[email protected],rsa-sha2
-256,[email protected],rsa-sha2-512,[email protected]
loglevel VERBOSE
syslogfacility AUTHPRIV
authorizedkeysfile .ssh/authorized_keys
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_key
authenticationmethods any
subsystem sftp /usr/libexec/openssh/sftp-server
maxstartups 10:30:100
persourcemaxstartups none
persourcenetblocksize 32:128
permittunnel no
ipqos af21 cs1
rekeylimit 1073741824 3600
permitopen any
permitlisten any
permituserenvironment no
pubkeyauthoptions none |
|
@ferricoxide if you get a minute, could you offer any suggestions? |
|
Added Note: I also added this to my Host *
Ciphers 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,[email protected],hmac-sha2-512
KexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,[email protected],[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512This may be an effect of enabling FIPS, but updating the client side ssh config has not been something I have have to do before and I have been connecting to DOD boxing a few many years :) |
|
Having to configure the ssh-client configuration is something that seems to come along every couple RHEL generations. I'd assumed that some of it was due the march of ever-tightening security controls (e.g., EL8 no longer accepts anything less than a SHA256 key if you're using RSAv2 and wholly disables support for most of the other encryption-families that EL 6 & 7 supported). At any rate, last time I had to configure Ciphers/MACs in my SSH client was RHEL 5 time-frame (2010ish). Pretty sure the reason I had to do it, at all, was that I was using generic SSH clients. Since switching away from using either the local OS's native SSH client, Cygwin/X's client or PuTTY's, it's basically been a non-problem. That said, avoidance of those came due a change in my personal workflow: I no longer connect directly from my local OS. Instead, I run ELx VMs on my local host and connect from those VMs. I would assume that, since I use "latest and greatest" for my local VMs, changes caused by posture-deltas between the remote host and the local clients are generally eliminated (or, where deltas exist, the SSH client I'm using is generally going to be more fascist than the remote server's configuration). |
|
Do we think this is something we’d want to document in the read me and I
think perhaps this is something I should possibly raise to the test kitchen
folks as well to see if we can incorporate some sort of workaround.
I think the very least we should probably document what we found so others
don’t have to go through the same pain :-)
Would there be a way to make the cipher and such an * or ‘any’
configuration so that when we do a we avoid this issue on the client side?
In my case, the SSH client is the stock standard of osx.
Perhaps could try to install via BREW And see how I fair with that client.
What do we think the proper next steps are?
--------
Aaron Lippold
***@***.***
260-255-4779
twitter/aim/yahoo,etc.
'aaronlippold'
…On Mon, Sep 16, 2024 at 08:37 Thomas H Jones II ***@***.***> wrote:
Having to configure the ssh-client configuration is something that seems
to come along every couple RHEL generations. I'd assumed that some of it
was due the march of ever-tightening security controls (e.g., EL8 no longer
accepts anything less than a SHA256 key if you're using RSAv2 and wholly
disables support for most of the other encryption-families that EL 6 & 7
supported).
At any rate, last time I had to configure Ciphers/MACs in my SSH client
was RHEL 5 time-frame (2010ish). Pretty sure the reason I had to do it, at
all, was that I was using generic SSH clients. Since switching away from
using either the local OS's native SSH client, Cygwin/X's client or
PuTTY's, it's basically been a non-problem.
That said, avoidance of those came due a change in my personal workflow: I
no longer connect directly from my local OS. Instead, I run ELx VMs on my
local host and connect from *those* VMs. I would assume that, since I use
"latest and greatest" for my local VMs, changes caused by posture-deltas
between the remote host and the local clients are generally eliminated (or,
where deltas exist, the SSH client I'm using is generally going to be more
fascist than the remote server's configuration).
—
Reply to this email directly, view it on GitHub
<#703 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALK42FFEBNFWHAKJGCS6C3ZW3GHRAVCNFSM6AAAAABOEHQBUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJSG44TSOBWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I feel like OSX is infamous for including out-of-date clients and shells. Really need to manage the dev environment and take full control, not rely on OSX as much. |
|
Honestly, you're the first person reporting this. That said I'd imagine that's influenced by two things:
Neither of which is to be confused with me saying there's nothing to be put in the documentation, just that, absent indications to the contrary, yours appears to be a very corner-case scenario. I know that in the past, we've had issues with OSX-users' execution of spel and related projects' BASH-based logic as the default version of BASH in OSX has been considerably behind "current" – even moreso than that in Red Hat's major-releases. I would be curious to see what your results were if using a more up-to-date SSH client (i.e., your mention of using |
|
Happy to look into this and also have some non osx team members run the
same test flow to see if this is isolated.
This is more along the lines of a if you happen to run into some strange
behavior like this try this kind of thing as a note in the read me.
…--------
Aaron Lippold
***@***.***
260-255-4779
twitter/aim/yahoo,etc.
'aaronlippold'
On Mon, Sep 16, 2024 at 12:04 Thomas H Jones II ***@***.***> wrote:
Honestly, you're the first person reporting this. That said I'd imagine
that's influenced by two things:
1. Most users of spel AMIs are using the EL *8* AMIs, not the EL *9*
AMIs (we only just recently started making EL9 hardening-content available
and have no spel-using organizations that have made us aware that they're
even beginning to think about life beyond EL 8).
2. Most users of spel AMIs aren't doing so via direct connection from
OSX (most of the organizations we have explicit knowledge of are primarily
Windows-based organizations)
Neither of which is to be confused with me saying there's nothing to be
put in the documentation, just that, absent indications to the contrary,
yours appears to be a very corner-case scenario. I know that in the past,
we've had issues with OSX-users' execution of spel and related projects'
BASH-based logic as the default version of BASH in OSX has been
considerably behind "current" – even moreso than that in Red Hat's
major-releases. I would be curious to see what your results were if using a
more up-to-date SSH client (i.e., your mention of using brew).
—
Reply to this email directly, view it on GitHub
<#703 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALK42CASAGBIWFLW5I2LRTZW36RHAVCNFSM6AAAAABOEHQBUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJTGMZTENRSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Also, At some point, I’d love to be able to show you some of the work that
my teams have been doing around this you may find some of the security
validation profiles. I’ve been writing inspect and are open source Heindel
application something you guys might find useful.
…--------
Aaron Lippold
***@***.***
260-255-4779
twitter/aim/yahoo,etc.
'aaronlippold'
On Mon, Sep 16, 2024 at 15:44 Aaron Lippold ***@***.***> wrote:
Happy to look into this and also have some non osx team members run the
same test flow to see if this is isolated.
This is more along the lines of a if you happen to run into some strange
behavior like this try this kind of thing as a note in the read me.
--------
Aaron Lippold
***@***.***
260-255-4779
twitter/aim/yahoo,etc.
'aaronlippold'
On Mon, Sep 16, 2024 at 12:04 Thomas H Jones II ***@***.***>
wrote:
> Honestly, you're the first person reporting this. That said I'd imagine
> that's influenced by two things:
>
> 1. Most users of spel AMIs are using the EL *8* AMIs, not the EL *9*
> AMIs (we only just recently started making EL9 hardening-content available
> and have no spel-using organizations that have made us aware that they're
> even beginning to think about life beyond EL 8).
> 2. Most users of spel AMIs aren't doing so via direct connection from
> OSX (most of the organizations we have explicit knowledge of are primarily
> Windows-based organizations)
>
> Neither of which is to be confused with me saying there's nothing to be
> put in the documentation, just that, absent indications to the contrary,
> yours appears to be a very corner-case scenario. I know that in the past,
> we've had issues with OSX-users' execution of spel and related projects'
> BASH-based logic as the default version of BASH in OSX has been
> considerably behind "current" – even moreso than that in Red Hat's
> major-releases. I would be curious to see what your results were if using a
> more up-to-date SSH client (i.e., your mention of using brew).
>
> —
> Reply to this email directly, view it on GitHub
> <#703 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AALK42CASAGBIWFLW5I2LRTZW36RHAVCNFSM6AAAAABOEHQBUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJTGMZTENRSGI>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Since this issue was a functionality issue that seems to be something more-appropriately addressed as a documentation issue, I opened a separate (documentation) issue (#705) to track it. I'm going to close this issue in favor of the documentation-issue. |
|
Sounds great |
Hello,
I am having an odd issue when I run the https://github.com/ansible-lockdown/RHEL9-STIG on the SPEL image in AWS that SSH login with a PEM cert stops working in the shell.
Oddly, if I run the playbook using the same cert and user, ansible is able to connect and run the playbook.
Has anyone run into an issue like this before?
The text was updated successfully, but these errors were encountered: