When automating PostgreSQL database operations, the fe_sendauth: no password supplied error commonly occurs despite seemingly correct password configurations. Let's examine the most effective solutions.

Your script is close, but needs adjustment:

#!/bin/bash
export PGPASSWORD="postgres"
psql -U postgres -d pg_ldap -h localhost -p 5432 -t -c "SELECT id FROM radusers WHERE id=1"

Key points:

• Remove sudo: Running as postgres user bypasses environment variables
• Explicit username: Always specify -U parameter
• Remove redundant flags: -w --no-password conflicts with password auth

For a more secure approach using .pgpass:

# ~/.pgpass content (must be chmod 0600)
localhost:5432:pg_ldap:postgres:postgres

Then simplify your script:

#!/bin/bash
psql -U postgres -d pg_ldap -h localhost -p 5432 -t -c "SELECT id FROM radusers WHERE id=1"

For maximum clarity, use connection URIs:

#!/bin/bash
psql postgresql://postgres:postgres@localhost:5432/pg_ldap \
  -t -c "SELECT id FROM radusers WHERE id=1"

• Verify PostgreSQL's pg_hba.conf has md5 or password auth method for local connections
• Check psql -U postgres -l to confirm database accessibility
• Test authentication with PGPASSWORD="postgres" psql -U postgres -h localhost
• Ensure .pgpass is in the correct user's home directory

For production scripts, consider:

#!/bin/bash
read -s -p "Password: " PGPASSWORD
export PGPASSWORD
psql -U postgres -d pg_ldap -h localhost -p 5432 \
  -t -c "SELECT id FROM radusers WHERE id=1"
unset PGPASSWORD

---

When automating PostgreSQL operations, password authentication remains one of the most common pain points. The error message "fe_sendauth: no password supplied" typically occurs when the client connection attempt fails to provide proper credentials, despite your configuration efforts.

#!/bin/bash
export PGPASSWORD="postgres"
sudo -u postgres psql -d pg_ldap -w --no-password -h localhost -p 5432 -t -c "SELECT id FROM radusers WHERE id=1"

The key issues here are:

1. Conflicting parameters: -w (force password prompt) and --no-password
2. Environment variable scope when using sudo
3. Potential pg_hba.conf configuration conflicts

Solution 1: Proper Environment Variable Usage

#!/bin/bash
sudo PGPASSWORD="postgres" -u postgres psql -d pg_ldap -h localhost -p 5432 \
  -t -c "SELECT id FROM radusers WHERE id=1"

Key improvements:

• Moved PGPASSWORD into sudo's environment
• Removed conflicting password-related flags

Solution 2: Leveraging .pgpass Correctly

For the .pgpass file to work effectively:

localhost:5432:pg_ldap:postgres:postgres

Critical configuration steps:

chmod 600 ~/.pgpass
chown $(whoami):$(whoami) ~/.pgpass

Solution 3: Connection URI Method

#!/bin/bash
sudo -u postgres psql postgresql://postgres:postgres@localhost:5432/pg_ldap \
  -t -c "SELECT id FROM radusers WHERE id=1"

When troubleshooting, always check:

1. pg_hba.conf authentication methods
2. PostgreSQL server logs
3. Environment variable inheritance
4. File permissions (especially for .pgpass)

For more secure automation:

1. Use separate automation users with limited privileges
2. Consider client certificate authentication
3. Store credentials in dedicated secret management systems
4. Implement connection pooling where appropriate