Bryan,
To help clarify the issue a bit further, I consulted with a
colleague of mine (thanks Trevor!) and various man pages, to assemble
the following explanation.
Once the sshd daemon is started it reads its config files and
listens for connection requests. Upon receipt of a connection request,
the daemon forks, creating a new process (child process). (see fork(2))
The child process is an exact copy of the parent process inheriting
several attributes from the parent including it's environment and all
attached shared memory segments (see shmop(2)).
Config files are *NOT* processed for each new connection because
new sessions are simply copies of the currently running "top level"
daemon and it's environment.
When sshd receives a hangup signal, it rereads its configuration
file, by re-running itself. (see sshd(8))
SUMMARY:
It is the responsibility of the "top level" sshd to fork copies
of itself for each connection, therefore, only the "top level" sshd,
needs to be HUP'ed. This will force it to reread the configuration
files. From that point forward, each new child process created, will
then inherit the new environment/configuration while currently
established connections will remain unchanged.
As far as convenience, IMHO, if you don't have remote access to
the console, it's more convenient than physically going to the server
and more secure than enabling telnet.
Dale Foster
-----Original Message-----
From: Christ, Bryan [mailto:bryan.christ@hp.com]
Sent: April 19, 2005 1:39 PM
To: Foster, Dale
Cc: secureshell@securityfocus.com
Subject: RE: X11 Forwarding
Thanks Dale!!!! You solved it. When I logged in, I received a message
from xauth saying that it had created .Xauthority (it's absence was a
bit of a mystery to me this whole time). My $DISPLAY was also set
properly and I fired up xcalc!
I guess all those forums out there saying that sshd reads the config
file anew after each fork are wrong.
I find all of this a rather incovenient way to restart sshd
Bryan
-----Original Message-----
From: Foster, Dale [mailto:dale.foster@eds.com]
Sent: Tuesday, April 19, 2005 2:18 PM
To: Christ, Bryan
Cc: secureshell@securityfocus.com
3+
Subject: RE: X11 Forwarding
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!
