SSH -Q key access from the red zone

Security
1

I have an issue that is slowly driving me crazy: I’ve blocked ports 22 and 222 in the firewall.
ssh -l root xxx.xxx.xxx.xxx (where xxx.xxx.xxx.xxx is the public ip address of my ipfire machine) from outside our company doesn’t do anything, so that part is good.

but ‘ssh -Q key xxx.xxx.xxx.xxx’ results in a list:

ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
sk-ssh-ed25519@openssh.com
sk-ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp256@openssh.com
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com

How can I prevent this from happening? I don’t want it to show this list.

3

Try:
# ssh -Q key
without a IP-Address. you will get the same answer. I assume this option shows the local side, not the remote IPFire.

2 Likes
4

−Q query_option
Queries ssh for the algorithms supported for the specified version 2. The available features are: cipher (supported symmetric ciphers), cipher-auth (supported symmetric ciphers that sup- port authenticated encryption), help (supported query terms for use with the −Q flag), mac (sup- ported message integrity codes), kex (key exchange algorithms), key (key types), key-cert (cer- tificate 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 signa- ture algorithms). Alternatively, any keyword from ssh_config(5) or sshd_config(5) that takes an algorithm list may be used as an alias for the corresponding query_option.

5

Thank you. This seems plausible.