After `ssh` without `-X` to a machine, is it possible to change `$DISPLAY` to make it work like `ssh -X`?
After ssh without -X to a machine, is it possible to change some settings (for example $DISPLAY) to make it work like ssh -X? If not, what is the reason? Thanks.
ssh x11
asked Mar 10 at 13:34
TimTim
27.8k78269486
add a comment |
After ssh without -X to a machine, is it possible to change some settings (for example $DISPLAY) to make it work like ssh -X? If not, what is the reason? Thanks.
ssh x11
asked Mar 10 at 13:34
TimTim
27.8k78269486
add a comment |
After ssh without -X to a machine, is it possible to change some settings (for example $DISPLAY) to make it work like ssh -X? If not, what is the reason? Thanks.
ssh x11
asked Mar 10 at 13:34
TimTim
27.8k78269486
After ssh without -X to a machine, is it possible to change some settings (for example $DISPLAY) to make it work like ssh -X? If not, what is the reason? Thanks.
ssh x11
ssh x11
asked Mar 10 at 13:34
TimTim
27.8k78269486
asked Mar 10 at 13:34
TimTim
27.8k78269486
asked Mar 10 at 13:34
TimTim
27.8k78269486
asked Mar 10 at 13:34
TimTim
27.8k78269486
asked Mar 10 at 13:34
TimTim
27.8k78269486
27.8k78269486
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You can create a second connection with X11 forwarding enabled, and then you can also use the DISPLAY environment variable from the second connection in the first.
In the 1st window:
$ ssh user@host
user@host$ ...
In the 2nd window:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Back to the 1st window:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Unfortunately, ssh does nothing to contain the X11 (or other) forwardings to the process/session it started or to the user it runs as on the remote machine (eg. by using Unix sockets with/out checking credentials, or by using namespaces), and those forwardings are simple tcp listening sockets to which anybody on the remote machine can connect; all the security of the X11 forwarding relies on the X11 authentication.
X11 Forwarding By Hand
The sshd_config(5) manpage mentions that:
disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Here is how you can do that by hand.
Show the auth info for DISPLAY=:0 on the local machine:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connect to the remote machine without any X11 forwarding:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Open the command line via ~C and add a remote forwarding from the port 6000+43 to the unix socket corresponding to display :0:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Set the $DISPLAY envvar and add the auth info from the local to the remote machine:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Now you're ready to go:
hzy64$ xterm
answered Mar 10 at 14:37
mosvymosvy
8,3221732
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
Mar 10 at 17:22
8
many (most?) X11 programs don't work with-X, only with-Y. people don't notice that because on many system (eg. debian)ForwardX11Trustedis set toyesby default, and the-Xand-Yoptions are equivalent ;-)
– mosvy
Mar 10 at 17:25
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f505473%2fafter-ssh-without-x-to-a-machine-is-it-possible-to-change-display-to-ma%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can create a second connection with X11 forwarding enabled, and then you can also use the DISPLAY environment variable from the second connection in the first.
In the 1st window:
$ ssh user@host
user@host$ ...
In the 2nd window:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Back to the 1st window:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Unfortunately, ssh does nothing to contain the X11 (or other) forwardings to the process/session it started or to the user it runs as on the remote machine (eg. by using Unix sockets with/out checking credentials, or by using namespaces), and those forwardings are simple tcp listening sockets to which anybody on the remote machine can connect; all the security of the X11 forwarding relies on the X11 authentication.
X11 Forwarding By Hand
The sshd_config(5) manpage mentions that:
disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Here is how you can do that by hand.
Show the auth info for DISPLAY=:0 on the local machine:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connect to the remote machine without any X11 forwarding:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Open the command line via ~C and add a remote forwarding from the port 6000+43 to the unix socket corresponding to display :0:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Set the $DISPLAY envvar and add the auth info from the local to the remote machine:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Now you're ready to go:
hzy64$ xterm
answered Mar 10 at 14:37
mosvymosvy
8,3221732
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
Mar 10 at 17:22
8
many (most?) X11 programs don't work with-X, only with-Y. people don't notice that because on many system (eg. debian)ForwardX11Trustedis set toyesby default, and the-Xand-Yoptions are equivalent ;-)
– mosvy
Mar 10 at 17:25
add a comment |
You can create a second connection with X11 forwarding enabled, and then you can also use the DISPLAY environment variable from the second connection in the first.
In the 1st window:
$ ssh user@host
user@host$ ...
In the 2nd window:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Back to the 1st window:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Unfortunately, ssh does nothing to contain the X11 (or other) forwardings to the process/session it started or to the user it runs as on the remote machine (eg. by using Unix sockets with/out checking credentials, or by using namespaces), and those forwardings are simple tcp listening sockets to which anybody on the remote machine can connect; all the security of the X11 forwarding relies on the X11 authentication.
X11 Forwarding By Hand
The sshd_config(5) manpage mentions that:
disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Here is how you can do that by hand.
Show the auth info for DISPLAY=:0 on the local machine:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connect to the remote machine without any X11 forwarding:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Open the command line via ~C and add a remote forwarding from the port 6000+43 to the unix socket corresponding to display :0:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Set the $DISPLAY envvar and add the auth info from the local to the remote machine:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Now you're ready to go:
hzy64$ xterm
answered Mar 10 at 14:37
mosvymosvy
8,3221732
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
Mar 10 at 17:22
8
many (most?) X11 programs don't work with-X, only with-Y. people don't notice that because on many system (eg. debian)ForwardX11Trustedis set toyesby default, and the-Xand-Yoptions are equivalent ;-)
– mosvy
Mar 10 at 17:25
add a comment |
You can create a second connection with X11 forwarding enabled, and then you can also use the DISPLAY environment variable from the second connection in the first.
In the 1st window:
$ ssh user@host
user@host$ ...
In the 2nd window:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Back to the 1st window:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Unfortunately, ssh does nothing to contain the X11 (or other) forwardings to the process/session it started or to the user it runs as on the remote machine (eg. by using Unix sockets with/out checking credentials, or by using namespaces), and those forwardings are simple tcp listening sockets to which anybody on the remote machine can connect; all the security of the X11 forwarding relies on the X11 authentication.
X11 Forwarding By Hand
The sshd_config(5) manpage mentions that:
disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Here is how you can do that by hand.
Show the auth info for DISPLAY=:0 on the local machine:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connect to the remote machine without any X11 forwarding:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Open the command line via ~C and add a remote forwarding from the port 6000+43 to the unix socket corresponding to display :0:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Set the $DISPLAY envvar and add the auth info from the local to the remote machine:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Now you're ready to go:
hzy64$ xterm
answered Mar 10 at 14:37
mosvymosvy
8,3221732
You can create a second connection with X11 forwarding enabled, and then you can also use the DISPLAY environment variable from the second connection in the first.
In the 1st window:
$ ssh user@host
user@host$ ...
In the 2nd window:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Back to the 1st window:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Unfortunately, ssh does nothing to contain the X11 (or other) forwardings to the process/session it started or to the user it runs as on the remote machine (eg. by using Unix sockets with/out checking credentials, or by using namespaces), and those forwardings are simple tcp listening sockets to which anybody on the remote machine can connect; all the security of the X11 forwarding relies on the X11 authentication.
X11 Forwarding By Hand
The sshd_config(5) manpage mentions that:
disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Here is how you can do that by hand.
Show the auth info for DISPLAY=:0 on the local machine:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connect to the remote machine without any X11 forwarding:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Open the command line via ~C and add a remote forwarding from the port 6000+43 to the unix socket corresponding to display :0:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Set the $DISPLAY envvar and add the auth info from the local to the remote machine:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Now you're ready to go:
hzy64$ xterm
answered Mar 10 at 14:37
mosvymosvy
8,3221732
edited Mar 10 at 17:23
answered Mar 10 at 14:37
mosvymosvy
8,3221732
answered Mar 10 at 14:37
mosvymosvy
8,3221732
answered Mar 10 at 14:37
mosvymosvy
8,3221732
8,3221732
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
Mar 10 at 17:22
8
many (most?) X11 programs don't work with-X, only with-Y. people don't notice that because on many system (eg. debian)ForwardX11Trustedis set toyesby default, and the-Xand-Yoptions are equivalent ;-)
– mosvy
Mar 10 at 17:25
add a comment |
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
Mar 10 at 17:22
8
many (most?) X11 programs don't work with-X, only with-Y. people don't notice that because on many system (eg. debian)ForwardX11Trustedis set toyesby default, and the-Xand-Yoptions are equivalent ;-)
– mosvy
Mar 10 at 17:25
If you care about security,
-X would be slightly better than -Y, wouldn’t it?– Stephen Kitt
Mar 10 at 17:22
If you care about security,
-X would be slightly better than -Y, wouldn’t it?– Stephen Kitt
Mar 10 at 17:22
8
8
many (most?) X11 programs don't work with
-X, only with -Y. people don't notice that because on many system (eg. debian) ForwardX11Trusted is set to yes by default, and the -X and -Y options are equivalent ;-)– mosvy
Mar 10 at 17:25
many (most?) X11 programs don't work with
-X, only with -Y. people don't notice that because on many system (eg. debian) ForwardX11Trusted is set to yes by default, and the -X and -Y options are equivalent ;-)– mosvy
Mar 10 at 17:25
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f505473%2fafter-ssh-without-x-to-a-machine-is-it-possible-to-change-display-to-ma%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
