Remote Postgres access??

[Derek Atkins]

True, I agree with you that key management is hard.  However, SSH
is not the answer.  Think about what it means to require SSH with
port forwarding:

	a) you cannot easily have multiple connections going at once
	   (because you cannot have multiple port-forwarders on the
	   same port).  Sure, an easy workaround is to have a
	   different port for each server, but that's a kludge.
	   Worse, then you have to remember which port goes to which
	   site.  The average user wont be able to remember that.

	b) you have to have a unix account on the PostGres server in
	   order to ssh into the machine.  I don't want to have to
	   maintain Unix login accounts for all my database users, and
	   I certainly don't want them logging into my database
	   server.

	c) you still have the key management issue; it's just a
	   different color.  In particular, your client has to make
	   sure they get the right host key, and you still have to
	   maintain a client credential on the server (a password or
	   RSA key) for them to login.

I still maintain that a self-contained end-to-end encryption is the
way to go.  We can use an RPC (be is SOAP/CORBA/RPC/XML+HTTP/whatver)
to transmit information back and forth between client and server.
Encryption is from the client app to a server that runs on the DB
server.  Authentication can be via any number of methods
(Kerberos/GSSAPI/SASL/Username-Password) and can hook either directly
into the DB or the server application can proxy the authentication and
perform the access control itself.

In the latter case, the DB would enable full privs to the server-app
"user", and the server would grant/deny access to information in the
DB based upon the authenticated client.  This latter method abstract
the client-server nature from the actual SQL storage method.

-derek

linas@linas.org (Linas Vepstas) writes:

> Well, there was a time when I'd agree, but the more I'd think about it
> =2E.. ssh really does have some pretty powerful VPN capabilities. =20
> What its missing is support from all those firewall auto-config
> tools and anti-port-scanner tools and auto-inetd or auto ipportfw
> config tools. etc. If it had those it wouldn't seem so 'hackish'
> 
> The other way to think of ssh is as a command-line wrapper for SSL.
> So instead of integrating SSL in directly (and dealing with all
> the mess about agents, key management, etc that each app would=20
> need to provide ) instead you have this unix-command-line-tool=20
> tradition thing. =20
> 
> Adding SSL is easy.  Thinking through the implications of how you=20
> manage keys, etc. is hard.  You, Mr. PGP, should know ...
> 
> --linas=20
> 
> --=20
> Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available