Re: scp. I don't get it

From: Nico Kadel-Garcia (nkadel@bellatlantic.net)
Date: 11/19/02


From: "Nico Kadel-Garcia" <nkadel@bellatlantic.net>
Date: Tue, 19 Nov 2002 00:56:53 GMT


"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
news:3DD943A0.23CEAC7D@daimi.au.dk...
> Nico Kadel-Garcia wrote:
> >
> > You don't understand what I meant, but that's OK, it wasn't completely
> > clear.
> >
> > I have an unsecured public SSH key. I also run tools that ssh to dozens
of
> > machines nightly with an ssh-agent based key, or I ssh to lots and lots
of
> > new machines all the time. Somebody nabs a copy of my public key,
unplugs
> > one of the macines I normally connect to, and runs sshd such that it
permits
> > key forwarding.
>
> First of all the client should refuse to connect because of the changed
> host key. Or at least give you a big fat warning first. And even if the

In some cases you don't have the original hostkey. That was the situation I
once encountered, where machines deployed in the field were connected to
without keys previously being registered as part of a probe script. There
are other situations where it's fairly trivial to get physical access to
machines and steal the machine's hostkeys, which represented a whole other
ball of overly hot soup to swallow.

> attack was possible, I guess it would be possible even without knowing
> the public key beforehand. You might need to modify the sshd source
> first, but I guess it would be possible to get it accepting any key
> provided by the client.

Yeah, but at that point you have to actually install and make work your
modified software. Most crackers are *LAZY*, and don't bother to do
something that sophisticated.

> > I, being an idiot or careless or actually needing to do it,
> > use key forwarding on the client side.
>
> Forwarding the keys to a host without verifying the host key sounds
> stupid, how could trying to hide the public keys help you there?

Because when you try to connect to the host, you fail to connect and know
that it's not the machine you expect to be able to connect to. The previous
storage of the remote target's public keys helps there, but there is a
modest potential risk in leaving your public keys accessible to others. Like
leaving your encrypted password user-readable in /etc/passwd, it lowers the
threshold for crackers in a way that isn't usually necessary.



Relevant Pages

  • Re: Selling Python Software
    ... >schemes that are presumed to let people run code on machines under ... the effect of CPUs' having secret-to-everyone private keys, along with public keys, ... happens in cache memory that you can't reach the address/data busses of, and execution ... Or maybe get law enacted mandating free interoperability. ...
    (comp.lang.python)
  • Re: OpenSSH version question
    ... >I'm using OpenSSH 2.5 or 2.9 on various Linux machines. ... SSH itself ... I have all the appropriate host key files in /etc/ssh. ...
    (comp.security.ssh)
  • OpenSSH version question
    ... I'm using OpenSSH 2.5 or 2.9 on various Linux machines. ... SSH itself ... works OK, but with 2.9, whenever I try to start sshd, I get a wierd ... I have all the appropriate host key files in /etc/ssh. ...
    (comp.security.ssh)
  • Re: Question on SSH configuration in a cluster environment.
    ... >> connect via ssh because of the changed host key. ... > nodes of the cluster. ... > phrased private key that's generated when ssh is first installed. ... simply duplicate the hostkeys among all the machines. ...
    (comp.security.unix)
  • Re: Question on SSH configuration in a cluster environment.
    ... >> connect via ssh because of the changed host key. ... > nodes of the cluster. ... > phrased private key that's generated when ssh is first installed. ... simply duplicate the hostkeys among all the machines. ...
    (comp.unix.solaris)