When attempting to connect to the tryhackme provided IP address we get port 22: connection timed out even while our ssh server is active

When I attempt to

ssh -vvv [email protected]

I get the below result while using verbosity 3 -vvv

OpenSSH_9.0p1 Ubuntu-1ubuntu7.1, OpenSSL 3.0.5 5 Jul 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/kali/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/kali/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to [] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address port 22: Connection timed out
ssh: connect to host port 22: Connection timed out

We have verified the ssh server is active w/

sudo systemctl status ssh

ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/ssh.service.d
     Active: active (running) since Fri 2023-01-06 01:45:26 PST; 58min ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
   Main PID: 824 (sshd)
      Tasks: 1 (limit: 2281)
     Memory: 1.6M
        CPU: 17ms
     CGroup: /system.slice/ssh.service
             └─824 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jan 06 01:45:26 ubuntu-22 systemd[1]: Starting OpenBSD Secure Shell server...
Jan 06 01:45:26 ubuntu-22 sshd[824]: Server listening on :: port 22.
Jan 06 01:45:26 ubuntu-22 systemd[1]: Started OpenBSD Secure Shell server.

Then, when we check our LISTENING ports, we find that ::22 is (not sure the proper term yet for this) but configured to 1/init instead of something like 1823/sshd. Below is the following

sudo netstat -tulpn | grep LISTEN

tcp        0      0 *               LISTEN      587/systemd-resolve 
tcp        0      0 *               LISTEN      804/cupsd           
tcp        0      0 *               LISTEN      587/systemd-resolve 
tcp6       0      0 ::1:631                 :::*                    LISTEN      804/cupsd           
tcp6       0      0 :::22                   :::*                    LISTEN      1/init         

So far we have used the below resources, but now I have not found anything further to assist, and kinda stuck. If anybody could provide further assistance that would be fantastic!:





tryhackme ip for reassurance: Tryhackme machine ip

  • Can you explain a bit more please? Are you actually connected to this machine? If you cannot ssh into it, how did you run sudo systemctl status ssh? And, if you are somehow connected to the machine, what is the output of sudo systemctl status sshd? That's the one you want, not ssh.
    – terdon
    Commented Jan 6, 2023 at 11:19
  • 1
    @terdon While most distributions might use sshd.service as the service name of the SSH server, Debian and related distributions do use ssh.service for historical reasons.
    – telcoM
    Commented Jan 6, 2023 at 11:23
  • Ah, thanks @telcoM, I haven't used a Debian-based system in a few years so I seem to have forgotten.
    – terdon
    Commented Jan 6, 2023 at 11:28
  • Edit question to tell us: What is the physical connection (ethernet, virtual machine, etc)? Commented Jan 6, 2023 at 23:52

2 Answers 2


Your ubuntu-22 system is configured to start sshd only when needed, using systemd socket activation. In other words, when no SSH connection attempts have yet been received, the ssh.service will not be started yet: there will be only ssh.socket, which is managed by PID #1/init (which is actually systemd in your case).

When the first SSH connection attempt arrives to port TCP/22, ssh.socket automatically triggers ssh.service to start up and passes the incoming connection to the service. This is why you see

TriggeredBy: ● ssh.socket

in systemctl status ssh output.

Since the SSH service was successfully activated by connection attempts, that means packets from your client system can probably reach the system. But the Connection timed out error indicates that no answer of any kind was received.

This might suggest that you have a firewall configuration problem somewhere: a firewall is set to allow incoming packets to TCP/22 to, but the responses are not allowed back out and are dropped by the firewall.

It might be an overly defensively configured firewall on your client system, a software firewall on the tryhackme virtual machine, or even separately-configurable firewall rules on the cloud service you're using to run your tryhackme.

It might be helpful to run sudo traceroute -T -p 22 to see how far a TCP-based traceroute can get when trying to reach the SSH port on the tryhackme server. If you get responses only from your local host, it's probably your local software firewall; if you get all the way to the router of the tryhackme server, it might be the software firewall on the tryhackme VM; if the responses stop somewhere in between (and there are multiple in-between steps) then it might be the cloud service.


:::22 shows that is is listening on IPv6, port 22. I don't see it listening on IPv4.

You also need to configure the firewall (if on).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .