[Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15)

Thomas Wouters thomas@xs4all.net
Fri, 21 Jul 2000 07:59:15 +0200

On Thu, Jul 20, 2000 at 08:33:11PM -0400, Donald Beaudry wrote:
> Greg Stein <gstein@lyra.org> wrote,
> > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the
> > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from
> > your local machine to .ssh/authorized_keys on shell.sourceforge.net.
> > 
> > From then on, SF will used the auth'd key rather than asking for your
> > password.

> That's mostly correct, but... you are assuming that the private side
> of the key (.ssh/identity on the local host) has not been encrypted
> with a passphrase.  If it has, the scp command will prompt for it
> instead of the remote password.  When using an encrypted private key
> ssh-agent is the answer.

> Personally, I am pretty paranoid about my private keys so (now ;) I
> always encrypt them.  As a loose rule, I wont give anyone access to my
> systems (accept a public key) unless they at least tell me that their
> private key has been encrypted.

And that's perfectly sensible. I'm not a crypto-junkie in any way, but using
ssh with non-passphrase-protected is dangerous stuff. We do use it, at
XS4ALL, actually, for scripts to execute commands on remote machines, but we
do it with seperate keysets, and restricted per host. Nevertheless, if one
of those private keys ever gets stolen, it's very likely the thief can get
access to semi-sensitive parts of our system.

Using a authorized_keys scheme with an unencrypted private key makes your
private key, something you 'have', your password, without coupling it to
something you 'know'. So anyone who steals your private key can pretend to
be you ;) For more security, I'd suggest a cronjob that connects to your
ssh-agent first, and just bails out if you haven't an ssh-agent running.

(That means a private key is only useful on a machine that also has an
accompanying ssh-agent running, and the 'hacker' can assume your privileges.
This is the case for the common root access hole, but not so if the machine
is rebooted, for instance, to gain that root access, or if it's only a
file-stealing hole instead of a full-access hole ;)

Then again, I'm a system administrator for a high-profile ISP. I might be a
tad paranoid myself ;-P

Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!