I have a shell script which adds the below to sshd_config and then restarts ssh.

cat << EOF >> /etc/ssh/sshd_config
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512,ssh-rsa-cert-v01@openssh.com

It worked fine until I ran it on a Debian 8 box where the given HostKeyAlgorithms aren't supported, so ssh wouldn't start. Removing the HostKeyAlgorithms line using emergency console fixed the issue and ssh started.

Is there a clever way for that script to check if these HostKeyAlgorithms (and maybe KexAlgorithms, Ciphers and MACs) are supported by SSH before restarting it and risking getting locked out?


You can just use the query option, as shown in the man page:

     -Q query_option
             Queries ssh for the algorithms supported for the specified ver‐
             sion 2.  The available features are: cipher (supported symmetric
             ciphers), cipher-auth (supported symmetric ciphers that support
             authenticated encryption), help (supported query terms for use
             with the -Q flag), mac (supported message integrity codes), kex
             (key exchange algorithms), kex-gss (GSSAPI key exchange algo‐
             rithms), key (key types), key-cert (certificate key types),
             key-plain (non-certificate key types), key-sig (all key types and
             signature algorithms), protocol-version (supported SSH protocol
             versions), and sig (supported signature algorithms).  Alterna‐
             tively, any keyword from ssh_config(5) or sshd_config(5) that
             takes an algorithm list may be used as an alias for the corre‐
             sponding query_option.

For example:

error@vmtest-debian8:~$ ssh -Q key

Check your man page, as you have a much older version of OpenSSH on that old distro and will not have all of the above options available.

  • 1
    In any case, I'd strongly advise any automatic modification to SSH to keep a copy of the original sshd_config so it can rollback in case the service fails to restart, precisely to avoid having to do that in an emergency shell. – Ginnungagap Jun 19 '20 at 21:21

Test the sshd_config with sshd -t on the host being updated. Further, -f option allows specifying the proposed config file. No need to touch the running one until the new one can be parsed.

Locking yourself out is still possible, but at least will not be because the config could not be parsed.

Incomplete shell script outline:

SSHD_CONFIG=$(mktemp sshd.XXXX)
# copy new config to ${SSHD_CONFIG}
sshd -t -f ${SSHD_CONFIG}
# failure if return is not 0
# install sshd_config
# restart sshd service

Or, if you use Ansible for automation, file related modules can do something similar. A validate parameter, a command where %s is replaced with a copy of the proposed file. sshd is one of the template module's examples.

- name: Update sshd configuration safely, avoid locking yourself out
    validate: /usr/sbin/sshd -t -f %s
    backup: yes

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.