I found the permit_open option in authorized_keys, but I want the particular user to ssh to the server and automatically telnet to another user and being jail-boxed at the same time. It means something like:

user1@local# ssh user1@remote1

it actually connects to a remote2 telnet port behind a firewall, and user1 is not able to access anything(incl. remote1) behind the firewall.


You would use port forwarding, or a firewall rule (ipchains, or similar). I think you're looking at SSH expecting to do this, but that's not what SSH is for.

  • 1
    Harv is right. There's no reason to use ssh on the first machine. Rather just have the first machine forward any incoming connections, using iptables, to the restricted machine. Then you only have one ssh session and no tunneling. – CarpeNoctem Dec 9 '10 at 9:47
  • Well if I understand well the OP, the reason to use SSH on remote1 THEN telnet on remote2 is that the local <-> remote1 part of the connection is encrypted, which is considerably more secure than just telnet from local to remote2 via remote1 using iptables. – Renik Dec 9 '10 at 17:21
  • @Renik, yeah thats what I mean, but is telnet jailed in? Couldn't I use ^] to escape? – TiansHUo Dec 10 '10 at 3:27

I would not use port forwarding but simply change the initial program run by the ssh user on remote1 to be "telnet remote2" instead of "/bin/bash" or whatever. EDIT : with the "command" option in authorized_keys

Maybe you could elaborate on your use case, though.


Renik already gave you the answer, but do not forget to add some hardening settings to disable port forwarding.

Like this :

command="/usr/bin/ssh user1@remote1",no-port-forwarding,no-user-rc ssh-rsa ... user@host


Leaving aside the user of telnet in a secure environment, I agree with Harv - you're trying to overload SSH. If it were my build, I'd probably put in openVPN for the remote users to connect to remote1, then use iptables to restrict traffic coming out of the tunnel to TCP/23 destined for remote2 (and replies).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.