X11 forwarding under su through ssh
Brian Olmsted
I've been reading through the "Remote X Applications Mini-HOWTO"
(http://www.xs4all.nl/~zweije/xauth-7.html#ss7.2) specifically the scripts
in section 7 of the script and trying to figure some things out...
What I would like to do is be able to have a generic "su" alias for users
such as myself to run the shell of the target user such that I (or others)
can run any type of X11 based command in the shell through ssh with X11
forwarding, not just one command. That is say I want to be able to su to
root for example and run any commands in the shell and then further if I
want to su to another user from root for troubleshooting purposes say and
run an application as them. All back through the ssh tunnel (rather than
back on the X11 ports (600x)).
If I run the xroot version of the scripts without the embedded "-c $*"
option in the command it will give me a root shell where I can run various
X11 program and I can optionally add the "-c command" option like I can on
the command line to regular su but this isn't really that great for a
generic "su" via "cookie" passing.
That is, the "xsu" would seem to allow you to do "user->user", "user->root"
or "root->user" or "user->root->user", etc but I can't get it to it give me
a shell where I could run multiple commands. Also, the ability to do
"su -" or just plain "su" would be nice.
Now I did find this nice and dandy Linux script
(http://fgouget.free.fr/sux/sux-readme.shtml) with lots of options for X11
forwarding via su but it doesn't seem to recognize the ssh cookies properly
(localhost:10.0 vs hostname/unix:10) but I believe this could be worked
around using some grep and cut commands to extract the right cookie to add
into the target user's .Xauthority.
Furthermore, the program seems very specific to the Linux su command syntax
which is different than the Solaris "su" and the script is a little more
elaborate/robust and complex than it needs to be (for my purposes) but has
some of the options I like. I would like to be able to do stuff like "su"
, "su -", "su user", "su - user", "su - user -c command", etc which the
basic xsu could not do (just a pseudo script); but those other options in
the sux program can do would be nice to do as well.
What's the trick to getting sux to work in Solaris (over ssh?) seems like
the su syntax is mangled and also having problems dealing with localhost X11
forwarding in SSH.
I have come up with the necessary parts to extract the right cookie based on
display variable (localhost:##.0) that SSH sets up so it would just be a
matter of modifying the sux script. I do have this piece of code working
in the xsu script (excerpt below) but it will only let me run specific
command and not the target X-user's shell (so that I can run multiple X11
programs at my leisure).
=====================================
--------------------------------------------------------
XAUTH_HOST_DISPLAY="`hostname`""/unix:""`echo $DISPLAY | cut -d":" -f 2 |
cut -d"." -f 1`"
echo $XAUTH_HOST_DISPLAY
xauth list | grep $XAUTH_HOST_DISPLAY | sed -e 's/^/add /' | {
--------------------------------------------------------
[olm8980@sparrow ~]% /sbin/sh
$ echo $DISPLAY
localhost:10.0
$ XAUTH_HOST_DISPLAY="`hostname`""/unix:""`echo $DISPLAY | cut -d":" -f 2 |
cut -d"." -f 1`"
$ echo $XAUTH_HOST_DISPLAY
sparrow/unix:10
$ xauth list | grep $XAUTH_HOST_DISPLAY
sparrow/unix:10 MIT-MAGIC-COOKIE-1 da5c6bc78b4f41e99f328f9442704f2f
$
=====================================
I tried running the sux program (and further modified it try and get it to
work)...
[olm8980@sparrow ~]% ./sux
./sux: TERM=xauth -q remove localhost:10.0 2>/dev/null;: is not an
identifier
[olm8980@sparrow ~]%
---> changed "export VARIABLE=...." to "VARIABLE=.... ; export VARIABLE"
[olm8980@sparrow ~]% ./sux
su: Unknown id: eval $TERM; exec env TERM='vt100'
DISPLAY='localhost:10.0' $SHELL;
[olm8980@sparrow ~]%
not sure what to do about this eval line in the script. I tried modifying
the script ever so slightly so that I could have it pass root as the default
user when not specified but frankly some of the script is a bit confusing at
times.
[olm8980@sparrow ~]% ./sux root
Password:
sh: xauth: not found
sh: xauth: not found
[olm8980@sparrow ~]#
changed script to point to specific path of xauth (/usr/openwin/bin/xauth)
This seems to work (su <user_specified>)
[olm8980@sparrow ~]% ./sux root
Password:
[olm8980@sparrow ~]# xclock
[olm8980@sparrow ~]#
[olm8980@sparrow ~]#
[olm8980@sparrow ~]# exit
however this doesn't.... which seems to be pointing to the localhost X11
forwarding that SSH sets up....
[olm8980@sparrow ~]% ./sux - root
Password:
/usr/openwin/bin/xauth: (argv):1: bad display name "l" in "remove" command
sh: -l: not found
[olm8980@sparrow ~]%
When I don't specify a user id it complains about this but I'm not sure
where in the script is the best place to specifically specify root (default
for su) if none is specified:
[olm8980@sparrow ~]% ./sux -
su: Unknown id: -c
[olm8980@sparrow ~]%
or if I want to just sux... again looks like a problem with the default
user for su but again don't know proper place to put this stuff.
[olm8980@sparrow ~]% ./sux
su: Unknown id: eval $TERM; exec env TERM='vt100'
DISPLAY='localhost:10.0' $SHELL;
[olm8980@sparrow ~]%
These are the other major scenarios I can see myself running:
[olm8980@sparrow ~]% ./sux -c xterm
su: Unknown id: -c
[olm8980@sparrow ~]%
[olm8980@sparrow ~]% ./sux root -c "xterm"
Password:
env: No such file or directory
[olm8980@sparrow ~]%
[olm8980@sparrow ~]% ./sux root -c "/usr/openwin/bin/xterm"
Password:
env: No such file or directory
[olm8980@sparrow ~]% which xterm
/usr/openwin/bin/xterm
[olm8980@sparrow ~]%
[olm8980@sparrow ~]%
[olm8980@sparrow ~]% ./sux - root -c "xterm"
Password:
/usr/openwin/bin/xauth: (argv):1: bad display name "l" in "remove" command
env: No such file or directory
[olm8980@sparrow ~]%
If you guys can help me out that would be greatly appreciated. Thanks in
advance
Brian
Brian Olmsted
[olm8980@sparrow ~]% ./sux otheruser
Password:
/usr/openwin/bin/xauth: timeout in locking authority file
/export/home/olm8980/.Xauthority
/usr/openwin/bin/xauth: timeout in locking authority file
/export/home/olm8980/.Xauthority
[olm8980@sparrow ~]%
[olm8980@sparrow ~]% ./sux --copy-cookies otheruser
xauth: timeout in locking authority file /export/home/olm8980/.Xauthority
xauth: timeout in locking authority file /export/home/olm8980/.Xauthority
Password:
/usr/openwin/bin/xauth: timeout in locking authority file
/export/home/olm8980/.Xauthority
/usr/openwin/bin/xauth: timeout in locking authority file
/export/home/olm8980/.Xauthority
[olm8980@sparrow ~]%
not sure if this is related to the ssh X11 forwarding display not matching
what's in the xuath list....
Again, thanks in advance
Brian
"Brian Olmsted" <NOS...@rogers.com> wrote in message
news:gABib.98122$ko%.62160@news04.bloor.is.net.cable.rogers.com...
Darren Dunham
> also I get the following when I try to become another user:
> [olm8980@sparrow ~]% ./sux otheruser
> Password:
> /usr/openwin/bin/xauth: timeout in locking authority file
> /export/home/olm8980/.Xauthority
Is that on an NFS mount? Root often does not have privleges on NFS
mounts.
As root, can you run 'xauth list'? Is it using ~olm8980/.Xauthority?
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Maximust
>
> I've been reading through the "Remote X Applications Mini-HOWTO"
> (http://www.xs4all.nl/~zweije/xauth-7.html#ss7.2) specifically the scripts
> in section 7 of the script and trying to figure some things out...
>
> What I would like to do is be able to have a generic "su" alias for users
> such as myself to run the shell of the target user such that I (or others)
> can run any type of X11 based command in the shell through ssh with X11
> forwarding, not just one command. That is say I want to be able to su to
> root for example and run any commands in the shell and then further if I
> want to su to another user from root for troubleshooting purposes say and
> run an application as them. All back through the ssh tunnel (rather than
> back on the X11 ports (600x)).
Nobody here is listening to X11 traffic, so I tried everything you want to do
with xon and it all works. Are you sure you need to ssh everything?
Kai Grossjohann
-", and "ssh someuser@somehost", then from there "ssh
otheruser@otherhost", and so on.
Some people consider it a security issue to allow ssh logins as
root, because that means breakers-inš need just one password (the root
password) rather than two (a user password plus the root password)
for remote break-ins. If that's your problem, then perhaps you can
run two instances of sshd, one listening on 127.0.0.1 and allowing
root logins, and the other listening on 0.0.0.0 and forbidding root
logins.
WDYT?
Kai
š Is that a word?
Brian Olmsted
su 8-\
but it doesn't seem to solve the problem of becoming another user from root
which is a bonus of su (i.e for troubleshooting something as them). In the
case of ssh you would need to know the users password to ssh into their id,
so you may as well su directly to their id from your mortal id. In this
case I would have to extract/merge/add/whatever the xauth cookie into their
profile to get it work. :-(
again, yes I don't want any X11 traffic going back on normal X11 ports and
would like it go through the ssh tunnel as designed for the first user in
mind with the future goal of having the firewalls only allowing ssh through
:)
"Kai Grossjohann" <kai.gro...@gmx.net> wrote in message
news:86he2cb...@slowfox.dyndns.org...
Kai Grossjohann
> but it doesn't seem to solve the problem of becoming another user from root
> which is a bonus of su (i.e for troubleshooting something as them). In the
> case of ssh you would need to know the users password to ssh into their id,
> so you may as well su directly to their id from your mortal id. In this
> case I would have to extract/merge/add/whatever the xauth cookie into their
> profile to get it work. :-(
I found that sudo works for becoming another user and still running X
programs. Dunno how it does that. Hm.
Oh! Lookee here. I said "su" (sans "-"), then entered the root
password, then typed xterm, and lo! an xterm.
WDYT?
Kai
Brian Olmsted
taking to mean without based on the dictionary definition ;-) Anyway I was
hoping to simulate a true root login or a true login as another user (as if
I had logged in as them). Wonder if sudo can still do this.
"Kai Grossjohann" <kai.gro...@gmx.net> wrote in message
news:86ismrv...@slowfox.dyndns.org...
Roger Marquis
>Some people consider it a security issue to allow ssh logins as
>root, because that means breakers-inš need just one password (the root
>password) rather than two
You can also leave "PermitRootLogin" set to "no" until you need to
xterm or rsync directly to the root account, change it to "yes"
before running the remote command, and change it back to "no" once
the session is established.
The drawback of this method is that it requires two logins per
session. Not a big deal if security is the goal, except perhaps
when you have to do it several times per day. In that case it might
be easier to leave an ssh/shell/xterm/icon open all day.
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
Brian Olmsted
which will accomodate the specific commands allowing you to do a rsync or
whatever.... I have this working for my rsync/rdist setup but my problem is
trying to get su to work with xauth.
Now, I came across this interesting program written by someone at Sun
supposedly and have been playing with this today:
http://groups.google.com/groups?q=su_cookie.c&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=350EA4D9.3517E8B7%40Sun.COM&rnum=1
"Roger Marquis" <not-fo...@roble.com> wrote in message
news:bmikh0$7sv$1...@news.mainstreet.net...
Brian Olmsted
I R A Darth Aggie
Kai Grossjohann <kai.gro...@gmx.net>, in
<86ismrv...@slowfox.dyndns.org> wrote:
+> Oh! Lookee here. I said "su" (sans "-"), then entered the root
+> password, then typed xterm, and lo! an xterm.
+>
+> WDYT?
That's how it's supposed to work? Consulting 'man su', we see:
The current environment is passed to the new shell. The
value of $PATH is reset to /bin:/usr/bin for normal users,
or /sbin:/bin:/usr/sbin:/usr/bin for the super user.
In summary, when you "su" (and no "su -", which invokes a login shell)
root gets $XAUTHORITY and $DISPLAY preset with the correct values that
will allow the su'd user to connect to your display.
James
--
Consulting Minister for Consultants, DNRC
I can please only one person per day. Today is not your day. Tomorrow
isn't looking good, either.
I am BOFH. Resistance is futile. Your network will be assimilated.
Kai Grossjohann
> what are you using for your sudoers file?
I did something really simple. Hm. Ah, found it. The default file
has this line:
root ALL=(ALL) ALL
I copied it, put in my user name instead of root, and that was it.
You may wish to do something more elaborate.
> you say sans "-" which I'm taking to mean without based on the
> dictionary definition ;-) Anyway I was hoping to simulate a true
> root login or a true login as another user (as if I had logged in as
> them). Wonder if sudo can still do this.
The incantation "/bin/su -" is kind of hardwired into my fingers.
That's always my starting point. I think you can see where the
"without dash" part comes in :-)
Now I switched to FreeBSD, and I'm having to unlearn that, anyway.
su lives in /usr/bin on FreeBSD ;-) Is it bad that I now type "su -"?
Kai