Linux.com

Home Linux Community Community Blogs Business (or Enterprise) Sudo, SSH, changing to another user, and exporting the display elsewhere

Sudo, SSH, changing to another user, and exporting the display elsewhere

I'm sure that the title is confusing to many.  This article is meant to help users in a very specific workflow:  administrators who have to frequently test applications as other users remotely.  If that's not you, you probably won't get much use out of this posting.

 Here's the scenario:  User jsmith has a GUI application that he needs you to test remotely over SSH.  As an admin, you don't know jsmith's password, but you do have admin rights.  The problem comes when you ssh and su to another user and find that you can no longer export the display back to your workstation.

Warning!  This opens a security hole and should only be used within closed trusted networks.

This works with a few assumptions:

  • You have sudo rights on the remote workstation
  • Your home folder mounts at the remote location (probably not necessary, but that's what I do)
  • You're using NIS (this function is easily modified to just use the local /etc/passwd file instead) 
  • You are willing to accept the security implications of modifying permissions on your .Xauthority file

 Here's the solution that I've come up with.  I've added this to my .zshrc file:

# change2user username
 change2user() {
     echo "Changing permissions on Xauthority file.  (Warning!  This opens a security hole)"
     chmod 644 ~/.Xauthority
     echo -n "Getting user shell...."
     NEWUSERSHELL=`ypcat passwd | grep $1 | awk -F: '{ print \$7 }'`
     echo $NEWUSERSHELL
     XAUTHORITY=$HOME/.Xauthority DISPLAY=$DISPLAY sudo -H -u $1 $NEWUSERSHELL
}

The function opens up access to the .Xauthority file for another user to see, then queries for the target user's shell (jsmith's shell in this case).  It provides feedback so you know which shell you're about to switch to (because I noticed sometimes the $SHELL variable isn't accurate for telling when doing stuff like this).  Next, it sets the XAUTHORITY variable in jsmith's environment to point to YOUR .Xauthority file, as well as setting the display to YOUR ssh display forward.  It then launches the user's shell as jsmith.  Now you just run any GUI application as that user.

 The workflow goes like this:

  1.  ssh -X remoteworkstation
  2. change2user jsmith
  3. Type in sudo password
  4. Execute any program (i.e. xterm)
That's all it takes.  You should now see an xterm for the remote workstation and anything you launch will launch AS that user and on YOUR screen.  I use this a lot for testing CAD packages that my users have trouble with.

 

 

 

Comments

Subscribe to Comments Feed

Upcoming Linux Foundation Courses

  1. LFD331 Developing Linux Device Drivers
    25 Aug » 29 Aug - Virtual
    Details
  2. LFS422 High Availability Linux Architecture
    08 Sep » 11 Sep - Raleigh, NC
    Details
  3. LFS426 Linux Performance Tuning
    08 Sep » 11 Sep - New York
    Details

View All Upcoming Courses


Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board