> From: Tom Holroyd <tomh at po.crl.go.jp> > > > > What he is proposing is for OpenSSH to disregard a system-wide policy > > > decision -- that root should not be permitted to directly log in from > > > the network. There are more reasons to disable remote logins as root > > > (vs. normal login then su) than just to prevent plaintext use of the > > > root password; for example, audit trails for a group of admins or site > > > security policies. This patch would violate the expected behavior of > > > the system. > > As we all know, disabling remote root logins as a security measure is an > old policy from the days before strong authentication methods. As pointed > out above, there *are* other issues, but they also have other solutions. > These days, normal login followed by su is less secure than allowing a > direct root login. > > ssh -l user host > su > <root password exposed to traffic analysis>Erm ... traffic analysis? Where? Ssh is encrypted.
On Fri, Apr 27, 2001 at 11:30:08AM +1000, carl at bl.echidna.id.au wrote:> > As we all know, disabling remote root logins as a security measure is an > > old policy from the days before strong authentication methods. As pointed > > out above, there *are* other issues, but they also have other solutions. > > These days, normal login followed by su is less secure than allowing a > > direct root login. > > > > ssh -l user host > > su > > <root password exposed to traffic analysis> > > Erm ... traffic analysis? Where? > > Ssh is encrypted. >Nothing earth shattering: http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt Guess the lengths of your passwords maybe. -- David Terrell | "The reasons for my decision to quit were myriad, but Nebcorp PM | central to the decision was the realization that there are dbt at meat.net | two kinds of companies: Good ones ask you to think for wwn.nebcorp.com | them. The others tell you to think like them." -Benjy Feen
>vs. > > ssh -l root host > <with hostbased, public key, and SRP> > >and if you want a better audit trail: > > root:x:0:0:root:/root:/bin/sh > fred:x:0:0:root:/root:/bin/sh > joe:x:0:0:root:/root:/bin/sh > frank:x:0:0:root:/root:/bin/sh > >where they all have different passwords (and 'root' has no valid password).First this isn't the correct alias to be disussing the virtues of direct or non direct root login so it is offtopic. This does NOT provide the correct level of auditing because all the uid's are the same. The kernel doesn't know about names it only cares about uids so in systems where the auditing is kernel based this doesn't help you to identify which real person it was. It also increases the vulnerability of the machine because now there are 4 passwords that give access to the root account rather than 1. So the probability of cracking or social engineering attempts has moved in favour of the attacker. As for the traffic analysis argument I though that current OpenSSH snapshots had a fix for that. -- Darren J Moffat
On Fri, 27 Apr 2001 carl at bl.echidna.id.au wrote:> > ssh -l user host > > su > > <root password exposed to traffic analysis> > > Erm ... traffic analysis? Where? > > Ssh is encrypted.Not traffic sniffing - but you can still try to estimate password lengths and infer a few liklihoods about what characters are used through keystroke timings. This may be enough to make a brute-force search tractable. Best read the advisory at http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt OpenSSH tries to prevent such attacks using the methods discussed in the advisory. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer