Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 05:08:32PM +0200, Christian Egli wrote:
> Simon Kirby <email@example.com> writes:
> > Using "su root" later is worse than just logging in as root with a key.
> I cannot understand why using "su root" later would be worse. Can you
> enlighten me?
In all cases, you always depend on the security of the client, whether it
be protecting a key on the filesystem or protecting the keystrokes from
being logged. If the client is compromised, anything can happen,
regardless of if the client has to enter one password, two passwords, a
key with one passphrase, or a key with ssh-agent. So, let us look at the
If the server is compromised, often a password sniffer and/or trojaned
SSH or su daemon will be installed.
With passwords, as soon as the next administrator logs in and enters the
password, via su or via ssh, the password will be decrypted to cleartext
by the server for verification and thus logged. If this password happens
to be used on any other server, the attacker will have access to those
servers (you could have a different password for every server, but often
this does not happen in practice).
With keys, nothing special happens. The server can either allow or
refuse the connection, and logging will accomplish nothing other than
being able to determine the public key (which would already have to be on
the server anyway). The attacker cannot obtain any password or private
This combined with the fact that logging in as root (preferrably with a
key) makes things like "scp" and other non-interactive programs possible
over SSH. I don't see any reason _not_ to log in directly as root.
Logging is the only potential issue, but that can be fixed by altering
the log level in sshd_config. (Remember we're talking about root access
here. Anybody with root access can alter logs and/or transmit decoy
logging entries to remote logging servers, etc., so logs for root logins
aren't really that useful except for the "Alright, who broke it?" case.)
[ Simon Kirby ][ Network Operations ]
[ firstname.lastname@example.org ][ NetNation Communications ]
[ Opinions expressed are not necessarily those of my employer. ]
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org