Track down problem with access to display 0.0

Harry Putnam reader at newsguy.com
Thu Jul 29 11:55:54 UTC 2004


Nalin Dahyabhai <nalin at redhat.com> writes:

> Harry, I'm not trying to be difficult.  If I'm coming across that way, I
> apologize.

Sorry... guess I'm getting crochety in my old age...

> I asked you what the permissions were on the .ssh directory and its
> contents for both users, and you gave me that data for the one of the
> users.

I started out to do that very thing but got side tracked before
completing.  Came back from dinner and posted without all info.

> I'm wondering if the permissions on root's files (or the .ssh
> directory itself) may be incorrect.  The output of "ssh -vv" wouldn't
> tell you that pubkey authentication was denied for that reason because
> it only prints client-side debugging messages (you need to run sshd with
> the "-d" flag to debug the server side).  

Good to know.. But maybe an incoming ssh -vv from a remote would show
something?  I'll try that in a moment.

> Attempting pubkey authentication from another system with the same
> key would be one way of ruling that possibility out, because if that
> is indeed the problem, then pubkey authentication should fail no
> matter which client system you're coming from.  It works when I try
> it here, so if that's not it, nothing else is jumping out, and
> that's frustrating.

Ahh I see your thining the same thing.   When you first mentioned
permissions I went to /root/.ssh and set it all 0600 to see if it
helped ... didn't seem to,  and  ssh -vv from a remote doesn't mention
anything about permissions.  Looking at an obsd box here, that I
haven't mucked around with, I see how permissions are set by ssh.

So setting my /root/.ssh as follows:

ls -l /root/.ssh
-rw-r--r--  1 reader reader 4298 Jul 28 23:09 authorized_keys
-rw-------  1 root   root   4298 Jul 28 23:00 fwobsd
-rw-------  1 root   root    744 Jul 28 22:58 id_dsa
-rw-r--r--  1 root   root    612 Jul 28 22:58 id_dsa.pub
-rw-------  1 root   root    951 Jul 28 22:58 id_rsa
-rw-r--r--  1 root   root    232 Jul 28 22:58 id_rsa.pub
-rw-r--r--  1 root   root    448 Jul 27 11:18 known_hosts

> I'm telling you that running "ssh-agent --list" doesn't indicate
>whether or not another copy of ssh-agent is running, because the
>ssh-agent program does not recognize a --list flag.  Running
>"ssh-agent --list" just launches another copy of ssh-agent, a copy
>which will go unused.

I see...  well making no claim here at expertise hehe... I see your
much better informed than I am.  I was apparently confusing 
a non existent `ssh-agent --list' with `ssh-add -list'. 

I'm going to step thru my proceedure here in some detail maybe you'll
spot the trouble:

On Machine reader and user root
ssh-keygen -t dsa
ssh-keygen -t rsa

(Putting the keys in the normal place and passwording them the same pw.)

cd .ssh

echo "## machine reader root" >file_to_be_authorized_keys
cat *.pub >> file_to_be_authorized_keys

scp file_to_be_authorized_keys  fwobsd:/root/.ssh
root at fwobsd's password: 
file_to_be_authorized_keys    100%  867     0.9KB/s   00

  (and now ssh to that same remote host)
ssh fwobsd
 (now on remote host fwobsd:

ssh-keygen -t dsa
ssh-keygen -t rsa

(again putting stuff in normal place and passwording both)

cd .ssh
echo "## Machine fwobsd root" >>file_to_be_authorized_keys

cat *.pub >> file_to_be_authorized_keys
mv file_to_be_authorized_keys authorized_keys

 # scp authorized_keys reader:/root/.ssh
root at reader's password: 
authorized_keys          100% 1734     1.7KB/s   00:0

Now both machines have each others authorized_keys

So starting the agent on Machine reader:
(Not sure how much of this is really needed)
 ssh-agent -s > SSH_AGENT_ENV
# . SSH_AGENT_ENV
Agent pid 21705

ssh-add
(enter passphrase)

ssh fwobsd 
(cool... I get logged in with no password or passphrase  prompt)

Ok so this is working as expected
now to ssh in from remote:

(Repeat above proceedure for starting agent on remote fwobsd)

Now sshing in works as expected as well.

==================================================================

Ok now the kicker On machine reader the above proceedure has been done
for user reader  and all works as expected.

Now starting X from that shell with ssh-agent running, starts kde and
any xterms I call up have the ability to ssh seemlessly to user reader
on fwobsd due to being invoked from a terminal with ssh-agent running.  

What prompted my posts here was that a call to root at localhost from
xterm in kde got a password prompt instead of the expected seemless
login.  Whereas in FC2, that didn't happen.

Now trying it `ssh -Y root at localhost'  and I'll be damned if it
doesn't just work as it should.  My problem has disappeared.  Somehow
your prompting me to get more carefull with my reporting and my
consequent complete step thru has fixed the problem.

Incidently... I decided not to leave the trusted stuff in ssh_config.
I guess that is what -Y is for so one can control which incoming ssh
requestes are given X11 forwarding.  And I never want that remotely.

Now we can both call it a day, and many thanks for your persistence
even in the face of my rude behavior.








More information about the fedora-test-list mailing list