I use my company Windows 7 workstation with personal putty and xming to access the many AIX and Linux servers I must administer.
I ssh -X onto a server via putty and if xming is running in the background I can use any of the xwindows aware applications, for example on AIX smit or mozilla.
This is very productive for me. I also use this method to connect to the SUSE 11.2 vmware clients I manage. Life is good.
Successful access to SUSE
Here I use putty to connect and immediately run yast2
Using username “root”.
Authenticating with public key “rsa-key-20130911”
Last login: Fri Dec 6 09:22:01 2013 from pcmv544.corp.xxxxint.com
lxmv91:~ # cat /etc/SuSE
SuSE-brand SuSE-release SuSEconfig/
lxmv91:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
lxmv91:~ # yast2
** (y2controlcenter-gnome:3551): WARNING **: key not found [/apps/yast-control-center/cc_actions_list]
I can’t paste it here, but I got right into yast2 as I would expect.
Failed access to OpenSuse
Unfortunately OpenSuse 13.1 is configured differently and I can ssh -X in and run yast2. I get the blue colored tty based screen that hard to use.
In this example I exported the DISPLAY value and they tried yast2 and then firefox there is no error but no application screen appears.
login as: root
Authenticating with public key “rsa-key-20130911”
Last login: Fri Dec 6 11:12:22 2013 from pcmv544.corp.xxxxint.com
Have a lot of fun…
lxmv150:~ # cat /etc/os-release
NAME=openSUSE
VERSION=“13.1 (Bottle)”
VERSION_ID=“13.1”
PRETTY_NAME=“openSUSE 13.1 (Bottle) (x86_64)”
ID=opensuse
ANSI_COLOR=“0;32”
CPE_NAME=“cpe:/o:opensuse:opensuse:13.1”
BUG_REPORT_URL=“https://bugs.opensuse.org”
HOME_URL=“https://opensuse.org/”
ID_LIKE=“suse”
lxmv150:~ # yast2
lxmv150:~ # firefox
(process:2776): GLib-CRITICAL **: g_slice_set_config: assertion ‘sys_page_size == 0’ failed
Error: no display specified
lxmv150:~ # export DISPLAY=172.24.5.24:0.0
lxmv150:~ # firefox
(process:2783): GLib-CRITICAL **: g_slice_set_config: assertion ‘sys_page_size == 0’ failed
^C
lxmv150:~ # yast2
^C
I have been trying to determine the differences in the two configs.
I compared the two /etc/ssh/sshd_config files and only difference that stood out was “UsePrivilegeSeparation sandbox”
I am at a loss with this problem. I want to put my personal OpenSuse box on VMWare, and then access from my Win 7 desktop.
I can of course use vnc but I need the flexibility of running only specific application and not an entire remote desktop.
I haven’t had any luck with google searches, I don’t think I am using the correct search term to find the magic bullet.
Hopefully someone here can point me in the right direction.
Regards,
Clem
On 2013-12-06 17:46, clemtaylor wrote:
>
> I use my company Windows 7 workstation with personal putty and xming to
> access the many AIX and Linux servers I must administer.
> I ssh -X onto a server via putty and if xming is running in the
> background I can use any of the xwindows aware applications, for example
> on AIX smit or mozilla.
> This is very productive for me. I also use this method to connect to the
> SUSE 11.2 vmware clients I manage. Life is good.
>
> Successful access to SUSE
> Here I use putty to connect and immediately run yast2
Instead of Putty, you can try “MobaXterm”. It is a single application
with an X server in Windows, enough of it to type yast and run it
graphically.
I don’t know if would solve your problem, though.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I do not believe the problem lies with the device accessing the OpenSuse server. Just now I connected to a Suse server running as a VMware client using vSphere. This gives me true console access, I can run firefox or chrome just as if it were a physical console. I can then ssh -X to my OpenSuse 13.1 system. Here I can run yast2 in a nicer tty mode which is quite usable, but I still have no way to use firefox.
What I want to learn is how to make the necessary configuration changes on OpenSuse 13.1 in ssdd_config or sysconfig.conf or ???.conf that will make it behave like SUSE 11.2. The 13.1 developers have make certain implementation decisions I would like to override. I would like the configuration differences between versions to be a little more transparent.
Thank you for your interest.
Clem
On 2013-12-06 21:36, clemtaylor wrote:
>
> I do not believe the problem lies with the device accessing the OpenSuse
> server. Just now I connected to a Suse server running as a VMware client
> using vSphere. This gives me true console access, I can run firefox or
> chrome just as if it were a physical console. I can then ssh -X to my
> OpenSuse 13.1 system.
Try “ssh -Y” instead :-?
> What I want to learn is how to make the necessary configuration changes
> on OpenSuse 13.1 in ssdd_config or sysconfig.conf or ???.conf that will
> make it behave like SUSE 11.2. The 13.1 developers have make certain
> implementation decisions I would like to override. I would like the
> configuration differences between versions to be a little more
> transparent.
I can not try now that where I are. Tomorrow I’ll try to reproduce.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
Hi,
Have you tried running firefox with the commandline option -no-remote?
When I ssh to a different machine and type firefox I get another window of the firefox I running of the machine where I’m comming from. But when I type firefox -no-remote I get a firefox window from the remote server.
How I know the difference? Because the firefox on the remote server is a different version than the one that is running on my laptop. 
P.s.
Great that you also work on AIX. I miss my Power systems :’(
On 2013-12-07 00:44, Carlos E. R. wrote:
> On 2013-12-06 21:36, clemtaylor wrote:
>>
>> I do not believe the problem lies with the device accessing the OpenSuse
>> server. Just now I connected to a Suse server running as a VMware client
>> using vSphere. This gives me true console access, I can run firefox or
>> chrome just as if it were a physical console. I can then ssh -X to my
>> OpenSuse 13.1 system.
>
> Try “ssh -Y” instead :-?
>
>> What I want to learn is how to make the necessary configuration changes
>> on OpenSuse 13.1 in ssdd_config or sysconfig.conf or ???.conf that will
>> make it behave like SUSE 11.2. The 13.1 developers have make certain
>> implementation decisions I would like to override. I would like the
>> configuration differences between versions to be a little more
>> transparent.
>
> I can not try now that where I are. Tomorrow I’ll try to reproduce.
Ok, I have a virtual machine on vmware running 13.1, the guest. The host
is 12.3.
I do the testing with a simple app, “xeyes”, and “gkrellm”. Not yast,
because if it thinks there is no X, it goes to text mode. Not firefox,
because it runs the local firefox instead, not the remote: it wants to
be clever. Yes, I know of the switch, but better to run a simple X app
for demo: xeyes. Or “gkrellm” (gkrellm displays the machine name).
It works in both directions. I use “ssh -Y user@targetmachine”, and it
runs on both machines, no problems.
My config is the default one in the guest, except for one entry:
/etc/ssh/sshd_config:
MaxAuthTries 12
I don’t know why exactly, but without that I can not connect any of my
machines, whatever system they run.
I’ll try a virtual machine with win XP if I can install MobaXterm on it,
later.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2013-12-08 01:03, Carlos E. R. wrote:
> I’ll try a virtual machine with win XP if I can install MobaXterm on it,
> later.
I did it, and it works fine. I also tried “yast2 --qt &” in Windows, and
it worked :-))
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Hi, I don’t know if you’ve solved the problem yet, but I’ve seen that OpenSUSE 13.1 installation has generated the following files with the wrong access permissions (you can see and change them from root account only):/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_rsa_key
They should have 0600 permissions, but they have 0640 instead… the only private key with the correct permission is /etc/ssh/ssh_host_ecdsa_key, but it seems that PuTTY does not handle it correctly (as MobaXterm and TeraTerm do).
bye!