secure access to IMAP server?
Alan J. Flavell
This seems like an interesting dilemma. I would like to implement (not
here at CERN, however!) secure access to an IMAP server. But without
allowing the users to have a normal terminal-style session on the mail
server.
The obvious way, using ssh port forwarding, seems to need opening an ssh
session at the mail server in order to enable the port forwarding. From
which the users could then do pretty much anything they wanted on the
mail server. We don't want to do that - they have access to other
machines for doing shell-window-stuff, we want to reserve the mail
server for mail sessions only.
What am I missing here?
thanks
Timothy J. Lee
|
|The obvious way, using ssh port forwarding, seems to need opening an ssh
|session at the mail server in order to enable the port forwarding. From
|which the users could then do pretty much anything they wanted on the
|mail server. We don't want to do that - they have access to other
|machines for doing shell-window-stuff, we want to reserve the mail
|server for mail sessions only.
Would giving the users a shell that allows them to do nothing
except logout (when the user desires) do the task?
--
------------------------------------------------------------------------
Timothy J. Lee timlee@
Unsolicited bulk or commercial email is not welcome. netcom.com
No warranty of any kind is provided with this message.
David desJardins
> here at CERN, however!) secure access to an IMAP server. But without
> allowing the users to have a normal terminal-style session on the mail
> server.
> The obvious way, using ssh port forwarding, seems to need opening an ssh
> session at the mail server in order to enable the port forwarding.
Well, connecting with ssh isn't the same as starting a shell. Just
setting up an ssh tunnel doesn't start a remote shell; you can do that
(I believe) even if your remote shell is /sbin/nologin or the like.
But if you do want to allow them to log in and execute a limited set of
commands, then you need to set up the account on that machine with the
correct uid but with a restricted shell which only allows certain
commands to be executed. On many (all?) Unix systems if you invoke
/bin/sh as "rsh", you get a restricted shell. Or you can use chroot to
build the same thing yourself. Or you can just write a custom program
to use as the shell which only allows specific limited commands.
David desJardins
crin...@invalid.invalid
: This seems like an interesting dilemma. I would like to implement (not
: here at CERN, however!) secure access to an IMAP server. But without
: allowing the users to have a normal terminal-style session on the mail
: server.
: The obvious way, using ssh port forwarding, seems to need opening an ssh
: session at the mail server in order to enable the port forwarding. From
: which the users could then do pretty much anything they wanted on the
: mail server. We don't want to do that - they have access to other
: machines for doing shell-window-stuff, we want to reserve the mail
: server for mail sessions only.
: What am I missing here?
- I haven't done it myself but sshd2 executes the shell environment
variable. If you just set the default shell to be your imap-Server you
should have secure imap. On the other hand you could specify a global
authorization file and restrict access to just one command. (I've done that
for scp1 Batchmode processes)
--
Christopher
Nico Kadel-Garcia
>
>This seems like an interesting dilemma. I would like to implement (not
>here at CERN, however!) secure access to an IMAP server. But without
>allowing the users to have a normal terminal-style session on the mail
>server.
It is possible to install an SSL wrapper for IMAP for access via clients
that understand the SSL wrapped IMAP. It is also easier to do this and
have your people use Netscape, Internet Exploder, etc. than to get
SSH port forwarding running on all the systems that might need it.
--
Alan J. Flavell
> It is possible to install an SSL wrapper for IMAP for access via clients
> that understand the SSL wrapped IMAP. It is also easier to do this and
> have your people use Netscape, Internet Exploder, etc. than to get
> SSH port forwarding running on all the systems that might need it.
Thanks. This is indeed another option that I was seriously considering;
however, I am still interested in the ssh question (and thanks to the
others who provided answers and comments; I may need to come back with
other questions in due course - hope this is also useful for others).
Russell Fulton
>
> This seems like an interesting dilemma. I would like to implement (not
> here at CERN, however!) secure access to an IMAP server. But without
> allowing the users to have a normal terminal-style session on the mail
> server.
>
> session at the mail server in order to enable the port forwarding. From
> which the users could then do pretty much anything they wanted on the
> mail server. We don't want to do that - they have access to other
> machines for doing shell-window-stuff, we want to reserve the mail
> server for mail sessions only.
>
What I do when I am attending conference is to establish an ssh tunnel
to my own workstation and then use port forwarding from there. So IMAP
traffic goes across the internet through an encrypted tunnel and pops
out on our network from my workstation where it then travels
(unencrypted) across our LAN to the Mail server.
Since you have a machine for doing shell stuff you could use that (just
be aware that traffic between where the tunnel ends and the mail server
will be unencrypted. (in our case it is a switched network within our
building).
forwarding to another system is a bit more fiddly to set up than
forwarding to the host where the tunnel is to but it isnt too bad.
Cheers, Russell.
Alan J. Flavell
> Would giving the users a shell that allows them to do nothing
> except logout (when the user desires) do the task?
I guess so; you mean specifying something different as their shell, in
their password file entry? If so, then what should that "something"
be, please?
It means, I suppose, a different passwd file on the mail host than on
the login hosts, but this could be feasible if it was the optimal
solution. Or should the mail host be set up so that the filesystem that
the mail users see has its shells all symlinked to the "something"
mentioned above? This could then use the same passwd file, but the
effects could be confusing...?
thanks for the suggestions, I appreciate it.
Thomas H Jones II
Alan J. Flavell <fla...@mail.cern.ch> did thusly spew forth:
for what it's worth, this is the option I took. I explored several possible
avenues first, however. After all, its more than a bit silly to have ssh
installed, if youre still using things like ftp, imap, pop and other
programs that send passwords in the clear over the Internet.
My decision to go with SSL for IMAP/POP stemmed from the fact that the
ssh-tunnel seemed like a kludge, at best, and didnt offer the same level
of compatability (for specific applications) that SSL does. Besides, for
me, this isnt so much an exercise in "what can i do with SSH today?" as it
is "how can I keep my (users') passwords (relatively) secure?".
-tom
ps. using an SSL wrapper proved easier to
implement than hacking SSL support
into the IMAPd itself.
--
"You can only be -so- accurate with a claw-hammer." --me
Timothy J. Lee
|
|> Would giving the users a shell that allows them to do nothing
|> except logout (when the user desires) do the task?
|
|I guess so; you mean specifying something different as their shell, in
|their password file entry? If so, then what should that "something"
|be, please?
Perhaps something like:
#include <stdio.h>
#include <stdlib.h>
int
main (void)
{
static char s[10];
fputs ("Enter P to change password, anything else to logout: ", stdout)
;
fgets (s, 2, stdin);
if (s[0] == 'p' || s[0] == 'P') {
int rc;
rc = execl ("/usr/bin/passwd", "passwd", NULL);
if (rc) perror ("/usr/bin/passwd");
return rc;
} else {
return 0;
Doug Siebert
>for what it's worth, this is the option I took. I explored several possible
>avenues first, however. After all, its more than a bit silly to have ssh
>installed, if youre still using things like ftp, imap, pop and other
>programs that send passwords in the clear over the Internet.
I thought IMAP 4 supported encryption itself? Is this something that
IMAP 4 allows but popular servers or popular clients do NOT support?
If not, something ought to be done in the IMAP protocol, rather than
tack on ugly and essentially unsupportable hacks using ssh tunnels and
the like. There's no way a user base that has any control over their
own PCs could make something like this work and stay working.
--
Douglas Siebert Director of Computing Facilities
douglas...@uiowa.edu Division of Mathematical Sciences, U of Iowa
I plan to live forever, or die trying.
Julian King
> > The obvious way, using ssh port forwarding, seems to need opening an ssh
> > session at the mail server in order to enable the port forwarding.
>
> Well, connecting with ssh isn't the same as starting a shell. Just
> setting up an ssh tunnel doesn't start a remote shell; you can do that
> (I believe) even if your remote shell is /sbin/nologin or the like.
>
You can? I'd love to know how, I've never seen an indication of this
in my browsing of the documentation...
Julian King
Computer Officer, University of Cambridge, Unix Support
Alan J. Flavell
> It is possible to install an SSL wrapper for IMAP for access via clients
> that understand the SSL wrapped IMAP. It is also easier to do this and
> have your people use Netscape, Internet Exploder, etc. than to get
> SSH port forwarding running on all the systems that might need it.
Thanks. I also received email making the same suggestion, and
this seems a good moment to report back observations to usenet.
I'm now moving the discussion to comp.mail.imap as it seems a more
appropriate place for this sub-thread. BTW I should mention that this
discussion has nothing to do with CERN, it relates to my "home
institute".
I first tried sslwrap on a Digital Unix 4 machine that already had
SSLeay 0.9.0b installed. Installing sslwrap from
http://www.rickk.com/sslwrap/ proved very easy to set up, simply by
following the instructions. I made the certificate file mode 600, and
chown'ed it to sslwrap.
The only bits I stumbled over were related to tcp wrappers:
- the UID "sslwrap" wasn't able to read the hosts.allow|deny files
until I did something about it (for the present I set them
world-readable; perhaps a group membership would be a better plan)
- I had to add an entry for sslwrap into hosts.allow to permit my
client to access the server.
I was easily able to see these problems from the syslog, so it was no
big deal.
After that was done, a connection from (for example) Netscape Messenger
went very smoothly.
I emailed some suggestions to the author about the web page.
One that may be worth repeating is this:
- - -
Also, when req prompts for you "Common Name (eg, YOUR name) []" enter
your host name
ought to be placed earlier, right after the three commands have been
exhibited. I had issued those commands and answered the questions
(wrongly) before realising what I was supposed to do.
- - -
I subsequently installed SSLeay and sslwrap onto a Solaris 2.6 system,
with equal success. In both cases the compiler used was gcc 2.8.1.
These accesses definitely work in principle, from NS Messenger (tried)
and MS Outlook (reported by others). This mode of working evidently
gives protection to the whole network link, both to the authenticator
procedure and to the transfer of actual mail content.
I'm a little concerned about the CPU implications of opening this up to
users in general before we migrate to a new and more powerful mail
server in the Summer, but we'll see how it goes.
There's still confusion about what other client options are viable.
Many users are familiar with and like Eudora Light (most on Win95, a few
on Mac), which they use against the Qualcomm POP3 server, qpopper: we
were thinking some of them would like to move to Eudora Pro, so that
they could use IMAP instead, but in both cases there's still this issue
of protecting against password snooping. I see no mention of Eudora
Pro supporting the SSL wrapping technique.
Maybe it could be used with one or other secure authenticator; in most
cases, there is no real concern about secrecy of data transfers, only
about the risk of passwords being snooped. I haven't found a very clear
presentation anywhere of the secure authenticator options that are
actually available in IMAP servers and clients. Eudora Pro seems to
have some kind of MD5 authenticator - is this an option for UW IMAP
server?
The other clients that are favoured by users are PINE and PC PINE.
PINE can anyway be used against the UW IMAPD with "preauthentication".
Since our servers block r-series commands, we'd be using the variant
ssh-spoofed r-series commands to provide that function. So that
provides us with a secure authenticator. As an alternative, we come
back to running PINE over an ssh tunnel[*]
I don't see any corresponding option for PC PINE, so there, we'd
still be looking at running PC PINE over an ssh tunnel from the PC, if
there were no secure authenticator available[*].
[*]and that brings us back to the original discussion, since we don't
want to open arbitrary shells on the mail server. But I think that side
of the discussion has been explored enough for now. I'll be looking
into the practical issues raised in the various responses.
Thanks all, and could I say this was usenet at its best: high quality,
on-topic, relevant answers. I'm glad I asked.
Lyndon Nerenberg
Doug> I thought IMAP 4 supported encryption itself?
Technically, it doesn't. IMAP4rev1 supports SASL. A particular SASL
mechanism MAY support encryption ("protection" in SASL terminology).
Right now the only SASL mechanisms supporting protection that have seen
any real amount of deployment in IMAP4rev1 are KERBEROS_IV and GSSAPI
(Kerberos 5).
Work is underway to add support for TLS to IMAP4. I suspect this will
rapidly become the preferred method for deploying encryption at the
transport layer.
Using SSH is a hit-and-miss proposition. Port forwarding via SSH will
almost certainly break IMAP login and mailbox referrals. If your IMAP4
server doesn't support referrals SSH should work.
--lyndon
Rich Paul
everything except pine, here's the last step: Set each user's
shell to be your imapd ( /usr/sbin/imapd or whatever ). Then set
up pine, which is able to get to an imapd server using rsh, to
just run ssh2 instead of what it wants to do, which is
/usr/bin/rsh /usr/sbin/imapd. Try running imapd from the command
line to see what you get in this case.
Now what I want to know is if you then make sshd listen to the
port that netscape uses for simap, will netscape be able to talk
directly to the sshd server. But I doubt that that part will be
that easy.
Three that's in one sentance, time to sleep. <G>
In article
<Pine.HPP.3.95a.99032...@hpplus01.cern.ch>, Alan
J. Flavell wrote:
>
>This seems like an interesting dilemma. I would like to
>implement (not here at CERN, however!) secure access to an IMAP
>server. But without allowing the users to have a normal
>terminal-style session on the mail server.
>
>The obvious way, using ssh port forwarding, seems to need
>opening an ssh session at the mail server in order to enable the
>port forwarding. From which the users could then do pretty much
>anything they wanted on the mail server. We don't want to do
>that - they have access to other machines for doing
>shell-window-stuff, we want to reserve the mail server for mail
>sessions only.
>