l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:11

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Secure Email Access (fetchmail and ssh)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Secure Email Access (fetchmail and ssh)

On Fri, Oct 12, 2001 at 12:09:08AM -0700, ME wrote:
> Date: Fri, 12 Oct 2001 00:09:08 -0700 (PDT)
> From: ME <dugan@passwall.com>
> To: vox-tech@franz.mother.com
> Subject: Re: [vox-tech] Secure Email Access (fetchmail and ssh)
> Reply-To: vox-tech@lists.mother.com
> On Thu, 11 Oct 2001, Matt Roper wrote:
> > I am trying to find a secure way to have the box that I use as a
> > mail
> > server go download all my @ucdavis email from the UCD mail server.
> > My
> > plan is to use fetchmail with an ssh preconnect string to accomplish
> > this.  I believe that my .fetchmailrc file should have an entry that
> > looks something like the following:
> >
> > poll yellow.ucdavis.edu via localhost port 1234 with proto pop3:
> >     user 'mattrope' there with password 'XXXXXXX' is mattrope here
> >     preconnect "ssh -f -q -L 1234:yellow.ucdavis.edu:110
> >     yellow.ucdavis.edu sleep 20 < /dev/null > /dev/null"
> Hmmm...
> > The problem with this is that ssh would have to ask for my password
> > every time it tries to connect to the UCD mailserver, which is
> > unacceptable if fetchmail is running in daemon mode.  I believe that
> > the
> > way most people overcome this is by generating an ssh keypair with
> > no
> > passphrase and sticking the public key in their
> > ~/.ssh/authorized_keys
> > file on the server.  However UCD does not allow students to login to
> > the
> > mail servers directly, so there is no way I can put my public key on
> > the
> > server.  This seems to rule out the use of public key authentication
> > for
> > establishing a secure connection.
> I am not so sure that you can have an ssh client arbitrate a "secure
> session" with a pop3 server (port 110) like that unless you are
> certain
> the mail server also runs ssh and can allow for redirections with the
> connecting ssh client. If there is really an ssh server on the mail
> server, you may be able to grab your private keys on the server with
> scp
> and make some guesses on the locations of the keys.
> In order for ssh to really work kind-of like the way you want it, is
> for
> them to have an SSH server running on the same host as the mail server
> offering the pop3 service. Then you can use an ssh-session to the
> server
> to relay a localhost connection and relay of pop3 data
> through
> your link.

The campus mail servers are running an SSH server as well as pop3 and
imap servers.  Trying to login directly through SSH results in a message
about interactive logins being disallowed.  I assumed that this message
was showing up because my login shell had been set to some message
script instead of a real shell and that secure port forwarding would not
be affected.  It turns out that they must be doing something else on the
server to restrict access because when I actually tried running "ssh -f
-q -L 1234:yellow.ucdavis.edu:110 yellow.ucdavis.edu sleep 20" manually,
the secure session quietly failed after I typed in my password (i.e. no
error messages, but no port 1234 established on localhost either).  This
was quite a surprise because I am able to use an almost identical
command on my ISP's mailserver (which I have put an SSH public key on)
without problems.  So I guess UCD is doing something more than just
changing my login shell.

> Some people have encountered problems like this and found ssh-ing to
> an
> on-campus host "close" to the pop3 server, and then relaying the
> request
> using the insecure pop-authentication (plain-text across the net, but
> only between the on-campus hosts nstead of being bounced across a
> larger
> network.)

Good point.  The mail servers can be reached in just a single hop from
the isun systems which I have a shell account on.  In order for somebody
to sniff my password being transmitted from isun to the mail server,
they'd have to have root access on some computer in that subnet, right?
Definitely a big win over sending an unencrypted password across the
entire Internet.

