Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin1!goblin.stu.neva.ru!nrc-news.nrc.ca!newsflash.concordia.ca!canopus.cc.umanitoba.ca!utnut!news.uwaterloo.ca!not-for-mail From: Carlos Moreno Newsgroups: comp.os.linux.development.apps Subject: Re: Security problem Date: Thu, 01 Sep 2011 15:48:11 -0400 Organization: University of Waterloo Lines: 46 Message-ID: References: <87obz4s142.fsf@araminta.anjou.terraraq.org.uk> NNTP-Posting-Host: cm-16c.uwaterloo.ca Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: rumours.uwaterloo.ca 1314906501 15062 129.97.10.215 (1 Sep 2011 19:48:21 GMT) X-Complaints-To: abuse@uwaterloo.ca NNTP-Posting-Date: Thu, 1 Sep 2011 19:48:21 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 In-Reply-To: <87obz4s142.fsf@araminta.anjou.terraraq.org.uk> Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:256 >> 1. Do *not* allow root login (in sshd_config, which on my >> systems it is located on /etc/ssh/sshd_config) there is the >> PermitRootLogin parameter, commented out --- uncomment it >> and set it to *no* (you can always login as a regular user >> and use sudo, or su to become root) > > Allowing login as a user who can become root is near-enough equivalent > to allowing login as root; moreover given the regular appearance of > privilege-escalation vulnerabilities allowing any user login is likely > to turn to to be equivalent to allowing root login. I guess you have a point --- in fact, I've always seen this as one weaknesses of the sudo setup. Which BTW, if you have a standard sudo setup, then the "PermitRootLogin no" is sort of implicit, in that there is no root password to login with. >> 2. Preferably, put a list of allowed users --- the AllowUsers >> configuration parameter, followed by the user names. (and by >> all means, *do choose good passwords* for these accounts) > > Better still use public-key authentication and disallow password > authentication completely, at least on anything facing a hostile > network. Oops --- I meant to mention this one as well! Even though I sort of have mixed feelings about this technique; the whole Debian OpenSSL atrocity that happened some 3 or 4 years ago left me thinking about ever setting up PK authentication for SSH :-\ I guess my fear is somewhat irrational: it *was* a blatant bug that happened to affect PK authentication; but it could have affected (and who is to say that there may not be some future bugs that do) password authentication as well, or simply affect ssh in a way that it becomes compromised regardless of what types of authentications are enabled.... Suffice it to say .... I've never enabled PK authentication on my servers for more than half-hour or so (when I'm working on something that requires lots of uploads in a short period of time). I guess combining it with using a non-standard port could buy you some peace of mind. Cheers, Carlos --