Unable to listen/no connection with podman
rugk opened this issue · 3 comments
I assume you need to expose the port (obviously) then, but it seems I needed to do something wrong here:
podman run -p 1234:1234 --rm -it ghcr.io/rub-nds/terrapin-scanner --listen localhost:1234
Listening for incoming client connection on localhost:1234
In another terminal:
$ ssh 127.0.0.1 -p 1234
kex_exchange_identification: read: Connection reset by peer
Connection reset by 127.0.0.1 port 1234
System
Fedora Workstation 39 (39.20240219.0)
$ podman run -p 1234:1234 --rm -it ghcr.io/rub-nds/terrapin-scanner --version
Terrapin Vulnerability Scanner v1.1.3
$ ssh -V
OpenSSH_9.3p1, OpenSSL 3.1.1 30 May 2023
tl;dr
Running this instead of your podman command should make the scanner available for your SSH client to connect to:
podman run -p 127.0.0.1:1234:1234 --rm -it ghcr.io/rub-nds/terrapin-scanner --listen 0.0.0.0:1234
Specifying localhost:1234
as the listen address for the scanner when running it inside a container will cause it to listen for incoming connection on the container's localhost
, which is different from your host system's localhost
. To fix this, it should be sufficient to specify --listen 0.0.0.0:1234
instead, which will cause the scanner to listen on all of the container's interfaces (including the published port). Note that in this case, -p 1234:1234
will make the scanner available on the network (assuming your firewall is not blocking it). Binding to the host system's localhost
can be done via -p 127.0.0.1:1234:1234
.
Thanks a lot! This works, indeed.
$ podman run -p 127.0.0.1:1234:1234 --rm -it ghcr.io/rub-nds/terrapin-scanner --listen 0.0.0.0:1234
Listening for incoming client connection on 0.0.0.0:1234
================================================================================
==================================== Report ====================================
================================================================================
Remote Banner: SSH-2.0-OpenSSH_9.3
ChaCha20-Poly1305 support: true
CBC-EtM support: false
Strict key exchange support: true
The scanned peer supports Terrapin mitigations and can establish
connections that are NOT VULNERABLE to Terrapin. Glad to see this.
For strict key exchange to take effect, both peers must support it.
Note: This tool is provided as is, with no warranty whatsoever. It determines
the vulnerability of a peer by checking the supported algorithms and
support for strict key exchange. It may falsely claim a peer to be
vulnerable if the vendor supports countermeasures other than strict key
exchange.
For more details visit our website available at https://terrapin-attack.com
Maybe the docs could be improved here… Otherwise, my question is answered.
That's nice to hear. I've added a paragraph to the README explaining how to set up the scanner for docker-based client scanning.