Ah, one specific octet per command port, so
you need to nock them in the right order.
Actually, it's one numeric per port, so 12 knocks to build the address.
Still don't see the point to this one.
The reason behind having the server call out, rather than allowing you to call
in, is that it leaves the server with NO listeners on the externally facing
network interface. If there are essentially no listeners, then there's nothing
for hackers to attack.
Also, since the callout is using a public-key authentication method, you have
to have the servers public key already loaded in your authorized_keys file.
I see. Combining this with the first one, you
could spawn an sshd that is bound to the
loopback interface, thus never exposing an
sshd, even for 30 seconds.
I hadn't actually thought of it that way, but it could be used that way.
They really were intended to be 2 different methods of access.
Or am I missing something here ?
You're close, very close. What I was attempting to do, that wasn't done with
normal port knocking implementations, was to transfer data, not via TCP payload
or traditional transport mechanisms, but via the actual knock sequence.
Think of it like morse code, only with 65Kx2 (tcp/udp) different code
components instead of just long and short.
By building information via knock sequences (and using more than one port for
each numeric), you could possibly extend this so that it contains not only the
IP address, but a numeric ID that represents a user who is going to connect
from the stated IP address, as well as a PIN number to use for that connection.
Again, all of this without any form of payload that could be sniffed. It's
just hits to certain ports.
