SSH to Telnet proxy

[Thanasis]

on 03/14/2007 05:43 PM Costas Liagos wrote the following:
> Καλησπέρα,
> αν και το πρόβλημά μου δεν έχει άμεση σχέση με Linux, επειδή όμως
> είμαι σχεδόν βέβαιος ότι σε linux θα υπάρχει λύση, ρωτάω εδώ.
> Το πρόβλημα είναι το εξής:
> Ένας terminal emulator (GLINK) στον οποίο έχουν γραφτεί πολλά
> και διάφορα scripts και ως εκ τούτου δεν είναι εύκολο να πάω σε
> κάτι άλλο (επιπλέον είναι και corporate standard οπότε αν βρω λύση
> θα διευκολύνω και περίπου 5.000 χρήστες ανά τον κόσμο).
> Δυστυχώς υποστηρίζει τα ποιό απίθανα πρωτόκολλα αλλά όχι ssh.
>
> Ένας server για την ευκολότερη χρήση του οποίου είχαν γραφτεί
> πάμπολλα scripts στο glink. Εδώ και κάμποσο καιρό όμως γύρισαν τον
> server σε ssh (έπαιζε με απλό telnet). Το telnet έχει κοπεί τελείως
> (ούτε καν με tunelling μέσα από ssh). Επομένως τα scripts είναι
> πλέον άχρηστα.
>
> Υπάρχει κάποιο s/w το οποίο να κάνει κάτι σαν tunneling και protocol
> conversion ταυτόχρονα, ώστε να ακούει απο τη μια μεριά στο 23
> (ώστε να του μιλάει το glink) και από την άλλη να μιλάει shh
> με τον server; Σκέφτικα το ssh σε tunelling mode αλλά δεν αλλάζει
> το πρωτόκολλο από ssh σε telnet.
> Επίσης δοκίμασα να κάνω patch το ssh αλλά είναι αρκετά μεγάλο
> και λίγο χάθηκα. Στην ανάγκη θα επανέλθω σε αυτή τη λύση αλλά
> φοβάμαι πως με δεδομένο ότι είμαι πολύ φορτομένος το διάστημα αυτό,
> θα μου πάρει πάρα πολύ καιρό και το χρειάζομαι σχετικά άμεσα.
>
> Καμιά ιδέα;
> Το OS στο οποίο θα παίξει η όποια λύση μου είναι αδιάφορο (στη
> χειρότερη περίπτωση ελπίζω να μπορέσω να την κάνω να δουλέψει
> μέσω cygwin).
>
> Κώστας
>
>

OpenSSH is a fantastic tool with a great variety of options and tricks 
available if you're creative enough to figure them all out. For remote 
connections and administration, there is no more flexible and powerful 
tool than OpenSSH.

For instance, assume that you have access to a variety of machines on a 
remote network, but can only get to those systems through a bastion 
host. Suppose that the "gateway" to the remote network is on a machine 
(called /guard/), which allows ssh connections. From that system, you 
are then able to /ssh/ into other systems. However, to obtain any access 
to the other systems, you must always go through /guard/.

A typical login scenario, then, might look like:

[me at myhost]$ ssh guard.example.com

[me at guard]$ ssh work1

If you connect to those other systems (such as /work1/) often, it can 
become tiresome to always connect to /guard/ and then connect to the 
other system. OpenSSH allows us a few tricks to get around this, so you 
can simply do /ssh work1//work1/ system without first logging into 
/guard/. on your home system and log in to the remote

Edit your ~/.ssh/config file. Here you'll add a few lines to get the 
configuration correct.

Host guard guard.example.com

  Hostname guard.example.com

  ForwardAgent yes

  ForwardX11 no

 LocalForward 9001 10.0.2.50:22

  LocalForward 9002 10.0.2.51:22

  LocalForward 9003 10.0.2.52:22

 

Host w1 w2 w3

  ForwardAgent yes

  ForwardX11 no

  Hostname localhost

  NoHostAuthenticationForLocalhost yes

 

Host w1

  Port 9001

 

Host w2

  Port 9002

 

Host w3

  Port 9003

Essentially, what you are doing is setting a few Host configurations to 
allow you to easily connect to the remote work systems, which you will 
nickname "w1", "w2", and "w3" (it doesn't really matter what the remote 
system's name is since you're connecting via the IP address as noted in 
the LocalForward statements). This is all fairly self-explanatory with 
the exception of the "NoHostAuthenticationForLocalhost" keyword. This 
will prevent /ssh/ from complaining each time you connect to one of the 
remote systems; because each connection is through the localhost, yet to 
a different physical machine, /ssh/ will note that the host keys for 
"localhost" keep changing and complain (loudly) without this option.

Now you need to fire up your "master connection", which will be the 
control channel that all connections to the remote systems will travel 
through. This connection is the one that will authenticate to /guard/ 
and remain open:

$ ssh -fMN guard

This will open the master connection in the background and now you can 
connect to those remote systems easily using "ssh w1" or "ssh w2". This 
also allows you to easily /scp/ files from the local system to a remote 
system without copying the files twice: first to /guard/ and from there 
to the remote system.