SSH time out. How to connect to a RHEL 8 instance?

[rnd8273812]

Hello

I have a fresh RHEL 8 installed on VMWare Workstation 15. Network works fine, I can ping both ways but I can't SSH into RHEL. I do ssh user@192.168.1.5 end it's timing out. The SSHD is up and listening on port 22. I can ssh from inside of the machine to another account but never from another host. My question is how to fix it and why logging from outside is disabled by default?

[Scott]

What does your firewalld look like?  Is ssh a permitted service in the active zone?

-STM

[rnd8273812]

[root@rhel ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens160
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

[Scott]

That's what you'd want to see. You don't have anything in the sshd-config that would cause this, like only accepting key-based auth or trying to log in as root, but root logins are disabled?

-STM

[rnd8273812]

No. This is how the system acts by default. Its fresh installation, done and fully updated this morning. I haven't changed anything because I can't connect to the instance and the graphic driver doesn't allow setting hosts native resolution. On 4K screen everything is hardly readable. 

[Lisenet]

The fact that it's timing out suggest it's a firewall issue.

What conenction details do you use when you ssh from inside of the machine?

[rnd8273812]

Its' simply user@localhost or user@127.0.0.1. I can login root-->user and user-->root. It doesn't make any sense. It has to be a lan issue. It's using Bridget connection now, getting it's IP from my router...

[Scott]

I'm inclined to agree with @Lisenet that it's likely something from the outside blocking your ability rather than the ssh or local system configuration.  A couple of other steps to verify that is the case:

on system, ssh user@<system's IP> , if this works, then the interface of the system is able to accept connections to it, but since you're connecting to the system from itself, you're not using your network for the transport layer.  If this fails, then it likely points to a local system config being the problem.

from another system on the same lan segment, ssh user@<system's IP>, if this works then you're able to get to the machine from another system on the same LAN segment.  Typically firewall rules are not applied to local LAN traffic (though this is not always the case).  If this fails, there may be network configuration issues or your router is applying some sort of filtering rules on the LAN segment as well.

-STM

[Lisenet]

To get valid results you need to use valid tests.

Using user@localhost for testing is not the same as using user@192.168.1.5.

It does make sense because the loopback interface does not represent any actual hardware.

[Scott]

Assuming the system's IP is 192.168.1.5, then ssh user@192.168.1.5 also won't use any actual hardware.  the TCP/IP stack will take care of routing the traffic without the traffic touching the NIC equipment.  the main difference is going to be that using the actual IP will still run the traffic through all the local subsystems as though it were recieved on the NIC and transferred into the TCP/IP stack on the system, thereby testing things like firewall, service configuration, et. al.

-STM