l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
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 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 127.0.0.1 connection and relay of pop3 data through
your link.

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.)

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:
1024 XX YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY...
...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.

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.)

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.

-ME

-----BEGIN GEEK CODE BLOCK-----
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




LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
EDGE Tech Corp.
For donating some give-aways for our meetings.