I intended this to go back to the list, where it could be commented on if
appropriate...
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Work:<[EMAIL PROTECTED]> Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
---------- Forwarded message ----------
Date: Wed, 14 Feb 2001 01:33:33 -0800 (PST)
From: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
To: Peter Jay Salzman <[EMAIL PROTECTED]>
Subject: Re: [vox-tech] fetchmail and ssh
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 13 Feb 2001, Peter Jay Salzman wrote:
> ok, jeff, call me dumb...
never. does not compute.
>
> On Tue 13 Feb 01, 3:37 AM, [EMAIL PROTECTED] said:
> > On Tue, 13 Feb 2001, Peter Jay Salzman wrote:
> >
> > > ok, i've been at this for awhile; time to get help.
> > >
> > > i'm trying to get fetchmail to send my password securely. this is what i've
> > > tried for .fetchmailrc:
> > >
> > > poll belial.ucdavis.edu with protocol pop3 and port 11110:
> > > preconnect "ssh -f belial.ucdavis.edu -L 11110:belial.ucdavis.edu:110
>belial.ucdavis.edu sleep 20"
> > > password XXXX;
> > >
> > > and:
> > >
> > > poll belial.ucdavis.edu via localhost port 1234 with proto pop3:
> > > preconnect "ssh -f -L 1234:belial.ucdavis.edu:110 belial.ucdavis.edu sleep 20
></dev/null >/dev/null"
> > > password XXXX;
> > >
> > > and a few variations on these two themes. i'm getting the same error message:
> > >
> > > fetchmail: starting fetchmail 5.5.3 daemon
> > > fetchmail: 5.5.3 querying belial.ucdavis.edu (protocol POP3) at Tue Feb 13
>01:09:20 2001
> > > You have no controlling tty. Cannot read passphrase.
> > > fetchmail: pre-connection command failed with status 65280
> > > fetchmail: Query status=5 (SYNTAX)
> > >
> > > i'm sure i have a few hurdles to jump here. the first one is the no
> > > controlling tty one. can someone help me out with this?
> >
> > You must setup an authorization key that allows connections to belial
> > without entering any verification (i.e. have a private key with no
> > passphrase for [EMAIL PROTECTED], have corresponding public key in
> > /home/p/.ssh/authorized_keys). That should get rid of the complaint about
> > no controlling tty.
>
> i've read this a few times, and it still makes no sense to me.
>
> maybe the problem is that i didn't know you CAN have a private key without a
> passphrase. how does one "get one of these"? i can certainly to a
>
> gpg --key-gen
>
> but i really don't want 2 keys if i don't need them. and i don't think
> it'll accept a null passphrase.
I haven't used gpg yet. *duck* I don't know about the interchangeability
of ssh keys with gpg keys, either.
However, I have had no problem using ssh-keygen to make keys without
passphrases.
Your comment does hint at something I find a little odd, though. I don't
use the same private key on more than one system, in case one of them gets
compromised... particularly where one system is more exposed than the
other. That is, I treat the key as the identity of user@host, not
[EMAIL PROTECTED] There probably is value in having a generic
private key for gpg identification, but once the account that contains it
gets cracked, the biggest hurdle in cracking your key is already done.
> isn't there a better option?
I am not sure what you want: to have your cake and eat it too? :)
>From the errors you were seeing, I am assuming you want an automated
mechanism to access services on belial from satan. What is different
between putting a passphrase in a configuration file, versus not having a
passphrase for the key at all? If p@satan gets cracked, then either way
they can get to p@belial from p@satan, so automating the mail transfer
implies that you will have to clean up both systems if p@satan gets
cracked.
Note that having unrestricted access from satan to belial is accomplished
by putting p@satan's public key in p@belial:/.ssh/authorized_keys, but
says nothing about p@belial's access to p@satan.
If you want the passphrase, and are willing to type it in every single
time you get mail, then I would run fetchmail manually. That may be
appropriate for ssh access from p@belial to p@satan, since belial is not
behind a firewall, and you don't have a need to forego that extra
security there. But firewalls with holes in them for public services
are not 100% trustworthy either. :)
Fortunately even the use of ssh without any passphrases reduces your
chances of getting cracked because of the decreased sniffability.
> > You probably also need to add a "-l p" (say, between the "-f" and "-L" to
> > go from user [EMAIL PROTECTED] to user p@belial.
>
> this is only for user p on satan, and collecting email as p on belial. i
> don't really care about root's email on that system.
Okay. No "-l" option. I have been assuming you ran it as a daemon
(root).
> sorry for being so boneheaded! this is definitely out of my sphere of
> knowledge.
I just happen to play with ssh... only slightly less bone in that part of
my head. The important thing to keep in mind is that the value of a
private key lies primarily in its privateness. The passphrase is the
second line of defense, and is weakened by the temptation to shorten it
since you use it a lot.
I'm still trying to find references for the relationship between SSH and
SSL, other than the fact that SSH happens to use the SSL library. I
thought that was simply one more possible encryption system... but perhaps
not.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Work:<[EMAIL PROTECTED]> Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
