Thanks Dan!
The offender was a call to setxkbmap in ~/.bashrc. Two calls, in-fact,
hence the two error messages.
As I now realize, disabling X11 forwarding on either client or server
side wouldn't have helped me a bit, right? If any, it would insure that
I'd get the message, because the message is generated by the X-program,
which gets called anyways, and disabling X-forwarding would just make
the X program more angry.
I caught the program fairly quickly. For those with more complicated
setups, I'd suggest the following diagnostic process for identifying the
cause of the problem:
a) invoke sshd from the cmdline, wrapped by strace, tracing exec() and
write() calls:
strace -f -e trace=process,write -o /tmp/sshd.strace /usr/sbin/sshd
b) Reporduce:
amit0 ~ # ssh localhost echo bla
Cannot open display "default display"
bla
c) Look for the PID that's writing the error message:
29350 write(2, "Cannot open display \"default dis"..., 38) = 38
d) Now locate the exec() call relating to that PID:
29350 execve("/usr/bin/setxkbmap", ["setxkbmap"...,
Amit
Dan Nelson wrote:
> In the last episode (May 05), Amit Dor-Shifer said:
>
>> Hi all.
>>
>> I'm using ssh to execute a command on a server. When the remote server
>> has an X server running, I get a/m message written to standard error.
>>
>> amit0 ~ # ssh localhost echo bla
>> Cannot open display "default display"
>> Cannot open display "default display"
>> bla
>>
>> Appending the '-x' parameter, as suggested, doesn't seem to help:
>>
>> amit0 ~ # ssh -x localhost echo bla
>> Cannot open display "default display"
>> Cannot open display "default display"
>> bla
>>
>
> You must have something in one of your shell's startup scripts that is
> trying to access an X display. Adding a "set -x" at the top of your scripts
> will force each line to be printed as it is run, which should help you track
> down the offending commands.
>
>
