Thread: Security with V9.3.3 standby servers

Security with V9.3.3 standby servers

From
John Scalia
Date:
Hi all,

An edict has been handed down here from on high that no script shall ever contain any password in cleartext for any
reason.Well this is problem with a streaming replication  
standby server's recovery.conf file as the line primary_conninfo = contains said replication user's password for that
connection.Is there any sort of plan to allow this to be md5  
or some such encoded? Or what else could I do in this case?

Thx,
Jay



Re: Security with V9.3.3 standby servers

From
luis.sa@htip.com.br
Date:
On Thu, 26 Feb 2015 11:15:51 -0500, John Scalia wrote:
> Hi all,
>
> An edict has been handed down here from on high that no script shall
> ever contain any password in cleartext for any reason. Well this is
> problem with a streaming replication standby server's recovery.conf
> file as the line primary_conninfo = contains said replication user's
> password for that connection. Is there any sort of plan to allow this
> to be md5 or some such encoded? Or what else could I do in this case?
>
> Thx,
> Jay


Yes. Use ssh key to create a fingerprint.

Ex. "ssh-keygen" command to generate a fingerprint. And "ssh-copy-id
postgres@slave" and  "ssh-copy-id user@master" to copy the key to alow
both machines communicated over ssh.


Re: Security with V9.3.3 standby servers

From
luis.sa@htip.com.br
Date:
On Thu, 26 Feb 2015 13:05:52 -0500, John Scalia wrote:
> On 2/26/2015 12:56 PM, luis.sa@htip.com.br wrote:
>> On Thu, 26 Feb 2015 11:15:51 -0500, John Scalia wrote:
>>> Hi all,
>>>
>>> An edict has been handed down here from on high that no script
>>> shall
>>> ever contain any password in cleartext for any reason. Well this is
>>> problem with a streaming replication standby server's recovery.conf
>>> file as the line primary_conninfo = contains said replication
>>> user's
>>> password for that connection. Is there any sort of plan to allow
>>> this
>>> to be md5 or some such encoded? Or what else could I do in this
>>> case?
>>>
>>> Thx,
>>> Jay
>>
>> Yes. Use ssh key to create a fingerprint.
>>
>> Ex. "ssh-keygen" command to generate a fingerprint. And "ssh-copy-id
>> postgres@slave" and  "ssh-copy-id user@master" to copy the key to alow
>> both machines communicated over ssh.
>>
> All systems already have ssh keys shared between them as it's used by
> scp to transmit the WAL archive to both standby servers. How would I
> indicate in the recovery.conf that the embedded password in the line
> primary_conninfo is encrypted? That line only has "user=<the user>
> password=<the password>" I was thinking that the "password=" could
> have something like "md5:<the password>" in it. Or you could just
> specify whichever encryption protocol that was used followed by the
> colon.

Sorry, wrong answer. The password is for role user on postgres and not
ssh.

Well, i don't know... but the security may be guaranteed for linux in
permissions (chmod and chown)..


Re: Security with V9.3.3 standby servers

From
Scott Ribe
Date:
On Feb 26, 2015, at 9:15 AM, John Scalia <jayknowsunix@gmail.com> wrote:
>
> An edict has been handed down here from on high that no script shall ever contain any password in cleartext for any
reason.Well this is problem with a streaming replication standby server's recovery.conf file as the line
primary_conninfo= contains said replication user's password for that connection. Is there any sort of plan to allow
thisto be md5 or some such encoded? Or what else could I do in this case? 

I have replica standbys that are firewalled from the primary. The primary establishes a reverse SSH tunnel to the
replica,then the replica is configured as for a local connection on-server at the primary, just using UNIX identity. 

--
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice






Re: Security with V9.3.3 standby servers

From
John Scalia
Date:
Ahhh, I hadn't considered that. Thanks, I think I'll try that tomorrow morning.

On 2/26/2015 4:57 PM, Scott Ribe wrote:
> On Feb 26, 2015, at 9:15 AM, John Scalia <jayknowsunix@gmail.com> wrote:
>> An edict has been handed down here from on high that no script shall ever contain any password in cleartext for any
reason.Well this is problem with a streaming replication standby server's recovery.conf file as the line
primary_conninfo= contains said replication user's password for that connection. Is there any sort of plan to allow
thisto be md5 or some such encoded? Or what else could I do in this case? 
> I have replica standbys that are firewalled from the primary. The primary establishes a reverse SSH tunnel to the
replica,then the replica is configured as for a local connection on-server at the primary, just using UNIX identity. 
>



Re: Security with V9.3.3 standby servers

From
Albe Laurenz
Date:
John Scalia wrote:
> An edict has been handed down here from on high that no script shall ever contain any password in
> cleartext for any reason. Well this is problem with a streaming replication
> standby server's recovery.conf file as the line primary_conninfo = contains said replication user's
> password for that connection. Is there any sort of plan to allow this to be md5
> or some such encoded? Or what else could I do in this case?

Well, I would consider "trust" authentication.

If you restrict it to a single IP address, I don't think it is less secure
than having your password lying around on another computer.

Yours,
Laurenz Albe

Re: Security with V9.3.3 standby servers

From
Peter Eisentraut
Date:
On 2/26/15 11:15 AM, John Scalia wrote:
> An edict has been handed down here from on high that no script shall
> ever contain any password in cleartext for any reason. Well this is
> problem with a streaming replication standby server's recovery.conf file
> as the line primary_conninfo = contains said replication user's password
> for that connection. Is there any sort of plan to allow this to be md5
> or some such encoded? Or what else could I do in this case?

You can put the password in the a .pgpass file.  Not sure if that counts
as a "script".

Or you can do away with passwords and authenticate using SSL client
certificates.