Lachlan,
Thanks for the further response!
L. Cranswick wrote:
> (Sorry for previous Emails dated 1991 -
No problem!
> On a general discussion on using a passphrase/password based approach:
> A silly question from me. Why would you need both a public file
> and a passphrase?
As I understand things:
Your private key file is stored on your local computer. If your local
computer is totally secure (from physical and networked breakins), no
problem. However, if someone can steal (copy) your private key, they
can pretend to be you in communicating to the system that you gave the
corresponding public key.
My understanding of the passphrase is like a password for your private
key. If you've required a passphrase when you set up the key pair, then
simply stealing the private key doesn't help them, they must also know
your passphrase.
Back to one of your earlier statements:
> (Isn't having private key files like putting your pin
> number with your VISA/Mastercard/Cashcard? If the hacker
> gets into your machine (or a backup tape/cd-rom) and gets
> the private file?)
Now your pin number (passphrase) is not written down on your Visa card
(private key) (unless you store your passphrase in your computer).
One problem with being overly security conscious
> is the same with being overly and unrealistically safety conscious:
> the systems you setup not only take far more effort - but eventually
> some people may start doing things insecurely as they get too annoyed
> with the inconvenience doing things securely.
True, but if you are doing a series of tasks with passwordless ssh, you
need to enter the passphrase only at the beginning of the session.
>
> Good secure systems need to be easy to inplement and easy to
> use - same with work place safety systems. Otherwise mistakes
> may creep in during installation - and people may feel compelled
> to by-pass security due to its unneccessary nuisance value.
Yes, that's why SourceForge encourages the use of passwordless ssh.
Maybe a link there would be helpful -- let me try to find some:
Look at this list of documents:
http://sourceforge.net/docman/?group_id=1
They try perusing this document:
http://sourceforge.net/docman/display_doc.php?docid=3228&group_id=1
A quotation:
"There is a better way. It's called Secure Shell, or SSH. With a proper,
working SSH setup, your transactions with SourceForge will be as secure
as good cryptography can make them -- and you'll never have to type a
password during a CVS or scp operation again."
(That's a pleasant surprise -- it looks like they've finally rewritten
some of that documentation -- it was really painful before -- this looks
reasonable (or better) (or I learned a lot since the last time I tried
to use it. ;-) )
>
> > PS: Thanks for the discussion. From what you've said and other things
> > I've heard before, my impression of chrooting is that you somehow create
> > an "artificial" root account / environment with limited privileges, and
> > somebody that uses this artificial account cannot get to the real root
> > account? Is this close?
>
> I would have thought it was an account with restricted file
> browsing and /or permissions
> and functionality.
I don't think our descriptions are very different, but why, once you
create the account with restricted file permission is it called
"chrooted" -- does the user of the account think it's a root account, or
is it just that it's his "root" account, as a synonym for "home"
account? Must you do something to make the restricted account
"chrooted"? (I guess I'll have to look up "chroot" on google or
similar.)
Thanks again for the discussion!
Randy Kramer
