Anton Aylward wrote:
Maybe socat could do the job? http://www.dest-unreach.org/socat/ There's this example: <quote> socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork \ SOCKS4:host.victim.org:127.0.0.1:6000,socksuser=nobody,sourceport=20
The problem is not in establishing a normal X11 based session w/o encryption. There are various levels of problems some of which I have workarounds for. The first and easiest is "simple X (& no GLX ) -- That one I just need the name of the remote system. The solution with socat would also need the remote system name. That is made available to pam during authentication by ssh. After that it is no longer available. the "pam_env" module can translate that remote host into an ENV var (aka "REMOTE_HOST") via the config file in /etc/security/pam_env.conf. with the line: REMOTEHOST DEFAULT="" OVERRIDE=@{PAM_RHOST} (or alternatively:) REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST} This is only available when 'ssh' make contact with the system. The problem her, is that OpenSuse's "pam" maintainer arrogated the usage of pam_env from it's previous once/system-auth role to using it as a lazy way to re-initialize per-session state. Unfortunately, in that it doesn't save the previous REMOTEHOST or DISPLAY, it fails preserve what is necessary for the new session to be useful. AFAIK, the only value saved between sessions is the antiquated, but still useful 'TERM' setting. The intent, clearly is to preserve display settings, but this isn't an option in the su program (though it is configurable in the 'sudo' program). Any other program that starts a new session in Suse, will, by default clear your DISPLAY and REMOTEHOST settings. The workaround there, is to undo inserting pam_env into the /etc/pam.d session files and have it only in the 'auth' section. But that's now, a non-standard configuration in OpenSuse (though standard in the rest of the world). ----------------------------------- The *second* main problem which is the focus of my current problems, is that GLX also needs to run remotely. It has the ability to do so, but is not doing so. The *third* main problem is that with the implementation of using "session" based settings, vs. "home-directory" based settings, all settings are based on a local system DBUS connection -- which again -- doesn't exist if you are logged in remotely. *EVEN* if you have a local dbus (are running under Cygwin, for example, under windows), DBUS wasn't designed for remote usage and I have yet to come up with a config that will allow the remote system to use my LOCAL dbus -- something that would often be more useful: Example: remote application wants to open a URL: Would be far preferable for it to be opened via my local browser, rather than trying to run the same browser via 'X' on the remote system. Without the DBUS connection, settings in applications are not saved between invocations. Saving state in wireshark -- no longer works. Saving options in firefox -- no longer works. They are all looking to store info on the session DBUS connection. which doesn't work remotely. linux systems which used to have stellar options to work on remotely, are slowly having their abilities eroded which will make it much harder to use in mixed platform environments (like most of the world). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org