Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm often asked by friends to help with small Linux problems, and more often than not I'm required to login to the remote system. Usually there are a lot of issues with making an account and logging in (sometimes the box is behind a NAT device, sometimes SSHD isn't installed, etc.) so I usually just ask them to make a connect-back shell using netcat (nc -e /bin/bash ). If they don't have netcat I can just ask them to grab a copy of a statically compiled binary which isn't that hard or time consuming to download and run.

Though this works well enough for me to enter simple commands, I can't run any apps that require a tty (vi, for example) and can't use any job control functions. I managed to bypass this issue by running in.telnetd with a few arguments within the connect-back shell that would assign me a terminal and drop me to a shell. Unfortunately in.telnetd isn't usually installed by default on most systems.

What's the easiest way to get a fully functional connect-back terminal shell without requiring any non-standard packages?

(A small C program that does the job would be fine as well, I just can't seem to find much documentation on how a TTY is assigned/allocated. A solution that doesn't require me to plough through the source code for SSHD and TELNETD would be nice :))

share|improve this question
SSHd (imho) should be considered a default package on any linux install, if your friend doesn't have it, then I'm guessing Ubuntu which does have VNC as default (System -> Preferences -> Remote Desktop). If we redefined your question as "How can I connect to SSH/VNC on a remote box behind NAT, when I can't configure port forwarding?" would that be OK for you, 'cos I can answer that pretty easily :) – BuildTheRobots Jan 14 '10 at 22:07
SSH reverse (port) forwarding FTW! – BuildTheRobots Jan 15 '10 at 4:55
up vote 3 down vote accepted

With the caveat that unencrypted shells across the Internet are a bad thing, this pentestmonkey post has some techniques that can be used to get a TTY over an existing shell session. The most likely to work on any system uses Python:

python -c 'import pty; pty.spawn("/bin/sh")'

Replace the shell with one of your choice.

share|improve this answer

It is not a standard program, but "socat tcp:your-host:1234 exec:bash,pty" will do the work.

You can also secure your communication with OpenSSL with socat:

# Your side:
openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
socat `tty`,raw,echo=0 openssl-listen:1237,reuseaddr,cert=cert.pem,verify=0

# Their side:
socat openssl-connect:,verify=0 exec:bash,pty,stderr,setsid

This will provide nice connect-back terminal with encryption.

share|improve this answer
Cool! But I get 2016/02/26 23:18:43 socat[22243] E SSL_connect(): error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small on "Their side". Any ideas? – cYrus Feb 26 at 22:19
Maybe something like different versions of libraries? Try playing with socat ssl-related options and with openssl options for generating the key/certificate. – Vi. Feb 28 at 14:06
Nope, I'm trying this on localhost, both sides. – cYrus Feb 28 at 19:08
OK the point was to generate dhparam.pem with openssl dhparam -out dhparam.pem 1024 and pass it to socat using the dhparam= option. – cYrus Mar 3 at 12:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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