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"

    Relevant Pages

    • Re: SSH as root
      ... Subject: SSH as root ... but it doesn't require having a key on the server that could be ... If they compromise a server, and the passphrase, etc. is there, they only ... private key to anyone. ...
    • RE: sshd / ssh setup
      ... USA server and his windows/xp notebook to use SSH. ... followed sshd instruction and built ... and require users to submit keys. ...
    • Re: HACKED!
      ... Your PHP script could be inscure and someone could have exploited it ... a little more for a provider that allows sftp and ssh. ... compromise happened because FTP was clear text (someone would have to ... protects you from when someone does root a server so they don't know ...
    • Re: SSH as root
      ... Server A to Server B, that if Server A was compromised, they now own Server ... see how passwords are less secure in anyone's mind, ... >> Passwords are inferior to keys in at least 3 regards: ... > unix passwords is when the same passwordcan be used to compromise ...
    • Debian SSH server configuration
      ... Before you flame me --- I asked this question over in debian-ssh and after 24 hours I didn't have a single hit on it. ... I would like to configure a Debian server to only allow clients to ssh in if the public keys already reside on the hard drives of both machines. ...