That's a normal case for port forwarding over ssh.
<ip> has ssh endpoint opened and an application server listening on Telnet port 23.
A client has an application client which should connect to
<ip>:23. Also client has nothing listening on port 23.
Let's establish port forwarding from server to client:
ssh -N -L 23:127.0.0.1:23 user@<ip> >/dev/null 2>&1 &
- connect to the server
<ip> as user
- put ssh session into background;
- redirect ssh session's output into /dev/null to avoid any messages on console;
- forward port 23 from the server's localhost to the client (your application server should listen on all IP interfaces, including 127.0.0.1)
Now application client should connect to the address
127.0.0.1:23 to work with the application server.
As per explanations, we have a telnet only capable client software and ssh only capable server. And client should be able to access the server.
As it happens, such solution does exist. From manual:
In the Telnet-DeleGate (DeleGate server for Telnet clients), a host name prefixed with "-ssh" and "." (as "-ssh.host") implies a SSH server on the host. In access to such a server, Telnet-DeleGate works as a gateway between the SSH server and a Telnet client. For example, using a Telnet-DeleGate configured like follows, Telnet clients can login to a SSH server on host as user as follows:
% delegated -P8023 SERVER=telnet://-ssh
% telnet -l user@host localhost 8023