Re: SSH as root

From: Michael Coulter (
Date: 07/05/03

  • Next message: Tim Greer: "Re: SSH as root"
    Date: Fri, 4 Jul 2003 19:16:33 -0700
    To: Tim Greer <>

    On Thu, Jul 03, 2003 at 07:04:21PM -0700, Tim Greer wrote:

    > > On Thu, Jul 03, 2003 at 05:31:17PM -0700, Tim Greer wrote:

    > > > SSH keys can be a bad thing... But I suppose so could plain text
    > passwords
    > > > on a system if someone compromises it.
    > >
    > > Passwords are inferior to keys in at least 3 regards:
    > >
    > > - in the case of a MITM attack a password is compromised, a key is not
    > Yes, but it doesn't require having a key on the server that could be
    > compromised that allows someone to ssh into another server without any
    > effort. Preventing a MITM attack is a good thing, for sure, and this is
    > true anyway, if youthe RSA key fingerprint to tell you it's changed. I
    > guess I thought you were saying you could store the keys for logging right
    > into the other server without prompting for a password. Yes? No? If no,
    > (i.e., you didn't mean setting a password to not prompt for a password for
    > logging into another server), then what I was commenting on my my reply
    > doesn't relate to what you said and you may disregard it. You may know
    > better what I had meant not, with that said. However, if it was what you
    > meant and you don't agree, read on.

    In the case that you have not yet talked to a machine, and are unable to
    verify the host key. Now, assuming someone can MITM you, your password is
    exposed, however if you used keys, private key would not be.

    > > - in the case of the server being compromised the password is compromised,
    > a key is not
    > If they compromise a server, and the passphrase, etc. is there, they only
    > need to get that data, or use it from those files and that server

    For clarity's sake do not refer to the machine that people use the ssh client
    to connect *from* as a server. The passphrase has no business being stored
    anywhere other than in someone's brain. The point still remains, if I setup
    a trojaned sshd on a server. I can obtain people passwords, but not their
    private keys.

    > Not if you don't have a password stored, they'd have to log what you type on
    > the TTY you are logged in on. You have to be there to make it happen, with
    > keys, you can have server after server compromised.

    Stealing a passphrase, stealing a password. You've gained nothing here.
    > Yes, if the server is compromised, but you'd also have to log into the
    > compromised server and SSH into server B, for them to get the password for
    > server B to access server B. You have a chance of noting something wrong on
    > Server A before that happens. Had they stored the keys to log in without a
    > password needed due to keys (this is what I'm speaking of, if you weren't,
    > disregard my comments), then there's no need for them to wait, they just log
    > into Server B and compromise it as well.

    Again, this muddles server and client. Also, it compares well implemented passwords
    to poorly implemented keys.

    > You're entitled to your views on it, but for the reasons mentioned above, I
    > don't agree--assuming you are saying what I thought. After all, once
    > someone compromises a server, perhaps all bets are off for that server,
    > including SSH'ing to another server, but unless you do, they log it and
    > obtain that information before you find the server was compromised or know,
    > then they aren't getting into Server B--that is a pretty good reason for my
    > comment about it, I'd think.
    Well, you are assuming the worst case implementation of keys everywhere, and
    have not addressed where a proper implementation falls short of passwords.

    I hope the message people get is that keys allow you to have a security level
    that has several advantages over passwords when you protect the keys themselves
    with well chosen passphrases. I also hope they have understood from other people's
    replies the problems with implementing them poorly.

  • Next message: Tim Greer: "Re: SSH as root"