Summary: Running FC3T1 (updated) Kde desktop Using default run level 3 and `startx' from cli to enter X.
Can someone point me to documentation that spells out the string of events that occur when X is started. In my case I default to run level 3 and `startx' as needed.
In past releases I've always been able to ssh root@localhost from a user xterm in X and the resulting root terminal would be able to run X applications in that users X session. Now I get messages that say things like: Gtk-WARNING **: cannot open display
Depending on which app it is, the warnings differ but always `no access to display' is the punch line.
I'm thinking if I unravel the scripting that startx runs I'll find where somekind of authorization is being invoked. Maybe --nolisten or something similar. I have looked at /etc/X11 scripts like `startx', `xinit' and `Xclients' but am getting really lost as to what is calling what etc.
I hoped somewhere the startup sequence of X in Fedora specifically might be outlined.
PS-setting `xhost +' doesn't seem to have any effect on this.
On Tue, 27 Jul 2004, Harry Putnam wrote:
Summary: Running FC3T1 (updated) Kde desktop Using default run level 3 and `startx' from cli to enter X.
Can someone point me to documentation that spells out the string of events that occur when X is started. In my case I default to run level 3 and `startx' as needed.
In past releases I've always been able to ssh root@localhost from a user xterm in X and the resulting root terminal would be able to run X applications in that users X session. Now I get messages that say things like: Gtk-WARNING **: cannot open display
Depending on which app it is, the warnings differ but always `no access to display' is the punch line.
I'm thinking if I unravel the scripting that startx runs I'll find where somekind of authorization is being invoked. Maybe --nolisten or something similar. I have looked at /etc/X11 scripts like `startx', `xinit' and `Xclients' but am getting really lost as to what is calling what etc.
I hoped somewhere the startup sequence of X in Fedora specifically might be outlined.
PS-setting `xhost +' doesn't seem to have any effect on this.
Have you tried 'ssh -Y root@localhost' ?
Satish
Satish Balay balay@fastmail.fm writes:
I hoped somewhere the startup sequence of X in Fedora specifically might be outlined.
PS-setting `xhost +' doesn't seem to have any effect on this.
Have you tried 'ssh -Y root@localhost' ?
Satish
Nope... I hadn't. Never used it before and had no problem, is it new? Anyway, the -Y flag fixes things for me. ... thanks
Doesn't appear to be new in ssh but I didn't need it in fc1 fc2, so something must have changed.
On Tue, 2004-07-27 at 10:06 -0500, Harry Putnam wrote:
Satish Balay balay@fastmail.fm writes:
I hoped somewhere the startup sequence of X in Fedora specifically might be outlined.
PS-setting `xhost +' doesn't seem to have any effect on this.
Have you tried 'ssh -Y root@localhost' ?
Satish
Nope... I hadn't. Never used it before and had no problem, is it new? Anyway, the -Y flag fixes things for me. ... thanks
Doesn't appear to be new in ssh but I didn't need it in fc1 fc2, so something must have changed.
Something has changed - FC2 ssh doesn't even recognize "-Y" flag.
Phil
On Tue, Jul 27, 2004 at 10:06:49AM -0500, Harry Putnam wrote:
Doesn't appear to be new in ssh but I didn't need it in fc1 fc2, so something must have changed.
The upstream behavior has always been to disable X11 forwarding by default. As of 3.8 and later, the packages in Raw Hide stopped overriding that in the system-wide configuration files.
The subthread: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00317.html
The full thread: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00316.html
HTH,
Nalin
Nalin Dahyabhai nalin@redhat.com writes:
The subthread: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00317.html
The full thread: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00316.html
Thanks for that.
Maybe this other problem regarding ssh I've been noticing is related. In past releases I've been able to put the appropriate pub id's in an ~/.ssh/authorized_keys file and start the ssh-agent while starting X.
Then all my xterms have ssh-agent running. In the past that meant when I called `xterm -e ssh root@localhost' it just started an root xterm with no login. The ssh-agent handled it.
I've exchanged the pub id's between $user and root .ssh/authorized_keys files. and I know it is done right because it works to remote hosts where I've put the same authorized_keys file. However, when I call ssh root@localhost I'm still queried for password.
On Tue, Jul 27, 2004 at 11:45:40AM -0500, Harry Putnam wrote:
Maybe this other problem regarding ssh I've been noticing is related. In past releases I've been able to put the appropriate pub id's in an ~/.ssh/authorized_keys file and start the ssh-agent while starting X.
How were you doing this?
Then all my xterms have ssh-agent running.
How are you verifying that?
In the past that meant when
I called `xterm -e ssh root@localhost' it just started an root xterm with no login. The ssh-agent handled it.
I've exchanged the pub id's between $user and root .ssh/authorized_keys files. and I know it is done right because it works to remote hosts where I've put the same authorized_keys file. However, when I call ssh root@localhost I'm still queried for password.
Hmm. Works from here. Does running ssh with the -v flag give any indication why pubkey authentication fails? When you're prompted for a password, is ssh requesting your login password or the passphrase to your private key?
Nalin
Nalin Dahyabhai nalin@redhat.com writes:
On Tue, Jul 27, 2004 at 11:45:40AM -0500, Harry Putnam wrote:
Maybe this other problem regarding ssh I've been noticing is related. In past releases I've been able to put the appropriate pub id's in an ~/.ssh/authorized_keys file and start the ssh-agent while starting X.
How were you doing this?
But creating a file authorized_keys that contains host_reader@/home/reader/.ssh/id_rsa.pub (and id_dsa.pub host_reader@/root/.ssh/id_rsa.pub (and id_dsa.pub)
Then puting that same file in /home/reader/.ssh and /root/.ssh (along with the public ids for: host_fwobsd@/home/reader/.ssh host_fwobsd@/root/.ssh/id_rsa.pub and id_dsa.pub
Note there is no output from: sudo diff /root/.ssh/authorized_keys \ /home/reader/.ssh/authorized_keys
Then all my xterms have ssh-agent running.
How are you verifying that?
I have written a section in /etc/profile.local.sh (my own invention) that is slurped from /etc/profile if caller is root or reader. That is, at a console login this section is read if user is root or reader. And if that is the case the user is queried for some info. Namely the pass code when ssh-add gets run. Consequently any processes started from that login shell (including startx) have the agent running.
That entry looks like:
#!/bin/sh
## SSH_AGENT setup for certain users ## Ask only non ssh and certain users logins if they want this. ## If answered yes then ssh-agent will be running for ## this shell and any processes it spawns can access ## The ssh-agent variables left in /etc/ssh/local_env/SSH_AGENT_ENV.local SSHAGENT=/usr/bin/ssh-agent SSHAGENTARGS="-s" SSH_ADD=/usr/bin/ssh-add SSH_AGENT_ENV=$HOME/.ssh/SSH_AGENT_ENV
trap "kill -KILL $SSH_AGENT_PID && rm -f $SSH_AGENT_ENV" 0
current_user=$(id -un) if [ $current_user = reader -o $current_user = root ];then if [ ! "$SSH_CLIENT" ];then echo "Do you want an authenticated ssh-agent running?" echo "If yes, type `y <ENTER>'. Anything else will" echo "continue login with out ssh-agent." echo -n "ssh-agent? > " read answer if [ "$answer" = y ];then if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then echo "Passed -z SSH_AUTH_SOCK TEST" echo "Running $SSHAGENT $SSHAGENTARGS into $SSH_AGENT_ENV" echo "and sourcing it" $SSHAGENT $SSHAGENTARGS |tee $SSH_AGENT_ENV . $SSH_AGENT_ENV echo "Now running $SSH_ADD" $SSH_ADD fi fi fi fi
and any xterm I open and type `ssh-agent --list' responds with:
SSH_AUTH_SOCK=/tmp/ssh-ZLkKhp5346/agent.5346; export SSH_AUTH_SOCK; SSH_AGENT_PID=5347; export SSH_AGENT_PID; echo Agent pid 5347;
[..]
Further, if I call ssh reader@fwobsd (a remote machine on home lan) it responds with a terminal (no login)
If I login as root answer the above query and ssh root@fwobsd, it responds with a shell (no login)
Hmm. Works from here. Does running ssh with the -v flag give any indication why pubkey authentication fails?
Not that I notice but the output is appended at the end.
When you're prompted for a password,
is ssh requesting your login password or the passphrase to your private key?
Its requesting a normal login password.
Now, some further info. You may notice in the script above any incoming logins originating from ssh will not be queried and hence will not have ssh-agent running. if [ ! "$SSH_CLIENT" ];then
That is coded that way to avoid having all that querying and other output crop up on real remote ssh logins or worse on scp logins where it would completely dork them (scp).
So you might think then that one would not expect a `ssh root@localhost' to bring up a terminal with ssh-agent running. And it doesn't as evidenced below.
The problem is it used too. Prior to FC3. I haven't changed the script in any way. So in the past the calling user terminal must have passed the agent pid to the new root term. (or something similar)
I'm thinking the way SHELL vars are handled in ssh exchange may have changed as has some other behaviors. Maybe something similar to the new `trusted' variables.
reader $ ssh -v root@localhost OpenSSH_3.8.1p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/reader/.ssh/identity type -1 debug1: identity file /home/reader/.ssh/id_rsa type 1 debug1: identity file /home/reader/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'localhost' is known and matches the RSA host key. debug1: Found key in /home/reader/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Offering public key: /home/reader/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Offering public key: /home/reader/.ssh/id_dsa debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Trying private key: /home/reader/.ssh/identity debug1: Next authentication method: password root@localhost's password:
On Tue, Jul 27, 2004 at 01:05:27PM -0500, Harry Putnam wrote:
But creating a file authorized_keys that contains host_reader@/home/reader/.ssh/id_rsa.pub (and id_dsa.pub host_reader@/root/.ssh/id_rsa.pub (and id_dsa.pub)
Then puting that same file in /home/reader/.ssh and /root/.ssh (along with the public ids for: host_fwobsd@/home/reader/.ssh host_fwobsd@/root/.ssh/id_rsa.pub and id_dsa.pub
Note there is no output from: sudo diff /root/.ssh/authorized_keys \ /home/reader/.ssh/authorized_keys
Please double-check the permissions on the respective users' ~/.ssh directories and ~/.ssh/authorized_keys files. Both should be readable by root, and neither should be group-writable.
and any xterm I open and type `ssh-agent --list' responds with:
SSH_AUTH_SOCK=/tmp/ssh-ZLkKhp5346/agent.5346; export SSH_AUTH_SOCK; SSH_AGENT_PID=5347; export SSH_AGENT_PID; echo Agent pid 5347;
[..]
I don't think this does what you think it does. Try 'ssh-add -l' to query the list of keys which your current agent holds.
HTH,
Nalin
Nalin Dahyabhai nalin@redhat.com writes:
Please double-check the permissions on the respective users' ~/.ssh directories and ~/.ssh/authorized_keys files. Both should be readable by root, and neither should be group-writable.
ssh writes the *.pub keys at 644 itself
A ssh -vv would have revealed those kinds of problems... ls -l .ssh total 36 -rw-r--r-- 1 reader reader 4298 Jul 25 17:06 authorized_keys -rw-r--r-- 1 reader reader 3600 Mar 4 06:01 authorized_keys~ -rw------- 1 reader reader 744 Mar 4 06:16 id_dsa -rw-r--r-- 1 reader reader 614 Mar 4 06:16 id_dsa.pub -rw------- 1 reader reader 951 Mar 4 06:15 id_rsa -rw-r--r-- 1 reader reader 234 Mar 4 06:15 id_rsa.pub
and any xterm I open and type `ssh-agent --list' responds with:
SSH_AUTH_SOCK=/tmp/ssh-ZLkKhp5346/agent.5346; export SSH_AUTH_SOCK; SSH_AGENT_PID=5347; export SSH_AGENT_PID; echo Agent pid 5347;
[..]
I don't think this does what you think it does. Try 'ssh-add -l' to query the list of keys which your current agent holds.
I think it does... All I expected it to show was that the instant xterm knows the ssh-agent pid and hence which socket to talk to.
Further I know for certain any xterm I start in my desktop can handle a remote ssh login under agent control because I do it constantly. If the agent wasn't running then sshing to remote mach fwobsd would result in a login prompt but does not. Either from $user or root account. But just for good measure:
ssh-add -l 1024 96:c0:59:ac:53:56:21:3c:6c:33:36:30:00:e1:b7:50 /home/reader/.ssh/id_rsa (RSA) 1024 f2:5c:c8:20:6a:3b:33:1e:35:45:c9:3d:6d:18:42:e2 /home/reader/.ssh/id_dsa (DSA)
What is puzzling here is why it acts different now under FC3. echo $SSH_CLIENT
On Wed, Jul 28, 2004 at 05:06:04AM -0500, Harry Putnam wrote:
Nalin Dahyabhai nalin@redhat.com writes:
Please double-check the permissions on the respective users' ~/.ssh directories and ~/.ssh/authorized_keys files. Both should be readable by root, and neither should be group-writable.
ssh writes the *.pub keys at 644 itself
A ssh -vv would have revealed those kinds of problems... ls -l .ssh total 36 -rw-r--r-- 1 reader reader 4298 Jul 25 17:06 authorized_keys -rw-r--r-- 1 reader reader 3600 Mar 4 06:01 authorized_keys~
[snip]
What are the permissions on /root/.ssh and /root/.ssh/authorized_keys?
and any xterm I open and type `ssh-agent --list' responds with:
SSH_AUTH_SOCK=/tmp/ssh-ZLkKhp5346/agent.5346; export SSH_AUTH_SOCK; SSH_AGENT_PID=5347; export SSH_AGENT_PID; echo Agent pid 5347;
[..]
I don't think this does what you think it does. Try 'ssh-add -l' to query the list of keys which your current agent holds.
I think it does... All I expected it to show was that the instant xterm knows the ssh-agent pid and hence which socket to talk to.
I believe you're mistaken -- that launched a new copy of ssh-agent.
Further I know for certain any xterm I start in my desktop can handle a remote ssh login under agent control because I do it constantly. If the agent wasn't running then sshing to remote mach fwobsd would result in a login prompt but does not. Either from $user or root account. But just for good measure:
ssh-add -l 1024 96:c0:59:ac:53:56:21:3c:6c:33:36:30:00:e1:b7:50 /home/reader/.ssh/id_rsa (RSA) 1024 f2:5c:c8:20:6a:3b:33:1e:35:45:c9:3d:6d:18:42:e2 /home/reader/.ssh/id_dsa (DSA)
Are you able to connect to the root account remotely using pubkey authentication?
Nalin
Nalin Dahyabhai nalin@redhat.com writes:
Malin, instead of jumping me thru hoops in post after post how about just saying whats on your mind here.
On Wed, Jul 28, 2004 at 11:02:44PM -0500, Harry Putnam wrote:
Nalin Dahyabhai nalin@redhat.com writes:
Malin, instead of jumping me thru hoops in post after post how about just saying whats on your mind here.
Harry, I'm not trying to be difficult. If I'm coming across that way, I apologize.
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'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). 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.
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.
HTH,
Nalin
Nalin Dahyabhai nalin@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@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@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@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@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.
On Tue, Jul 27, 2004 at 10:06:49AM -0500, Harry Putnam wrote:
Nope... I hadn't. Never used it before and had no problem, is it new? Anyway, the -Y flag fixes things for me. ... thanks
Doesn't appear to be new in ssh but I didn't need it in fc1 fc2, so something must have changed.
I might be mistaken, but I think it was added to ssh 3.8, where the X stuff is divided into "safe" and "unsafe", and you can allow ones while dissallowing the others, in some short experimenting I did, I found that for most uses you need both, so it looks kind of worthless (but I don't know the underlying details...), you can enable them by default in the ssh_config, or keep using that flag.
Carlos
Carlos Villegas villegas@math.gatech.edu writes:
I might be mistaken, but I think it was added to ssh 3.8, where the X stuff is divided into "safe" and "unsafe", and you can allow ones while dissallowing the others, in some short experimenting I did, I found that for most uses you need both, so it looks kind of worthless (but I don't know the underlying details...), you can enable them by default in the ssh_config, or keep using that flag.
Enable what?
On Wed, Jul 28, 2004 at 11:16:02AM -0500, Harry Putnam wrote:
Carlos Villegas villegas@math.gatech.edu writes:
I might be mistaken, but I think it was added to ssh 3.8, where the X stuff is divided into "safe" and "unsafe", and you can allow ones while dissallowing the others, in some short experimenting I did, I found that for most uses you need both, so it looks kind of worthless (but I don't know the underlying details...), you can enable them by default in the ssh_config, or keep using that flag.
Enable what?
The ForwardX11Trusted option, I believe.
Nalin