That depends on whether or not the jumphost has access to the post on the internal kali's machine. Let's say your Kali machine has the IP 192.168.1.1, the Jumphost has 10.0.1.1 and the internal Kali machien has 10.0.2.2.
A direct connection is possible
If the Jumphost can connect to 10.0.2.2:8834 and reach the interface (in other words, 10.0.2.2 is configured to allow connections to 8834 from any interface), then you can use the following command:
ssh -L 1234:10.0.2.2:8834 10.0.1.1 # On the local Kali machine
When run on your Kali machine (192.168.1.1), it will connect to the Jumphost 10.0.1.1. Furthermore, any traffic that your local Kali machine sends to its own port 1234, will be forwarded to the SSH tunnel, and from the Jumphost, it will go too 10.0.2.2:8834.
This only works if port 8834 on 10.0.2.2 is reachable from 10.0.1.1!
Of course, you can change the local port number to anything you wish. I just chose 1234 as an example.
A direct connection is NOT possible
In this case, you need to run two tunnels. The concept is the same as before, but this time, we need one tunnel from Kali to the Jumphost, and one tunnel from the Jumphost to the internal Kali machine.
ssh -L 1234:localhost:1234 10.0.1.1 # On the local Kali machine
ssh -L 1234:localhost:8834 10.0.2.2 # On the Jumphost
This basically means: Any traffic received on port 1234 on the local Kali machine will be forwarded to port 1234 on the Jumphost. And any traffic received on port 1234 on the Jumphost will be forwarded to port 8834 on the internal Kali machine.
You probably noticed "localhost" in there. This refers to "localhost" on the receiving machine of the SSH connection. Since these connections will use the loopback interface (127.0.0.1 aka localhost), you will be able to connect to the Nessus UI, even if it is configured to only accept connections from localhost (since, technically, it is a connection coming from localhost; from the sshd process specifically).
So, how do these tunnels work?
I need those ssh tunnels just enough to remember they exist, and not often enough to remember if I need local or remote tunnels.
Local tunnels create a listener on your local machine and forward the data from there to the remote host. The syntax for this would be as follows:
ssh -L localport:remotehost:remoteport targetmachine
ssh -L 443:localhost:8843 10.0.0.1
This will connect to 10.0.0.1 and create a local listener on your machine on port 443, which will forward the data to 10.0.0.1:8843, as if it came from the local interface there. This is useful when, like in your scenario, you want to connect to a port, which is only available on the remote machine.
Remote tunnels create a listener on the remote machine and forward the data from there to your local host. The syntax for this would be:
ssh -R remote:remotehost:remoteport targetmachine
ssh -R 443:localhost:8443 10.0.0.1
This will connect to 10.0.0.1 and create a listener on the remote machine on port 443. Any connection to that port will be forwarded to port 8443 on your localhost. This is useful, if you want to let others connect to your machine, without exposing your machine to the whole network.
Generally speaking, local tunnels are usually what you want.
