Several folks have shared some truly worthy possible fixes. I am planning to sort them by my limited grasp of which are practical for me. There seems to be a depth of comprehension above average in our group, which is quite above mine. So, I am asking permission from those who have contacted me off list to post all the collected work. There seems a possibility of refining the best of all these workarounds into dare I propose a new distro? An assembly of all the tool kits and scripts plus a stand alone minimalist distro such as DSL or Puppy. The killer incarnation to me at least might be a package loaded from a website or sent as a mail attach. With a fallback to CD or USB media if connection is an issue.
Under a doctrine of "if you have USB/CD access, permission is presumed - passwords etc can be simplified Thus we refine one path to -nsert media-reboot- automagic configures-and connects -then somehow it grands me remote KVM. An idea I had was a script to capture the IP of the remote livedistro,-have it Email that to me and then telnet etc in
On Thu, Jan 24, 2008 at 05:23:50PM -0600, Oren Beck wrote:
An idea I had was a script to capture the IP of the remote livedistro,-have it Email that to me and then telnet etc in
The problem with that is that telnet is not encrypted so it can be sniffed at least and might be subject to being hijacked.
Never use telnet when ssh is available.
The script I posted to this list connects from the client machine so that firewalls, most allow outgoing connections, will not interfere.
The script goes out to a server you control, logs in as '[email protected]' and adds the client's public key to the .ssh/known_hosts file. After that logins to '[email protected]' will not ask for a password.
It then uses this passwordless login to find the first open port in the range 9110 through 9119, uses the open port to start an ssh port forwarding listener. What that does is allow you to 'ssh -p9110 [email protected]' which connects you, via the loopback interface (127.0.0.1), to port 22 of the client machine.
Port 22 is ssh and responds to incoming connections (the ones blocked by firewalls) and allows login as a non-root user.
So this allows punching through firewalls because both the outgoing login to your server and the ssh tunnel back to the client box are encrypted so those in charge of the firewalls do not know what you are doing and are therefore unlikely to attempt blocking you or the client.
I add -X to the '[email protected]' so X programs can be started on the client box but display on your screen (helps if you have a higher resolution display than clients do, that way you see their entire screen without needing to scroll).
I also add -C to use compression whenever it can because text only uses between five and six bits of information for each byte sent/recieved. (makes low speed links more useable)
I suggest that we set up a 'server' and a few 'clients' at the next meeting on Feb 06. That way you can see that this complex to explain operation runs extemely easily.
-
Ed Allen -
Oren Beck