[Techtalk] adsl and dyndns issues with changing IP addresses
anotheranne at fables.co.za
Sat Nov 13 12:17:35 UTC 2010
nice to hear from you again and thanks for the pointer.
I am using kexi (part of koffice) as the front end to the database.
this will connect from any client to the server, given the address,
user name, password, from within our network or across the net as I
have got it to do.
Now that the euphoric moment of achieving that has passed I suppose, as
Monique implies, that this is a high risk.
If I connect using pgadmin then it indicates that its connection is SSL
encrypted. Not sure if that is the same as ssl tunnelling that I read
in man ssh, don't think so. I'll investigate this.
In the longer term, it has been in the pipeline for a long time,
I must get my nascent perl/catalyst app up to scratch so that we can
access the database through the browser on port 80 which would present
less opportunity for a security breach.
In the meantime I'll investigate and check all current security to
make sure it works as I think it works.
On Sat, 13 Nov 2010 10:22:18 +0100
Wim De Smet <kromagg at gmail.com> wrote:
> I didn't entirely grok your setup, but how about just letting postgres
> listen on localhost and just using a ssh tunnel if you need direct
> On 12 Nov 2010 20:33, "Anne Wainwright" <anotheranne at fables.co.za>
> Hello, every one.
> I actually have this under control, from one end at least. Using
> the dyndns service and with ddclient on the office server I get easy
> ssh connections to there from home through the adsl connection.
> The situation deteriorates when I want to connect to the postgresql
> database. In fact I can reliably achieve this, but at the home end the
> aadsl allocated WAN IP address also changes when I log in afresh. This
> means that I then have to ssh to the remote site and edit the
> pg-hba.conf file so that this presents the new IP address as a host
> address for postgresql. Then I restart postgres to reread the .conf
> file, and then I get my evening connection afresh.
> I didn't want to have such a wide mask that half the world could hack
> in, which is the only thing I can think of at present, so am wondering
> what the correct procedure should be. Is there any easy way around
> I can't be the first person to stumble on this issue, so all schemes
> considered with thanks.
> Techtalk mailing list
> Techtalk at linuxchix.org
More information about the Techtalk