HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- X11 forwarding problem
Operating System - OpenVMS
1827477
Members
2080
Online
109965
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-24-2004 12:12 PM
05-24-2004 12:12 PM
hi,
X11 forwarding is a standard feature in SSH v2.
According to the TCPIP/SSH manual it is configured by setting AllowX11Forwarding yes
in SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG.; config file.
Now ssh v2 sessions should have X11 forwarding supported - it means that X applications should be tunnelled over SSH connection to client host X display.
It is important to note that DISPLAY should not be set. It will cause that X communication will not go through SSH tunnel, but beside, and will be unencrypted.
DEC AXPVMS TCPIP V5.4-15 on an OpenVMS V7.3-2 works as it should during initial SSH session:
ALPHAF_ZAY_PRIV $ sh disp
%DECW-W-OPENIN, error opening alphaf.essnet.se:13.0 as input -SYSTEM-F-IVDEVNAM, invalid device name
Even if display reports warning. DISPLAY is "valid" and it is possible top start some X application. For example:
ALPHAF_ZAY_PRIV $ cre/term/deta
Let examine the DISPLAY variable in new, child window:
ALPHAF_ZAY_PRIV $ sh disp
%DECW-W-OPENIN, error opening DECW$DISPLAY as input -SYSTEM-W-NOSUCHDEV, no such device available
There is no DISPLAY. It was not inherited from parent session, therefore next attempt will fail:
ALPHAF_ZAY_PRIV $ cre/term/deta
%DECW-E-CANT_OPEN_DISPL, Can't open display
If we set up DISPLAY in child session, then it is possible to use X applications, but they go unencrypted beside the SSH tunnel.
This behaviour is always reproducible and cause serious security problems dfor sensitive X applications.
Do I something wrong or it is "just" a bug?
Thank you in advance.
Regards, Z
X11 forwarding is a standard feature in SSH v2.
According to the TCPIP/SSH manual it is configured by setting AllowX11Forwarding yes
in SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG.; config file.
Now ssh v2 sessions should have X11 forwarding supported - it means that X applications should be tunnelled over SSH connection to client host X display.
It is important to note that DISPLAY should not be set. It will cause that X communication will not go through SSH tunnel, but beside, and will be unencrypted.
DEC AXPVMS TCPIP V5.4-15 on an OpenVMS V7.3-2 works as it should during initial SSH session:
ALPHAF_ZAY_PRIV $ sh disp
%DECW-W-OPENIN, error opening alphaf.essnet.se:13.0 as input -SYSTEM-F-IVDEVNAM, invalid device name
Even if display reports warning. DISPLAY is "valid" and it is possible top start some X application. For example:
ALPHAF_ZAY_PRIV $ cre/term/deta
Let examine the DISPLAY variable in new, child window:
ALPHAF_ZAY_PRIV $ sh disp
%DECW-W-OPENIN, error opening DECW$DISPLAY as input -SYSTEM-W-NOSUCHDEV, no such device available
There is no DISPLAY. It was not inherited from parent session, therefore next attempt will fail:
ALPHAF_ZAY_PRIV $ cre/term/deta
%DECW-E-CANT_OPEN_DISPL, Can't open display
If we set up DISPLAY in child session, then it is possible to use X applications, but they go unencrypted beside the SSH tunnel.
This behaviour is always reproducible and cause serious security problems dfor sensitive X applications.
Do I something wrong or it is "just" a bug?
Thank you in advance.
Regards, Z
Solved! Go to Solution.
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-24-2004 08:09 PM
05-24-2004 08:09 PM
Solution
I can explain some of the DECwindows behaviour.
>ALPHAF_ZAY_PRIV $ sh disp
>%DECW-W-OPENIN, error opening alphaf.essnet.se:13.0 as input -SYSTEM-F-IVDEVNAM, invalid device name
If you do a SHOW LOGICAL DECW$DISPLAY I expect you will see it defined as
"alphaf.essnet.se:13.0"
DECwindows allows you to use DECW$DISPLAY as either a WS* display device or a string. The SHOW DISPLAY command only copes with display devices and not string format.
It looks like starting a terminal won't pass a display logical as string to the created terminal.
If you do a:
SET DISPLAY/CREATE/NODE=alphaf.essnet.se/server=13/screen=0
then you should be connected through the secure channel thereafter.
You will need a command file that can parse the display string into its parts to set this display device since the server number may vary between invocations.
Regards,
Martin Kirby
>ALPHAF_ZAY_PRIV $ sh disp
>%DECW-W-OPENIN, error opening alphaf.essnet.se:13.0 as input -SYSTEM-F-IVDEVNAM, invalid device name
If you do a SHOW LOGICAL DECW$DISPLAY I expect you will see it defined as
"alphaf.essnet.se:13.0"
DECwindows allows you to use DECW$DISPLAY as either a WS* display device or a string. The SHOW DISPLAY command only copes with display devices and not string format.
It looks like starting a terminal won't pass a display logical as string to the created terminal.
If you do a:
SET DISPLAY/CREATE/NODE=alphaf.essnet.se/server=13/screen=0
then you should be connected through the secure channel thereafter.
You will need a command file that can parse the display string into its parts to set this display device since the server number may vary between invocations.
Regards,
Martin Kirby
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2004 07:10 AM
05-25-2004 07:10 AM
Re: X11 forwarding problem
Thank you... it works as you described.
Regards, Z
Regards, Z
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Support
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP