On Thu, 2004-09-09 at 09:41 -0400, Andrew Haninger wrote: > > How about, as a service to enable as you are updating SSH remotely from > > the other side of the country to fix the most recent problem security > > problem and need a backup system to get into the server in the event > > that something goes wrong? > Maybe it would work as well, to start a ssh daemon on a high port, > login on that high port, update the current sshd, start it up on port > 22, logout of the high port, login on port 22, and kill the high-port > sshd. > > So, > > [EMAIL PROTECTED] ~] sshd -p 6000 > [EMAIL PROTECTED] ~] ssh [EMAIL PROTECTED] -p 6000 > [EMAIL PROTECTED] ~] [kill sshd running on port 22] > [EMAIL PROTECTED] ~] [make and install new sshd] > [EMAIL PROTECTED] ~] sshd > [EMAIL PROTECTED] ~] ssh [EMAIL PROTECTED] > [kill sshd running on port 6000] > > This would nearly eliminate any danger due to your insecure version of > sshd since it would be running on a non-standard port for a brief > period of time, and you would not be passing any passwords in the > clear.
So the solution to not run a backup telnet server for updating SSH is to run a second, known insecure version of sshd on a different port, presuming of course, that you are allowed to run said sshd on said high port in the first place. Which results in something that sounds a bit like security by obscurity, which is bad. You end up presuming that potential attacker cannot do his thing because you are using ssh on an oddball port. Oh, and not everyone is root for all parts of the network they may be administrating. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