> I could be very "out-of-it" and not know about some new special
> features
> in ssh/fetchmail, and if so, please accept my appology on
> misdirection.
> > It seems that what I really need is a way to tell ssh what password
> > to
> > use, either as a command line parameter or an option in
> > ~/.ssh/config.
> > Does such a parameter/option exist?  I have found no indication of
> > one
> > in the manpages.  I realize that having my UCD password available in
> > a
> > configuration file would not be a good thing if my mail server were
> > cracked, but I think this is probably less of a security risk than
> > transmitting my password over the internet in cleartext every minute
> > or
> > so.
> get the keys you need for password free authentication for ssh and
> then
> finally scp the desired keys from the server. (ssh may execute
> commands on
> remote servers. Depending upon how they have user accound set up, you
> may
> be able to execute a command as a shell with arguements being specific
> applications. This may get you booted from their server though as you
> would be trying to leverage your access to the system (getting
> command-line access to a server where students are explicitly denied
> shell
> access for example) I do not suggest this route, but mention that it
> may
> be possible and sometimes it is easier to ask forgiveness than
> permission - just know your risks.
> For example:
> $ ssh username@remotehost "bash -c ssh-keygen"
> Generating p:  ................++ (distance 216)
> Generating q:  ...........................................++(distance
> 521)
> Computing the keys...
> Testing the keys...
> Key generation complete.
> Initializing random number generator...
> Enter file in which to save the key (/home/dugan/.ssh/identity):
> Enter passphrase: uh huh huh
> Enter the same passphrase again: uh huh huh
> Your identification has been saved in /home/username/.ssh/identity.
> Your public key is:
> ...YYYYY username@remotehost
> Your public key has been saved in /home/username/.ssh/identity.pub
> $ (returned back to your local command shell)
> then you may be able to scp the stuff you want and then scp the files
> you
> want to the location you desire (-r option for dir creation as needed
> may
> help here)
> If they know what they are doing to prevent users from shell access
> that
> should not work as above.
> If you did have this key-pair with ssh for auto-auth with the whole
> private key copy thing it can also open up remote hosts added with the
> share key from keygen to being attacked from your local machine too.
> However, a local crack means anything may have been trojaned too, so
> know
> your risks...
> > If establishing a secure connection via ssh is not possible are
> > there
> > any other alternatives?  I read a little bit about stunnel, but it
> > sounds like that is of more use on the server side than the client
> > side...  I suppose if I really have to, I could try to hack the
> > openssh
> > source so that it will read a password from the config file and/or
> > command line.
> AFAIK, if you want to have some sort of higher security/encryption
> with
> pop3 mail pickup, then you need a server that supports it. The whole
> server based sshd to allow local pop3 connects is one method available
> at
> some ISPs. When you use the ssh -L option, I think it asks the remote
> ssh
> server to allow for redirected traffic to a machine port and then have
> the
> transaction take place between the ssh server and you client in an
> encrypted fashion.
> Also, beware of a command-line based password flag/arguement addition
> to
> ssh as someone looking at the processes (ps -auxw) may see your
> password
> as an arguement. Also, root would be able to look at the /proc and get
> this from your local session too.
> > Any ideas?  Am I just being stupid and overlooking something
> > obvious?  I
> > would appreciate any insight you could give me.
> If you do not care about your remote host (mail server's) ssh password
> being on your machine in plaintext, then you can expect script it and
> then
> cron-job the pickup process. (Obvious risks in leaving a plain-text
> password on the filesystem of your machine.)
> "more secure mail pickup with pop3" is a problem I tried to resolve a
> long
> while back few years.) The solutions I came up with were:
> use of ssh to tunnel a connection to an on-campus server (preferrably
> the
> mail server, but a "close" host when that was not possible) and then
> run
> slirp or a real pppd on that server, and add a routing entry for
> specific
> hosts to go through the added tunneled interface. Then do a normal
> pop to the IP which will be routed through the encyrpted tunneled
> ppd link. (umm.)
> Munge an IPSEC style network from my client to an on campus server
> "near" the mail server. (Need server support too)
> arrange for a demand dialed modem, or cron-job for dial-in and pickup
> of
> mail messages from the server.
> I seem to recall discussion of "APOP/APOP3" as ann Advanced POP3
> server
> that allowed for better authentication and possible some kind of
> encryption, but it would require the server to run this, and you to
> have
> an apop client.

I manually checked the campus mail server to see if its pop server
supported the APOP command, but unfortunately it doesn't.  I also
checked to see what types of authentication the imap server supports,
but apparently it can only handle the standard plaintext
username/password method.

> Use of an ssh server on campus (preferrably on the same server as the
> mail server) and then ssh to the server and use it as a relay with 2
> layers of passwords - one for ssh and one for pop3.
> Contact the IT department, and get them to forward all of your e-mail
> to a
> preset off campus ISP, or your home if running your own mail server.
> (I
> chose this option as it was the easiest in the long term.)

Yeah, this may be the best option.  I didn't think I was going to be
able to forward my mail to another server since I couldn't create a
.forward file, but last night I did come across a university website
that will let me forward my campus mail to another address.

> Summary:
> In order to allow for a pop3 client/server authentication be encrypted
> that functionality needs to exist in the client *and* the server or at
> least a server near the server you want to play with.
> AFAIK, the generic POP3 protocol does not require encryption or strong
> "security against eavesdropping" and allows for plain-text
> authentication.
> Use of stronger authentication requires support in the server (first)
> and
> the client (second). (APOP3 on server with an APOP3 client , or ssh to
> server running sshd and then pop3 relay\/get from there, or
> IPSEC/tunneles
> secured connections) require server-side support as well as your
> client
> side support.
> You have other thoughts on making a standard pop3 server without ssh
> allow
> for encrypted and "secure" (non-plaintext and encrypted
> challange-response) I'd like to hear em. :-)
> There are many people on this list more skilled than me who might have
> other ideas.

Thank you for the very informative, detailed email.  You brought up a
lot of good points that had not occured to me.


> -ME
> Version: 3.12
> GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$)
> P+$>+++
> L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
> t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
> ------END GEEK CODE BLOCK------
> decode: http://www.ebb.org/ungeek/ about:
> http://www.geekcode.com/geek.html
>      Systems Department Operating Systems Analyst for the SSU Library


* Matt Roper <matt@mattrope.com> *
* http://www.mattrope.com        *

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.