Solved ssh proxy jump not working

[jbo@]

Given the following scenario:

                          +
             "Internet"   |   Server network
                          |
    +-------+         +---+---+          +-------+
    |       |         |       |          |       |
    |   A   +---------+   B   +----------+   C   |
    |       |         |       |          |       |
    +-------+         +---+---+          +-------+
                          |
                          |
                          +

I'd like to connect from host A to host C using SSH with host B as a jump server/proxy.
I can successfully connect from host A to host B and I can successfully connect from host B to host C.

In order to use host B as a jump server/proxy tried to use the -J option of ssh:
ssh -J user_b@b.host.com:22 user_c@192.168.1.5
Where 192.168.1.5 is an interface of host C from which B can successfully connect to.
Unfortunately, I am getting an error that indicates that some name resolution failed:

$ ssh -J user_b@b.host.com:22 user_c@192.168.1.5:22
Enter passphrase for key '/home/xxx/.ssh/id_ed25519':
channel 0: open failed: connect failed: Name does not resolve
stdio forwarding failed
kex_exchange_identification: Connection closed by remote host

Unfortunately I had a hard time figuring out what's going on here. Could somebody point me towards the correct direction? What am I missing?
As mentioned I can successfully connect from host A to host B (using public key authentication) and I can successfully connect from host B to host C (using password authentication). Therefore, I am not sure what resolving operation would fail: b.host.com can definitely be resolved (it's of course a place holder for the sake of the forum) and the connection from host B to host C shouldn't require any name resolving.

Does host B require any special configuration to make this happen?

 

[SirDice]

Remove the :22. There's no reason to supply a port (22 is the default) and it's syntactically wrong too. It gets included as part of the hostname causing resolving errors.

 

[jbo@]

You're very right about that. Without the :22 it works as expected.
I rechecked the documentation and I think I got biased when reading about the -L option which I was investigating at first.