RE: X11 Forwarding

From: Foster, Dale (
Date: 04/19/05

  • Next message: Coleman Kane: "Re: publickey/password login"
    To: "Christ, Bryan" <>
    Date: Tue, 19 Apr 2005 14:18:05 -0500


    I support a large number of servers, and all are remote. Each time we
    make changes to the configuration, we need to restart the sshd daemon.
    The trick is to HUP only the highest sshd process. I sign on to a
    server using ssh, make the required changes. Once I have finished, I
    will usually use "ptree $$"(solaris8+) to find out the PID of the top
    sshd daemon and then "kill -HUP" that process.

    # ptree $$
    1124 /usr/local/sbin/sshd
      23317 /usr/local/sbin/sshd -R
        23320 -sh
          23328 ptree 23320
    # kill -HUP 1124

    If you are running an older version of solaris or another unix OS, it's
    a bit more work but still "doable". First do a "ps -f" to get the PPID
    of the current shell,

    # ps -f
        root 26813 26802 0 12:53:50 pts/5 0:00 -sh
        root 26824 26813 0 12:53:53 pts/5 0:00 ps -f

    Note the PPID of the shell which in my case is "-sh" and the PPID is
    26802. We have to work our way up the tree so next do a "ps -fp 26802"
    where PPID is the number you got from the last invocation of "ps",

    # ps -fp 26802
        root 26802 560 0 12:53:48 ? 0:00 /usr/local/sbin/sshd

    At this point we have what we need. The PPID of this last process (560)
    is the calling SSH daemon that spawns the shells. You don't have to
    take my word for it, just repeat the last command with the new PPID

    # ps -fp 560
        root 560 1 0 Nov 05 ? 0:05 /usr/local/sbin/sshd

    We now know the PID of the calling process, to fork the sshd daemon.

    # kill -HUP 560

    Any *new* sessions will use the current config settings and this will
    *not* affect any currently running sessions.

    WARNING: Use extreme caution when changing settings because if you
    configure an option that isn't supported by that particular version, the
    daemon may just die, killing *all* sshd processes.

    Dale Foster

    -----Original Message-----
    From: Christ, Bryan []
    Sent: April 19, 2005 10:43 AM
    To: Foster, Dale
    Subject: RE: X11 Forwarding

    Thanks for the reply Dale.

    I have learned the hard way that sshd cannot be restarted remotely (sshd
    does not respond to HUP). Apparently, sshd forks a new sshd process
    when a new connection is made and the new sshd process reads the config
    file anew. Therefore, there shouldn't be any need to restart.

    Can anyone confirm this? I've never truly found the definitive answer
    for this.

    -----Original Message-----
    From: Foster, Dale []
    Sent: Tuesday, April 19, 2005 10:21 AM
    To: Christ, Bryan
    Subject: RE: X11 Forwarding

    Have you restarted the sshd since setting "X11Forwarding" to yes?

    Once you log into the "host", what does "echo $DISPLAY" report?

    -----Original Message-----
    From: Christ, Bryan []
    Sent: April 18, 2005 8:46 AM
    Subject: X11 Forwarding

    Does anyone know why my DISPLAY variable is not getting set? I have
    tried looking at the debug messages from

    ssh -vv -X user@host

    but I haven't seen anything suspicious. xauth is installed in the normal
    location and seems to run correctly (although I'm really not familiar
    with it). In my sshd_config file, the relevant options are set as:

    X11Forwarding yes
    X11DisplayOffset 10
    #X11UseLocalHost no
    #UseLogin yes

    I've spent quite a bit of time googling on this problem and haven't come
    up with anything yet. I suspect that it might have something to do with
    installing XFree86 on Slackware 9.0 after initial OS installation (using
    installpkg *.tgz on the relevant packages). I'm really at a loss for
    where to turn.

    Server is OpenSSH 3.5p1, OpenSSL 0.9.7a
    Client is OpenSSH 4.0p1, OpenSSL 0.9.7f

    Thanks in advance!

  • Next message: Coleman Kane: "Re: publickey/password login"