Bryan,

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
UID PID PPID C STIME TTY TIME CMD
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
UID PID PPID C STIME TTY TIME CMD
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
(560).

# ps -fp 560
UID PID PPID C STIME TTY TIME CMD
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 [mailto:bryan.christ@hp.com]
Sent: April 19, 2005 10:43 AM
To: Foster, Dale
Cc: secureshell@securityfocus.com
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 [mailto:dale.foster@eds.com]
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 [mailto:bryan.christ@hp.com]
Sent: April 18, 2005 8:46 AM
To: secureshell@securityfocus.com
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!