[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tip: Upgrading the SSH Daemon
- To: Yotam Rubin <yotam(at-nospam)makif.omer.k12.il>
- Subject: Re: Tip: Upgrading the SSH Daemon
- From: Tzafrir Cohen <tzafrir(at-nospam)technion.ac.il>
- Date: Fri, 28 Dec 2001 17:21:42 +0200 (IST)
- Cc: Linux-IL <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <20011228144508.GA11669@makif.omer.k12.il>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
On Fri, 28 Dec 2001, Yotam Rubin wrote:
> On Fri, Dec 28, 2001 at 01:33:39PM +0200, guy keren wrote:
> >
> > On Fri, 28 Dec 2001, Yotam Rubin wrote:
> >
>
> Don't CC me, I read all the lists I'm subscribed to.
>
> > > That's not necessary. sshd is forked for every incoming connection. It is
> > > possible to connect to ssh, shut down the listening process and the session
> > > will remain unharmed. Then you would go about installing sshd as normal,.
> > > there's no reason to run two listening sshd's concurrently.
> >
> > that is necessary, since if your active connection(s) die (e.g. the box
> > gets rebooted due to power outage, or something similar) during the
> > process - you're _possibly_ locked out, in case your new install isn't
> > done properly.
>
> Consider the following:
> (It is presumed that you're using system's native packaging system to do
> the update )
Not in this case, actually. Redhat does not have ssh for 6.2, and
rebuilding a redhat 7.x package on redhat 6.2 may not be trivial. In this
case the new copy was installed from source.
>
> 1) You fetch the source package and the new upstream code.
> 2) You add the new upstream code to the source and generate the package.
[alternatively: you fetch the package]
> 3) You install the package. (note that during this entire procedure, ssh is
> still running and listening)
What if the new copy installs to whare the old copy used to be?
(binary, config files, libraries, docs (if the man pages have changed...))
> 4) You invoke '/etc/init.d/ssh restart' (Or where ever ssh's wrapper script
> is located)
>
> The only way this can leave your machine without an ssh process is if the
> init script exits after stopping ssh. The above procedure is as risky as
> doing /etc/init.d/ssh remotely.
Or if something went wrong in the installation procedutre (that is: too
wrong).
Actually I have made a number of updates of sshd in Mandrake 7.2 using
Mandrake's packages. In all cases the upgrade proved to be as easy as 'rpm
-Uv' I kept an ssh session open and put telnet up just-in-case.
> >
> > shlomi's doing things the same way. you and nadav are doing things the
> > careless way. you'll get there faster if it works, but shlomi has a
> > smaller 'Tochelet' (how's that called in english), if you account for both
> > successfull and unsuccesfull installations.
This is a slowr and more complex way. In this spesific example speed was
also a facter (an active exploit). Also keep in mind that if you need to
change your firewall configuration (open another port) then there is a
possible place for locking yourself out of the machine.
>
> The probability that the above procedure will fail is identical to the
> probability that an evil lepracaun will consume your file system, i.e.,
> not extremely likely.
>
> Best regards, Yotam Rubin
>
> >
> > the good and carefull remote (sometimes also local) sysadmin will use
> > shlomi's method for this single reason.
Using ssh as a backup has its drawbacks too. What if both copies happened
to use the same config file (and you didn't notice it)?
Actually using telnet as a backup in this case is not such a bad idea: the
chances that you'll need to use this backup are really small, and you can
be quite sure that it is independent of ssh (unless you screw-up the
networking code).
Not to mention that telnet is a very simple protocol, and much less can go
wrong in it.
--
Tzafrir Cohen
mailto:tzafrir@technion.ac.il
http://www.technion.ac.il/~tzafrir
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il