5

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 :))

Asad R.
  • 208
  • 3
  • 9
  • 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 04:55

2 Answers2

7

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:127.0.0.1:1237,verify=0 exec:bash,pty,stderr,setsid

This will provide nice connect-back terminal with encryption.

Vi.
  • 841
  • 11
  • 19
  • 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 '16 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 '16 at 14:06
  • Nope, I'm trying this on localhost, both sides. – cYrus Feb 28 '16 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 03 '16 at 12:41
4

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.

bonsaiviking
  • 4,420
  • 17
  • 26