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 14 hours ago
TimTim
27.6k78264477
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 14 hours ago
TimTim
27.6k78264477
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 14 hours ago
TimTim
27.6k78264477
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 14 hours ago
TimTim
27.6k78264477
asked 14 hours ago
TimTim
27.6k78264477
asked 14 hours ago
TimTim
27.6k78264477
asked 14 hours ago
TimTim
27.6k78264477
asked 14 hours ago
TimTim
27.6k78264477
27.6k78264477
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 13 hours ago
mosvymosvy
8,0721531
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
10 hours ago
3
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
10 hours ago
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 13 hours ago
mosvymosvy
8,0721531
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
10 hours ago
3
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
10 hours ago
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 13 hours ago
mosvymosvy
8,0721531
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
10 hours ago
3
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
10 hours ago
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 13 hours ago
mosvymosvy
8,0721531
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 13 hours ago
mosvymosvy
8,0721531
edited 10 hours ago
answered 13 hours ago
mosvymosvy
8,0721531
answered 13 hours ago
mosvymosvy
8,0721531
answered 13 hours ago
mosvymosvy
8,0721531
8,0721531
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
10 hours ago
3
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
10 hours ago
add a comment |
If you care about security,-Xwould be slightly better than-Y, wouldn’t it?
– Stephen Kitt
10 hours ago
3
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
10 hours ago
If you care about security,
-X would be slightly better than -Y, wouldn’t it?– Stephen Kitt
10 hours ago
If you care about security,
-X would be slightly better than -Y, wouldn’t it?– Stephen Kitt
10 hours ago
3
3
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
10 hours ago
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
10 hours ago
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
