ssh-audit
ssh-audit copied to clipboard
jtesta
Client-scan | Failed to listen on any IPv4 and IPv6 interfaces
$ cat /etc/redhat-release
Fedora release 38 (Thirty Eight)
$ ssh -V
OpenSSH_9.0p1, OpenSSL 3.0.8 7 Feb 2023
$ pip3 show -f ssh-audit | sed -n 2p
Version: 2.9.0
Hello. While a client-scan is operational at the web front-end for the ssh-audit tool, with that latter it is not. Note: OpenSSH-client left on purpose with the default configuration.
$ cd /home/$USER/.local/bin; ssh-audit -dcp 22
Listening for client connection on port 22...
Warning: failed to listen on any IPv4 interfaces.
Warning: failed to listen on any IPv6 interfaces.
Error: failed to listen on any IPv4 and IPv6 interfaces!
Hmm... I see the "$" in your command prompt. Does that mean you ran it as a non-root user? If so, that would be the problem, since only root can listen on ports under 1024.
It means that. The terminal session too in which i pasted the content associated to Copy OpenSSH-client command that is present in https://ssh-audit.com/, must have been opened against a non-root user. As per "A listener will begin on a random port on the ssh-audit.com server.", i did not pay attention that the produced port numbers were invariably superior to 1023.
$ cd /home/$USER/.local/lib/python3.11/site-packages; sudo su
# ../../../bin/ssh-audit -c
Traceback (most recent call last):
File "/home/yk/.local/lib/python3.11/site-packages/../../../bin/ssh-audit", line 5, in <module>
from ssh_audit.ssh_audit import main
ModuleNotFoundError: No module named 'ssh_audit'
Could you re-try without using the -p 22 option? By default, it will listen on 2222/tcp. Does that still result in an error?
@Ricky-Tigg : I checked in a small change into the master branch which prints more verbose error messages when socket listening operations fail. Can you please try with this version?
I am ready. As per https://github.com/jtesta/ssh-audit#usage, despite the mention of the version cannot be shown, that is this version. Information that may be relevant in the scope of an investigation:
- Configuration of firewalld, which is the default firewall in use in Fedora, is with its defaults in regard to ssh service and port 22.
$ firewall-cmd --permanent --list-ports
1025-65535/tcp 1025-65535/udp
Since only root can listen on ports inferior to 1024, can't it be deducted that supported port ranges both for udp and tcp, are expected to be 1024–65535? Anyway that's out of scope here.
$ firewall-cmd --permanent --list-services
dhcpv6-client mdns ssh
- OpenSSH's client configuration unchanged.
$ cat /etc/ssh/ssh_config | grep Port
# Port 22
At last, the test:
$ ./ssh-audit.py -dvc
Listening for client connection on port 2222...
Warning: failed to listen on any IPv4 interfaces: [Errno 98] Address already in use
Warning: failed to listen on any IPv6 interfaces: [Errno 98] Address already in use
Error: failed to listen on any IPv4 and IPv6 interfaces!
Listening for client connection on port 2222... Warning: failed to listen on any IPv4 interfaces: [Errno 98] Address already in use Warning: failed to listen on any IPv6 interfaces: [Errno 98] Address already in use
Looks like your system has another process listening on 2222/tcp already. What happens if you use -p to specify an unused port?
Once the system rebooted:
$ ./ssh-audit.py -dvc
Listening for client connection on port 2222...
Here the process becomes frozen. Same observation while being on a virtual machine running on KVM. Does it work as intended in the Linux distribution you are testing with?
It seems that the ssh-audit process is waiting for an incoming client connection. Try connecting to it with ssh -p 2222 x@localhost.
Does it work as intended in the Linux distribution you are testing with?
Yes. I just tested the master branch code now, and it properly audits my client.
I have to ensure with you that the need of a running OpenSSH daemon is not among the prerequisites, as it can be interpreted as such as per https://github.com/jtesta/ssh-audit#readme, since no mention in regards to that need is present. If so, all good, that's the present situation:
# lsof -i -n -P | grep '(LISTEN)' | grep -E '^ssh|:22'
$ systemctl status sshd | grep -E 'Loaded|Active'
Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; preset: disabled)
Active: inactive (dead)
As expected that daemon is not enabled by default on Desktop editions; however it is on Server editions. Now, the test either with ssh -p 2222 127.0.0.1 or the following command:
# setenforce 0
$ ssh -p 2222 x@localhost
ssh: connect to host localhost port 2222: Connection refused
# setenforce 1
I ensured that SELinux is not cause of that state.
I have to ensure with you that the need of a running OpenSSH daemon is not among the prerequisites
When you use the -c option, that tells ssh-audit to listen for incoming SSH connections (on 2222/tcp by default). This lets the user connect using their client and see if their client config is hardened. No other SSH services are needed for this test.
$ ssh -p 2222 x@localhost ssh: connect to host localhost port 2222: Connection refused
If ssh-audit is listening on 2222/tcp on the same machine, and this connection is failing, then this would be a local firewall problem.
FirewallD then.
$ firewall-cmd --state
running
$ firewall-cmd --zone=`firewall-cmd --get-default-zone` --list-all | sed 1d | column
target: default forward: yes
icmp-block-inversion: no masquerade: no
interfaces: forward-ports:
sources: source-ports:
services: dhcpv6-client mdns ssh icmp-blocks:
ports: 1025-65535/udp 1025-65535/tcp rich rules:
protocols:
Could FirewallD be involved? Stopping it though.
# systemctl stop firewalld
$ firewall-cmd --state
not running
Tests:
ssh -vvvp 2222 x@localhost| Connection refused../ssh-audit.py -vc| Previous behavior still valid.- Adding one verbose-level.
$ ./ssh-audit.py -vvc
Listening for client connection on port 2222...
Warning: failed to listen on any IPv4 interfaces: [Errno 98] Address already in use
Warning: failed to listen on any IPv6 interfaces: [Errno 98] Address already in use
Error: failed to listen on any IPv4 and IPv6 interfaces!
So here it did not froze. However despite that extra verbose-level, the frozen state may still be encountered. I run ./ssh-audit.py -vvcp <port> at least with ports 2121and 3333; same outputs as above. Something triggers [Errno 98] Address already in use there but not with OpenSSH commands. What can it be?
Something triggers [Errno 98] Address already in use there but not with OpenSSH commands. What can it be?
I don't know what is causing that. But it doesn't seem to be an issue with the application, which leaves the host configuration as the main suspect here.
Do you see any related error messages in /var/log/syslog?
@Ricky-Tigg On my system (also Fedora 38) everything works fine, (of course firewall disabled or port allowed)
$ ssh-audit -dvc
Listening for client connection on port 2222...
Getting banner...
KEX initialisation...
# general
(gen) client IP: 192.168.124.1
(gen) banner: SSH-2.0-OpenSSH_9.0
(gen) software: OpenSSH 9.0
(gen) compression: enabled ([email protected], zlib)
# key exchange algorithms
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
(kex) curve25519-sha256 -- [info] default key exchange since OpenSSH 6.4
(kex) [email protected] -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
(kex) [email protected] -- [info] default key exchange since OpenSSH 6.4
...
But I use ssh-audit from my copr repo, maybe something is wrong with the pip version?
You can use the netstat command to check what is listening on each port
netstat -atpn
$ ls --group-directories-first /var/log/
chrony private btmp dnf.log firewalld lastlog tallylog
gdm boot.log dnf.librepo.log dnf.rpm.log hawkey.log README wtmp
$ ls --group-directories-first /var/tmp/`ls /var/tmp/ | grep "dnf-$USER-"` | grep -v / | grep '\.log$' | column
dnf.librepo.log dnf.log dnf.rpm.log hawkey.log
Hence no syslog. firewalld is empty. I investigated against journalctl without success. My system is perhaps corrupted. Now removing the application As PyPI in order to test with the package sunwire has tested with.
$ dnf --installed rq --qf '%{version} %{release} %{packager} %{from_repo}' ssh-audit
2.9.0 1.git20230621.fc38 (none) copr:copr.fedorainfracloud.org:sunwire:ssh-audit
Closing the terminal before running the following command,
# netstat -atpn | grep LISTEN
tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 684/systemd-resolve
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 684/systemd-resolve
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 684/systemd-resolve
tcp6 0 0 :::5355 :::* LISTEN 684/systemd-resolve
The test:
$ ssh-audit -dvc
Listening for client connection on port 2222
Freezing here.
On an other TTY
# netstat -atpn | grep LISTEN | grep python3
tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 48521/python3
tcp6 0 0 :::2222 :::* LISTEN 48521/python3
Back to the previous TTY, interrupting the process: New attempt:
$ ssh-audit -dvc
Listening for client connection on port 2222...
Warning: failed to listen on any IPv4 interfaces: [Errno 98] Address already in use
Warning: failed to listen on any IPv6 interfaces: [Errno 98] Address already in use
Error: failed to listen on any IPv4 and IPv6 interfaces!
Soon I will reinstall the OS; Ventoy just released a version that fixed one of the issues that affects Fedora.
@Ricky-Tigg : If I'm reading your last post correctly, you ran ssh-audit -dvc twice on the same machine? If so, then the first instance successfully bound to 2222/tcp, and the second failed since 2222/tcp was already taken by the first instance. This would be correct behavior.
Otherwise, I'm not understanding what you did. The output of your netstat -atpn | grep LISTEN | grep python3 command shows that python3 is properly listening on 0.0.0.0:2222 as well as :::2222.
To refresh | At sshaudit.com copied client-scan expression and pasted in console produces:
$ ssh -p <port_superior_to_1023> [email protected]
Connection closed by <hexadecimal_address>
and triggers an analyse of my OpenSSH client at At sshaudit.com, with these results: F, 38 %.
PyPi package v.: 2.9.0; therefore i will keep on testing against the master branch. For the first time in the current user session i am going to execute ./ssh-audit.py -dvc and won't iterate it twice.
$ ./ssh-audit.py -dvc
Listening for client connection on port 2222..
Here freezing, While being in this state, in an other terminal TTY:
$ journalctl | grep ssh | grep -iE 'fail|error'
(...) fedora systemd[1744]: app-gnome-gnome\x2dkeyring\x2dssh-1952.scope: Failed to add PIDs to scope's control group: No such process
(...) fedora systemd[1744]: app-gnome-gnome\x2dkeyring\x2dssh-1952.scope: Failed with result 'resources'.
(...) fedora systemd[1744]: Failed to start app-gnome-gnome\x2dkeyring\x2dssh-1952.scope - Application launched by gnome-session-binary.
Here freezing,
This is normal & correct behavior. When you use -c, the tool acts as a server instead and waits for an SSH client to connect. When this connection happens, the tool will analyze the client's security properties. The tool will hang until that connection is made by a client.
While being in this state, in an other terminal TTY:
I don't believe these error messages are related to ssh-audit.
If only I could have the needed insight from these ssh-audit's -d and -v options while ssh-audit is in waiting state, in order to determine the cause that is preventing my OpenSSH client to connect. Yet I wonder how #sunwire's SSH client managed to establish its connection. That journalctl | grep ssh was to demonstrate that ssh-audit was not involved in the issue.
Yes, now however with version 3.1.0, the latest as reported by pip_search ssh-audit; tool at tovictorgarric/pip_search on this platform.
firewalld and selinux disabled. Testing.
- Message: still Listening for client connection on port 2222...
- No entries for
journalctl -u ssh.
$ lsof -i -n -P +c 0 | sed -n '/^COMMAND/ p; /(LISTEN)$/ p'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ssh-audit 5803 _ 3u IPv4 34819 0t0 TCP *:2222 (LISTEN)
ssh-audit 5803 _ 4u IPv6 34820 0t0 TCP *:2222 (LISTEN)
Do you observe the same on Fedora?
That output looks correct. ssh-audit is listening for an incoming client connection on port 2222 on both IPv4 and IPv6.
Now what happens when you run "ssh @.*** -p 2222" on the same machine while ssh-audit is still listening?
Internet connection status: established
$ ssh *@*.* -vvp 2222
OpenSSH_9.3p1, OpenSSL 3.1.1 30 May 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host *.* originally *.*
debug2: match not found
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host *.* originally *.*
debug2: match found
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug2: resolving "*.*" port 2222
ssh: Could not resolve hostname *.*: Name or service not known
Internet connection status: non-established
$ ssh *@*.* -p 2222
ssh: Could not resolve hostname *.*: Temporary failure in name resolution
Github censored the SSH connection string I wrote, because it appeared to be an e-mail address. Try connecting to ssh-audit with "x[at- sign]localhost".
I meant: in one window, run: ssh-audit.py -c -p 2222
Then, in another window, run: ssh x[at-sign]localhost -p 2222
[tty 0]
$ ssh-audit -v -c -p 2222
Listening for client connection on port 2222...
[tty 1]
$ ssh -v x@localhost -p 2222
OpenSSH_9.3p1, OpenSSL 3.1.1 30 May 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to localhost [::1] port 2222.
debug1: Connection established.
debug1: identity file /home/yk/.ssh/id_rsa type -1
debug1: identity file /home/yk/.ssh/id_rsa-cert type -1
debug1: identity file /home/yk/.ssh/id_ecdsa type -1
debug1: identity file /home/yk/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/yk/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/yk/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/yk/.ssh/id_ed25519 type -1
debug1: identity file /home/yk/.ssh/id_ed25519-cert type -1
debug1: identity file /home/yk/.ssh/id_ed25519_sk type -1
debug1: identity file /home/yk/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/yk/.ssh/id_xmss type -1
debug1: identity file /home/yk/.ssh/id_xmss-cert type -1
debug1: identity file /home/yk/.ssh/id_dsa type -1
debug1: identity file /home/yk/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: compat_banner: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:2222 as 'x'
debug1: load_hostkeys: fopen /home/yk/.ssh/known_hosts: No such file or directory
debug1: load_hostkeys: fopen /home/yk/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by ::1 port 2222
[tty 0] At last, something new is happening.
# general
(gen) client IP: ::1
(gen) banner: SSH-2.0-OpenSSH_9.3
(...)
Looks like it worked correctly. The ssh-audit process successfully responded to your client connection.
I must consider as my mistake that I kept on discovering this application by the sole lecture of the ssh-audit -h output. This led me to obfuscate the server-client relation. Therefore I had interpreted that ssh-audit -c would be all that is needed to obtain an analyze of the audit.
P.S. I learned that there was no need to tie the port 2222 to the ssh service, which is done on FirewallD by firewall-cmd --permanent --service=ssh --add-port=2222/tcp.