Skip to main content

sshd is not honoring sshd_config settings [Resolved]

I am adding the following settings to my docker based centos 7 /etc/ssh/sshd_config file:

Match User ansible
        PermitEmptyPasswords yes
        PasswordAuthentication no
        PermitRootLogin without-password
        PubkeyAuthentication no
        HostbasedAuthentication yes

And I am noticing that sshd is not honoring those settings, at least it is still asking for a password. In my set up, my ansible user does not have a password at all, but I still require it to shell into various machines without authentication. I do know about ssh-copy-id however since this is a closed docker network, I am wanting to bypass they key handling and just allow the user ansible to pass in.

I know it's not secure, however this is just for a test environment for development only.

What additional settings should I add to my sshd_config file to ensure I am never bothered for a password nor asked to type in "yes" to accept a fingerprint?

Here is what I see when inside my docker:

[root@docker-ansible /]# ssh ansible@portal.docker.local

The authenticity of host 'portal.docker.local (172.31.0.2)' can't be established.
ECDSA key fingerprint is SHA256:klErLlMAooQXDpAVNAsGoQTt5r+GdjDX06Fgihstteo.
ECDSA key fingerprint is MD5:60:4e:1e:6a:05:12:45:e9:21:79:4b:22:0b:1b:a7:cd.

Are you sure you want to continue connecting (yes/no)? yes <-- I need to not be typing yes here.

Warning: Permanently added 'portal.docker.local,172.31.0.2' (ECDSA) to the list of known hosts.

Permission denied (gssapi-keyex,gssapi-with-mic,hostbased).

When I try again, after typing in "yes", still:

[root@docker-ansible /]# ssh ansible@portal.docker.local

Permission denied (gssapi-keyex,gssapi-with-mic,hostbased).

Update: I just tried @telcoM's idea and although this feels close, it doesn't work. The end of my sshd_config file is this:

Match User ansible 
   PermitEmptyPasswords yes 
   AuthenticationMethods none 

But now the error i get is:

[ansible@docker-ansible ~]$ ssh -o StrictHostKeyChecking=no portal.docker.local
ansible@ocker-ansible's password:
:(

So it appears to be wanting the password still...


Question Credit: E.S.
Question Reference
Asked October 6, 2019
Posted Under: Network
20 views
1 Answers

The host key fingerprints and the "Are you sure you want to continue connecting?" prompt is generated by your SSH client, not the remote sshd. No amount of configuration on the sshd server will change that. The setting you need to change in either your local personal ~/.ssh/config or in local system-wide /etc/ssh/ssh_config is StrictHostKeyChecking.

  • If you set it to accept-new, new keys will be accepted, but changed keys on previously-known hosts will not be.
  • If you set it to no, both new and changed host keys will be accepted.
  • The default setting is ask, which is what you currently have.
  • Setting it to yes is the most strict option: with this setting, the SSH client will never connect unless it has the host key available locally in advance (maximum security, minimum convenience).

Now let's analyze your sshd_config snippet:

Match User ansible
        PermitEmptyPasswords yes
        PasswordAuthentication no
        PermitRootLogin without-password
        PubkeyAuthentication no
        HostbasedAuthentication yes
  • PermitEmptyPasswords yes: not very applicable as you have set PasswordAuthentication no. This may still prevent sshd from treating a passwordless user account as equivalent to a disabled one.
  • PasswordAuthentication no: you'll never get asked for a password for this user (or if you do, it will be a fake prompt just to waste the time of a potential intruder)
  • PermitRootLogin without-password: no effect here, we're within a Match User ansible block, we're talking about logging in as user ansible, not as root.
  • PubkeyAuthentication no: ~ansible/.ssh/authorized_keys will have no effect.
  • HostbasedAuthentication yes: this one may not work the way you think it does.

Requirements for HostbasedAuthentication

In order for HostbasedAuthentication to allow your login, the host key of the host you're coming from must already exist in the remote /etc/ssh/ssh_known_hosts or in ~ansible/.ssh/known_hosts, and either your local hostname must be listed in system-wide /etc/ssh/shosts.equiv or /etc/hosts.equiv or your local hostname and username must be listed in ~ansible/.shosts or ~ansible/.rhosts.

So HostbasedAuthentication is definitely not the no-preparation get-in-without-password setup you may have imagined it to be.

To get a fully wide-open, no-authentication set-up for the ansible user, try this Match block:

Match User ansible
    PermitEmptyPasswords yes
    AuthenticationMethods none

Obviously, NEVER use this on anything that is connected to the internet.


credit: telcoM
Answered October 6, 2019
Your Answer
D:\Adnan\Candoerz\CandoProject\vQA