Re: [suse-security-announce] SuSE Security Announcement: OpenSSH (SuSE-SA:2002:023)
Am Die, 2002-06-25 um 18.10 schrieb Olaf Kirch:
- if you do not need external access to your SSH daemons, turn off the SSH service on these machine completely, or block external access at the firewall.
- if you do need external access to your SSH daemons, make sure you restrict the hosts that it will talk to by setting appropriate firewall rules.
If, for some reason, you cannot configure your firewall to block external SSH access, you can also restrict access through /etc/hosts.allow;
Hmm - I need to administer a remote machine hosted at a server farm. By no means can I afford to lock myself out of that system by upgrading ssh, as several people have reported on this list. Nor can I use host-based access control reasonably, because I login from a large dialin provider with changing IP address & hostname. I am very certain I am not alone with this problem. Do you have any advice how to proceed ? Being able to install the new version in parallel to the old one and only disable the old one when the new one proves to work would be a nice option. Martin
Martin Wilck wrote:
Hmm - I need to administer a remote machine hosted at a server farm. By no means can I afford to lock myself out of that system by upgrading ssh, as several people have reported on this list. Nor can I use host-based access control reasonably, because I login from a large dialin provider with changing IP address & hostname.
I am very certain I am not alone with this problem. Do you have any advice how to proceed ?
VPN, setup something like vtun (easy but maybe not sooooo secure) or ipsec (not so easy, but littlebit more secure) and disable access to sshd via eth0 or whatever your internet device is and make it only accessable via the VPN device/IP's. Thats IMHO the best solution without fscking up your maschine etc. ;)
Being able to install the new version in parallel to the old one and only disable the old one when the new one proves to work would be a nice option.
thats 'possible'. You can open some shells, restart the sshd after the update, try to make a new login and if it fails, replace the new sshd conf with the old rpm. Or make a copy of the old bin and start it via comandline on another port. HTH Sven btw: today i locked my self out ;) typo in an ip ...
On Tue, Jun 25, 2002 at 09:50:35PM +0200, Martin Wilck wrote:
Being able to install the new version in parallel to the old one and only disable the old one when the new one proves to work would be a nice option.
Convert rpm to cpio (rpm2cpio
extract cpio to /wherever
run: sshd -f /wherever/etc/ssh/new-config-file -p 68
test with: ssh -p 68 <server> ...
Ciao
Jörg
--
Joerg Mayer
On Tue, Jun 25, 2002 at 10:52:46PM +0200, Joerg Mayer wrote:
run: sshd -f /wherever/etc/ssh/new-config-file -p 68
I forgot: fix ipfilters...
test with: ssh -p 68 <server> ...
Ciao
Jörg
--
Joerg Mayer
On Jun 25, Martin Wilck
Being able to install the new version in parallel to the old one and only disable the old one when the new one proves to work would be a nice option. I copied the old one to sshd-x and started it on a different port (sshd-x -p 1022). After that you can experiment with the new version (killall sshd ;). You can't restart the sshd-x after update, because it may fail with the new config file, so be careful or pass it another config file as option. My personal (first try) was to start a vnc server and access it through a box beneath mine. Quite ressource hungry, but works even with totally f*cked up ssh. As far as I can tell, you are safe without md5 passwords enabled (updated a 7.3 box successfully). I'm sure, that suse people are heavily struggling around with the md5 problem and expect a fix soon ...
Markus PS: debian works with md5 and 3.3p1, so a linux fix for the pam problem is at least available (but maybe debian people fixed themselves, and it wasn't with the official 3.3p1) -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
Hi, I had the same problem (zero-tolerance against misconfiguration of sshd because only remote access to server) and found the easiest way is simply using telnetd for the time of updating and testing sshd. Just my 2 pence, Matthias Riese -- Matthias Riese Software Engineer b-novative GmbH Bremen, Germany Phone,Fax: +49 700 2668 2848 WWW: http://www.b-novative.com
participants (5)
-
Joerg Mayer -
Markus Gaugusch -
Martin Wilck -
Matthias Riese -
Sven 'Darkman' Michels