How do I prevent ssh remote login from breaking dbus?
up vote
9
down vote
favorite
I'm running openSUSE 11.3 on my workstation at work under KDE, I don't have root access to it. The default shell has been set to tcsh
. When I am logged in at my workstation and log in remotely from my MacBook running OS X 10.6 using ssh
, like so:
ssh -X -C user@workstation.edu
everything works fine; however, once I'm done, I get DBUS errors on my workstation session whenever I try to launch anything with a GUI, including, unfortunately, the logout dialog box from the task bar panel. I'm getting tired of killing startkde
just to logout in these situations.
Online I've found a lot of instructions for connecting to an existing dbus session using ssh, but I'd like to do the opposite, leave the existing dbus session completely untouched by the ssh remote login session.
If I do
ssh -X -C user@workstation.edu dbus-launch konsole
that works, so it's only the interactive login shell that's breaking dbus. How should I modify ~/.cshrc
? Keep in mind that I don't have permission to modify /etc/cshrc
, /etc/login
, etc.
I can list the contents of those files here, if necessary.
Update:
Here is a big tar file with all the scripts I could find:
http://dl.dropbox.com/u/17203983/cshrc.tgz
ssh kde opensuse tcsh d-bus
add a comment |
up vote
9
down vote
favorite
I'm running openSUSE 11.3 on my workstation at work under KDE, I don't have root access to it. The default shell has been set to tcsh
. When I am logged in at my workstation and log in remotely from my MacBook running OS X 10.6 using ssh
, like so:
ssh -X -C user@workstation.edu
everything works fine; however, once I'm done, I get DBUS errors on my workstation session whenever I try to launch anything with a GUI, including, unfortunately, the logout dialog box from the task bar panel. I'm getting tired of killing startkde
just to logout in these situations.
Online I've found a lot of instructions for connecting to an existing dbus session using ssh, but I'd like to do the opposite, leave the existing dbus session completely untouched by the ssh remote login session.
If I do
ssh -X -C user@workstation.edu dbus-launch konsole
that works, so it's only the interactive login shell that's breaking dbus. How should I modify ~/.cshrc
? Keep in mind that I don't have permission to modify /etc/cshrc
, /etc/login
, etc.
I can list the contents of those files here, if necessary.
Update:
Here is a big tar file with all the scripts I could find:
http://dl.dropbox.com/u/17203983/cshrc.tgz
ssh kde opensuse tcsh d-bus
Yes, please post the contents of the initialization files that make the difference. Also, please describe precisely what commands break the local session (is it runningdbus-launch konsole
that breaks the local session? Or merely an interactive ssh login where you pressexit
immediately?).
– Gilles
Dec 3 '11 at 23:39
@Gilles Hmm, I tried to edit my question with the contents of the files, but there are too many characters. I will find out how and where I can upload them. In the meantime, dbus-launch konsole does not break the local session, while an interactive ssh login from the command line followed immediately by exit will. In fact, even just doing an rsync also breaks dbus (to me it seems strange that rsync runs the login shell scripts by default, but it does).
– user1079118
Dec 5 '11 at 17:27
Try pastebin.com for large files.
– Gilles
Dec 5 '11 at 18:24
add a comment |
up vote
9
down vote
favorite
up vote
9
down vote
favorite
I'm running openSUSE 11.3 on my workstation at work under KDE, I don't have root access to it. The default shell has been set to tcsh
. When I am logged in at my workstation and log in remotely from my MacBook running OS X 10.6 using ssh
, like so:
ssh -X -C user@workstation.edu
everything works fine; however, once I'm done, I get DBUS errors on my workstation session whenever I try to launch anything with a GUI, including, unfortunately, the logout dialog box from the task bar panel. I'm getting tired of killing startkde
just to logout in these situations.
Online I've found a lot of instructions for connecting to an existing dbus session using ssh, but I'd like to do the opposite, leave the existing dbus session completely untouched by the ssh remote login session.
If I do
ssh -X -C user@workstation.edu dbus-launch konsole
that works, so it's only the interactive login shell that's breaking dbus. How should I modify ~/.cshrc
? Keep in mind that I don't have permission to modify /etc/cshrc
, /etc/login
, etc.
I can list the contents of those files here, if necessary.
Update:
Here is a big tar file with all the scripts I could find:
http://dl.dropbox.com/u/17203983/cshrc.tgz
ssh kde opensuse tcsh d-bus
I'm running openSUSE 11.3 on my workstation at work under KDE, I don't have root access to it. The default shell has been set to tcsh
. When I am logged in at my workstation and log in remotely from my MacBook running OS X 10.6 using ssh
, like so:
ssh -X -C user@workstation.edu
everything works fine; however, once I'm done, I get DBUS errors on my workstation session whenever I try to launch anything with a GUI, including, unfortunately, the logout dialog box from the task bar panel. I'm getting tired of killing startkde
just to logout in these situations.
Online I've found a lot of instructions for connecting to an existing dbus session using ssh, but I'd like to do the opposite, leave the existing dbus session completely untouched by the ssh remote login session.
If I do
ssh -X -C user@workstation.edu dbus-launch konsole
that works, so it's only the interactive login shell that's breaking dbus. How should I modify ~/.cshrc
? Keep in mind that I don't have permission to modify /etc/cshrc
, /etc/login
, etc.
I can list the contents of those files here, if necessary.
Update:
Here is a big tar file with all the scripts I could find:
http://dl.dropbox.com/u/17203983/cshrc.tgz
ssh kde opensuse tcsh d-bus
ssh kde opensuse tcsh d-bus
edited Jan 14 '17 at 22:53
рüффп
75831529
75831529
asked Dec 3 '11 at 15:45
user1079118
493
493
Yes, please post the contents of the initialization files that make the difference. Also, please describe precisely what commands break the local session (is it runningdbus-launch konsole
that breaks the local session? Or merely an interactive ssh login where you pressexit
immediately?).
– Gilles
Dec 3 '11 at 23:39
@Gilles Hmm, I tried to edit my question with the contents of the files, but there are too many characters. I will find out how and where I can upload them. In the meantime, dbus-launch konsole does not break the local session, while an interactive ssh login from the command line followed immediately by exit will. In fact, even just doing an rsync also breaks dbus (to me it seems strange that rsync runs the login shell scripts by default, but it does).
– user1079118
Dec 5 '11 at 17:27
Try pastebin.com for large files.
– Gilles
Dec 5 '11 at 18:24
add a comment |
Yes, please post the contents of the initialization files that make the difference. Also, please describe precisely what commands break the local session (is it runningdbus-launch konsole
that breaks the local session? Or merely an interactive ssh login where you pressexit
immediately?).
– Gilles
Dec 3 '11 at 23:39
@Gilles Hmm, I tried to edit my question with the contents of the files, but there are too many characters. I will find out how and where I can upload them. In the meantime, dbus-launch konsole does not break the local session, while an interactive ssh login from the command line followed immediately by exit will. In fact, even just doing an rsync also breaks dbus (to me it seems strange that rsync runs the login shell scripts by default, but it does).
– user1079118
Dec 5 '11 at 17:27
Try pastebin.com for large files.
– Gilles
Dec 5 '11 at 18:24
Yes, please post the contents of the initialization files that make the difference. Also, please describe precisely what commands break the local session (is it running
dbus-launch konsole
that breaks the local session? Or merely an interactive ssh login where you press exit
immediately?).– Gilles
Dec 3 '11 at 23:39
Yes, please post the contents of the initialization files that make the difference. Also, please describe precisely what commands break the local session (is it running
dbus-launch konsole
that breaks the local session? Or merely an interactive ssh login where you press exit
immediately?).– Gilles
Dec 3 '11 at 23:39
@Gilles Hmm, I tried to edit my question with the contents of the files, but there are too many characters. I will find out how and where I can upload them. In the meantime, dbus-launch konsole does not break the local session, while an interactive ssh login from the command line followed immediately by exit will. In fact, even just doing an rsync also breaks dbus (to me it seems strange that rsync runs the login shell scripts by default, but it does).
– user1079118
Dec 5 '11 at 17:27
@Gilles Hmm, I tried to edit my question with the contents of the files, but there are too many characters. I will find out how and where I can upload them. In the meantime, dbus-launch konsole does not break the local session, while an interactive ssh login from the command line followed immediately by exit will. In fact, even just doing an rsync also breaks dbus (to me it seems strange that rsync runs the login shell scripts by default, but it does).
– user1079118
Dec 5 '11 at 17:27
Try pastebin.com for large files.
– Gilles
Dec 5 '11 at 18:24
Try pastebin.com for large files.
– Gilles
Dec 5 '11 at 18:24
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
Actually dbus session are per machine and per X display.
When you do a remote SSH session, you use a different X11 display (typically localhost:10)
If you kill all dbus and launch it on the SSH session it works... for the SSH session.
But obviously it breaksall other dbus sessions in the machine.
What is needed is to check if a session for the machine+display already exists, if yes use it, if not launch a new dbus for that combination and let the session know about it.
Look at https://unix.stackexchange.com/a/188877/32769 for a bash block you can put in your $HOME/.bash_profile file to do those tests and properly do the right thing.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Actually dbus session are per machine and per X display.
When you do a remote SSH session, you use a different X11 display (typically localhost:10)
If you kill all dbus and launch it on the SSH session it works... for the SSH session.
But obviously it breaksall other dbus sessions in the machine.
What is needed is to check if a session for the machine+display already exists, if yes use it, if not launch a new dbus for that combination and let the session know about it.
Look at https://unix.stackexchange.com/a/188877/32769 for a bash block you can put in your $HOME/.bash_profile file to do those tests and properly do the right thing.
add a comment |
up vote
0
down vote
Actually dbus session are per machine and per X display.
When you do a remote SSH session, you use a different X11 display (typically localhost:10)
If you kill all dbus and launch it on the SSH session it works... for the SSH session.
But obviously it breaksall other dbus sessions in the machine.
What is needed is to check if a session for the machine+display already exists, if yes use it, if not launch a new dbus for that combination and let the session know about it.
Look at https://unix.stackexchange.com/a/188877/32769 for a bash block you can put in your $HOME/.bash_profile file to do those tests and properly do the right thing.
add a comment |
up vote
0
down vote
up vote
0
down vote
Actually dbus session are per machine and per X display.
When you do a remote SSH session, you use a different X11 display (typically localhost:10)
If you kill all dbus and launch it on the SSH session it works... for the SSH session.
But obviously it breaksall other dbus sessions in the machine.
What is needed is to check if a session for the machine+display already exists, if yes use it, if not launch a new dbus for that combination and let the session know about it.
Look at https://unix.stackexchange.com/a/188877/32769 for a bash block you can put in your $HOME/.bash_profile file to do those tests and properly do the right thing.
Actually dbus session are per machine and per X display.
When you do a remote SSH session, you use a different X11 display (typically localhost:10)
If you kill all dbus and launch it on the SSH session it works... for the SSH session.
But obviously it breaksall other dbus sessions in the machine.
What is needed is to check if a session for the machine+display already exists, if yes use it, if not launch a new dbus for that combination and let the session know about it.
Look at https://unix.stackexchange.com/a/188877/32769 for a bash block you can put in your $HOME/.bash_profile file to do those tests and properly do the right thing.
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Mar 8 '15 at 13:53
Pablo Saratxaga
1,6281015
1,6281015
add a comment |
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f25998%2fhow-do-i-prevent-ssh-remote-login-from-breaking-dbus%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
Yes, please post the contents of the initialization files that make the difference. Also, please describe precisely what commands break the local session (is it running
dbus-launch konsole
that breaks the local session? Or merely an interactive ssh login where you pressexit
immediately?).– Gilles
Dec 3 '11 at 23:39
@Gilles Hmm, I tried to edit my question with the contents of the files, but there are too many characters. I will find out how and where I can upload them. In the meantime, dbus-launch konsole does not break the local session, while an interactive ssh login from the command line followed immediately by exit will. In fact, even just doing an rsync also breaks dbus (to me it seems strange that rsync runs the login shell scripts by default, but it does).
– user1079118
Dec 5 '11 at 17:27
Try pastebin.com for large files.
– Gilles
Dec 5 '11 at 18:24