tunnek

What?

tunnek is a small utility to ssh to one host from another host with non-friendly link between them.

You are on machine A and you want to ssh to machine B. It does not work, for whatever reason, mostly B does not have a public IP address. Same for A.

Solution: machine C, accessible by both machine A and machine B (machines A and C can be the same if machine B can connect to machine A).

You run a server on machine C. It waits for a connection from machine A. Then from machine B. Then on machine A you run "ssh localhost -p <some port>" and it goes to machine B.

Why?

Why not.

And I needed it.

I was supposed to do some stuff on machine B from my machine A. But no ssh access, only some kind of vnc. Machine B has the crappy default graphical user interface of this stupid ubuntu shit which is totally user unfriendly. Me loves fvwm. Hello world tunnek.

Why "tunnek"? Easy: I wanted to type "mkdir tunnel" but typed "mkdir tunnek" instead. So be it. Welcome tunnek.

How?

Run central on machine C. Then run client on machine A. Then run remote on machine B with the key generated on machine A (you need an initial, maybe vnc-based, access to machine B to run remote on it with the key printed on the terminal of machine A). Then ssh localhost -p <port> on machine A will go to machine B.

Note, important: "ssh localhost" must work on machine B.

You can run one central and several machine A/machine B pairs. So you can for example be on your machine A and access machine B1, machine B2, ..., machine Bn, to do whatever you need on those machines. (Machines B1, B2, ..., Bn, need to be able to access machine C, obviously.)

You can also use machine A1, machine A2, ..., machine An, still with the same central. The system is reasonably flexible. Makes you happy? Good. Me too.

Ah, and you can run many many ssh concurrently from machine A to machine B. But wasn't it obvious?

Security?

Once the link between client and remote is created I think it's the same level of security than ssh.

Before the link is created I would say: "security? lol".

So don't use in production. And this tool is for interactive use, don't daemonize it or whatever. You've been warned.

Source

Specifications

Seriously? Yes.

[topology.txt]

version 2026-02-12
                        sshd             sshd
                          |               |
          sshd            | +-------------+
            \             | |
             +          remote(for client 2001)
             |                 |
         remote(client 2000)   +
              \               /
               \             +
                +------+     |
                        \    |
                     8000\   |8000
                          central
                     8001/   |8001
                    +---+    +
                   /          \
                  /           |6143 (port chosen by kernel)
             client          client
                 \2000         |  \2001
                  +---+        |   \
                       \       |    \4321 (port chosen by kernel)
                        ssh    |    ssh
                               |
                             ssh

central always listens port 8001

1 - client starts, creates KEY, connects to central, sends KEY to central, waits for remote
2 - central opens port 8000, waits for remote
3 - remote connects to central on port 8000, sends KEY, if wrong key, central kills connection
    (remote AND client will need to restart)
4 - central creates a link between remote and client
6 - client/remote connected


when ssh happens on client (kernel chooses port xx for ssh source port):

1 - client sends [<port xx> 0] to remote
2 - remote creates a tcp socket (let's call it RS) to 127.0.0.1 port 22
3 - all data from RS on remote is sent to client as [<port xx> <length> <data>]
    and all data from client to remote is sent on RS socket, same format
4 - when remote socket RS dies remote sends [<port xx> -1] to client
  - when ssh on client is killed, client sends [<port xx> -1] to remote
5 - the end receiving [<port xx> -1] kills the ssh central link, deletes link

when remote-central link dies, central kills client-central corresponding link
and vice-versa

messages:
[<port xx> 0] : <port xx> is an integer, 0 too
[<port xx> -1] : <port xx> is an integer, -1 too
[<port xx> <length> <data>]: <port xx> and <length> are integers, <data> is a buffer of
                             bytes, length of buffer: <length>
Integers are sent as 32 bits, little endian.

Note: the code does not handle "integers" as written in the specs. Little endian is supposed, sizeof(int) == 32 is supposed. Too lazy to fix as of now. What was supposed to be a 2-hours hacking session turned out to be a 24-hours painful bug-hunting thing. I'm losing it...


Contact: see this

Created: 2026-02-12
Last update: 2026-02-12 ml>