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:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
