[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: SSH tunnels
We used SSH tunnels for well over a year to replicate to 4 remote servers
from the master server. You do not need to run it as root. It works
reasonably well, however here are the problems with it:
1) When one of the servers get rebooted, you must manually recreate the
ssh tunnel.
2) ssh tunnels occasionally die or stop working, in which case, slurp can
no longer contact the remote ldap server.
3) In 2.1 kernels, and possibly others, after killing an ssh tunnel, it is
sometimes unable to reclaim the port it had before. The only solution to
this is changing the port number in slapd.conf and creating a new ssh
tunnel, or rebooting.
In the end, these problems became too much, infrequent though they may be.
We went with stunnel (www.stunnel.org). It transfers tcp traffic of upd.
It's a stateless connection, so as long as the stunnel server is running
on both ends, it will create a connection whenever data needs to be
transfered. It appears to be quite reliable.
However, stunnel does add another dependency to your setup, which you will
probably have to bring into question from time to time.
Also, someone could potentially fire up an stunnel client on their
computer and connect to the stunnel server on your remote server, giving
them another route to your ldap database. This is really no different
than leaving port 389 open to the world, so take care in setting up your
ipchains/iptables firewall. With stunnel, you can also require ssl
certificates to authenticate stunnel clients.
Another alternative to consider is the kernel module cipe
(http://www.merit.ee/~gunnar/#Examples), which has been around for much
longer and is considered extremely stable. It is a kernel module, and may
require recompiling your kernel to get it working, but looks like (other
than ldap's built-in tls/ssl) it could be the "way."
>
> This certainly would be an alternative and could provide strong
> encryption (probably even more than required). However, IMO, it
> introduces another dependency* in your design, one which you probably
> don't need given the availability of SSL/TLS with ldap.
>
> If SSL/TLS is not available to you for whatever reason, another option
> is SASL (simple authentication and security layer). I would consider it
> an alternative not suitable for the faint of heart.
>
> * The ssh tunnel would need to be in place before ldap starts up and
> depending on how you configure it, may require root privileges.
>
>
> I would also comment that you should consider how the system will react
> in case the encrypted tunnel (be that ssh or SSL/TLS) fails. Does it
> fail securely and exit with an error (alarm) or proceed talking
> cleartext LDAP?
>
> cheers,
> Sasha
>
>>-----Original Message-----
>>From: owner-openldap-software@OpenLDAP.org
>>[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of
>>Richard Baldwin
>>Sent: Wednesday, November 06, 2002 2:00 PM
>>To: openldap-software@OpenLDAP.org
>>Subject: SSH tunnels
>>
>>
>>Hi,
>>
>>I have seen a few references to people using SSH tunnels to
>>secure LDAP communications, but no discussion as to its
>>advisability. Is this a reasonable way to go, or are there
>>hidden problems in this approach as compared to SSL/TLS?
>>
>>Thanks from an LDAP newbie!
>>
>>_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_
>>)_)_)_)_)_)_)_)
>>_)
>> _)
>>_) Richard E. Baldwin
>> _)
>>_) Geological Survey of Canada voice: 250-363-6740
>> _)
>>_) Pacific Geoscience Centre fax: 250-363-6565
>> _)
>>_) 9860 West Saanich Road, Box 6000 email:
>>baldwin@pgc.nrcan.gc.ca _)
>>_) Sidney, BC, V8L 4B2, CANADA web:
>>http://www.pgc.nrcan.gc.ca _)
>>_)
>> _)
>>_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_)_
>>)_)_)_)_)_)_)_)
--
John Hogenmiller, kb3dfz
Network Engineer
Pennswoods.net
877.716.2002 x 529
--
"It would be in your best interest to take my advice because I know
everything."