Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Restarting sshd without interruption

0 views
Skip to first unread message

sinister

unread,
Jan 6, 2005, 9:18:09 AM1/6/05
to
I need to change the sshd config file to allow X11 forwarding and then
restart sshd. How can I do this without possibility interrupting users
currently using sshd? If I can't, is there a way to check to see if there
are any live connections?

TIA,

S


Me

unread,
Jan 6, 2005, 9:23:56 AM1/6/05
to
kill -HUP the pid of the main sshd process (the one with a parent ID of 1)

Stefaan A Eeckels

unread,
Jan 6, 2005, 9:22:19 AM1/6/05
to

You can restart sshd without disturbing existing
connections. To avail themselves of X11 forwarding
the users will have to restart their sessions.

Take care,

--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh

Bill Unruh

unread,
Jan 6, 2005, 10:21:42 AM1/6/05
to
"sinister" <sini...@nospam.invalid> writes:

Count how many sshd daemons are running. If more than one then there are
external connections.
ps -ax|grep sshd
Since sshd forks a new version for each connection, you can kill and
restart the original with impunity. It will not affect existing
connections.
However do not do killall sshd since that WILL kill existing connections.
Rather if on a sysv type system do something like
service sshd restart.

Alternatively just send a
kill -HUP
to the main original daemon.
That will tell it to reread the config file.


Thomas Binder

unread,
Jan 6, 2005, 11:00:31 AM1/6/05
to
Hi!

In comp.security.ssh Me <m...@here.co.uk> wrote:
> kill -HUP the pid of the main sshd process (the one with a
> parent ID of 1)

Which is only true if you haven't already used this method since
the initial start of sshd. Once you've HUPed the main daemon, it
will restart itself, causing init (PID 1) becoming the parent of
all sshd processes handling an active connection.

Better use the PID file sshd writes, which is usually somewhere
around /var/run/sshd.pid

Note: All the above assumes OpenSSH - other implementations might
behave differently.


Ciao

Thomas


--
Thomas Binder (Gryf @ IRCNet)
gryf+...@hrzpub.tu-darmstadt.de
PGP-key available on request!

sinister

unread,
Jan 6, 2005, 1:38:01 PM1/6/05
to

"Me" <m...@here.co.uk> wrote in message news:344vvtF...@individual.net...

OK, that worked, thanks.

-S

>


all mail refused

unread,
Jan 6, 2005, 11:03:02 PM1/6/05
to
In article <crjl26$ko4$1...@nntp.itservices.ubc.ca>, Bill Unruh wrote:

>However do not do killall sshd since that WILL kill existing connections.

Particularly on systems where killall signals all processes.

--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
7.031: OnACPower returned value( 0x1 ) which is Equal To 0x1

Darren Tucker

unread,
Jan 8, 2005, 11:27:26 PM1/8/05
to
In article <crjnav$1tu$1...@lnx107.hrz.tu-darmstadt.de>,

Thomas Binder <gryf+...@hrzpub.tu-darmstadt.de> wrote:
>In comp.security.ssh Me <m...@here.co.uk> wrote:
>> kill -HUP the pid of the main sshd process (the one with a
>> parent ID of 1)
>
>Which is only true if you haven't already used this method since
>the initial start of sshd. Once you've HUPed the main daemon, it
>will restart itself, causing init (PID 1) becoming the parent of
>all sshd processes handling an active connection.

Being the untrusting soul that I am, I now use "lsof -i :22" or similar
and pick out the process in the LISTENING state to send the HUP to.

Yes, I have been bitten by wrong pid files or incredibly stupid sshd
startup scripts on remote macines, why do you ask :-?

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Nico Kadel-Garcia

unread,
Jan 9, 2005, 10:37:04 AM1/9/05
to

"Darren Tucker" <dtu...@dodgy.net.au> wrote in message
news:41e0b2ae$0$21142$5a62...@per-qv1-newsreader-01.iinet.net.au...

> In article <crjnav$1tu$1...@lnx107.hrz.tu-darmstadt.de>,
> Thomas Binder <gryf+...@hrzpub.tu-darmstadt.de> wrote:
>>In comp.security.ssh Me <m...@here.co.uk> wrote:
>>> kill -HUP the pid of the main sshd process (the one with a
>>> parent ID of 1)
>>
>>Which is only true if you haven't already used this method since
>>the initial start of sshd. Once you've HUPed the main daemon, it
>>will restart itself, causing init (PID 1) becoming the parent of
>>all sshd processes handling an active connection.
>
> Being the untrusting soul that I am, I now use "lsof -i :22" or similar
> and pick out the process in the LISTENING state to send the HUP to.
>
> Yes, I have been bitten by wrong pid files or incredibly stupid sshd
> startup scripts on remote macines, why do you ask :-?

Yeah, it happens. However, I've used the "/etc/init.d/sshd restart" command
in Linux across several thousand machines at one time, and only had problems
on those machines that had bad hardware and were in the process of failing.


0 new messages