FATAL: no pg_hba.conf entry for host "fe80::1%lo0" - sql

Can someone help me why this is happening when I'm trying to connect to database or rails s?
In my pg_hba.conf file I have this:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication Andrew trust
#host replication Andrew 127.0.0.1/32 trust
#host replication Andrew ::1/128 trust
local all all md5
Maybe I'm doing it wrong?
Thanks

I had the same problem. somehow, this line was added to my /etc/hosts file:
fe80::1%lo0 localhost
commenting out or removing that line from /etc/hosts should fix it
sudo vi /etc/hosts
#fe80::1%lo0 localhost

I'm on OSX 10.9.3 and Postgres 9.3.4.
I've managed to resolve this problem in the following way:
First find your pg_hba.conf file by starting up psql with psql -h 127.0.0.1 and executing SHOW hba_file;:
hba_file
-------------------------------------
/usr/local/var/postgres/pg_hba.conf
(1 row)
Now add the following line to pg_hba.conf:
host all all fe80::1%lo0/128 trust
and reload the configuration via select pg_reload_conf(); within psql.
Now you should be able to connect via psql -h fe80::1%lo0.

Oo, that's an interesting one.
Assuming you're connecting to localhost (you didn't say and didn't show your database.yml), it appears that localhost is resolving to an IPv6 link-local address with zone index.
If you use ::1 or 127.0.0.1 it should work.
This is very likely an operating system misconfiguration or bug, so lots more detail (see comment above) should be added to the question if you want any concrete advice on that.

For me, the cause was calling sudo rails server -p 80.
I bound the rails server to port 80 so that I wouldn't have to specify a port in the url localhost:3000 during development. This appears to write fe80::1%lo0»localhost to my /etc/hosts file.
Try commenting out the line in your hosts file, then running rails s -p 3000

Actually,
The same error occurs for me when I execute pg_dump command to take backup of my server database (external) like below
'/Applications/Postgres.app/Contents/Versions/9.3/bin'/pg_dump -d "<database_name>" -h <server_name> -U <db_user_name> -f <destination_path>
I solved it (work around) by replacing my <server_name> to my actual server IP (10.1.0.18).
So the issue here is my system didn't understand the <server_name> host.
It might solve permanently when you add <server_name> host in /private/etc/hosts file.

Another variant: if IPv6 is not used in the network, you can just disable it. On Windows IPv6 service also can be disabled.

Related

Ubuntu Jump Host in Open Telekom Cloud not working as expected

Currently, I have built a small datacenter environment in OTC with Terraform. based on Ubuntu 20.04 images.
The idea is to have a jump host in the setup phase and for operational purposes that allows spontaneous access to service frontends via ssh proxy jumps without permanently routing them to the public net.
Basic setup works fine so far - I can access the jump host with ssh, and can access the internal machines from there with ssh when I put the private key onto the jump host. So, cloudwise the security seems to be fine. Key pair is generated with ed25519, I use the same key for jump host and internal servers (for now).
What I cannot achieve is the proxy jump as a chained command from my outside machine.
On the jump host, I set AllowTcpForwarding to "yes" in /etc/ssh/sshd_config and restarted ssh and sshd services.
My current local ssh config looks like this:
Host otc
User ubuntu
Hostname <FloatingIP-Address>
Port 22
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
IdentityFile= ~/.ssh/ssh_access
ControlPath ~/.ssh/cm-%r#%h:%p
ControlMaster auto
ControlPersist 10m
Host 10.*
User ubuntu
Port 22
IdentityFile=~/.ssh/ssh_access
ProxyJump otc
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
I can use this to ssh otc to the jump host.
What I would expect is that I could use e.g. ssh 10.0.0.56 to reach an internal host without further ado. As well I should be able to use commands like ssh -L 8080:10.0.0.56:8080 10.0.0.56 -N to map an internal server's port to a localhost port on my external machine. This is how I managed that successfully on other hosting scenarios in the public cloud.
All I get is:
Stdio forwarding request failed: Session open refused by peer
kex_exchange_identification: Connection closed by remote host
Journal on the Jump host says:
Jul 30 07:19:04 dev-nc-o-bastion sshd[2176]: refused local port forward: originator 127.0.0.1 port 65535, target 10.0.0.56 port 22
What I checked as well:
ufw is off on the Jump Host.
replaced ProxyJump configuration with ProxyCommand
So I am at the end of my knowledge. Has anyone a hint what else could be the reason? Any help welcome!
Ok, cause is found (but not yet fully explained).
My local ssh setting was allowing multiplexed forwards (ControlMaster auto ) which caused the creation of a unix socket file for the Controlpath in ~/.ssh.
I had to login to the jump host to AllowTcpForwarding in the first place.
After rebooting the sshd, I returned to the local machine and the failure occured when trying to forward to the remote internal machine.
After deleting the socket file in ~/.ssh, the connection can now be established as needed. Obviously, the persistent tunnel was not impacted by the restarted daemon on the jump host and simply refused to follow the new directive.
This cost me two days. On the bright side, I learned a lot about ssh :o

~/.ssh/config deposited hosts not known

I a experiencing some trouble using ssh, which I can't figure out by myself.
My ~/.ssh/config file looks like this:
Host server
HostName xxx.xxx.xxx.xxx
User user
ForwardX11 yes
LocalForward 8000 127.0.0.1:8000
LocalForward 6080 127.0.0.1:6080
LocalForward 8022 192.168.122.100:22
LocalForward 7777 192.168.122.100:7777
Compression yes
ServerAliveInterval 5
ServerAliveCountMax 3
Manuel connect using ssh user#xxx.xxx.xxx.xxx works fine, yet ssh server does not because zsh "could not resolve hostname".
Do you have any ideas?
Does this problem occour because I use zsh?
Since the ssh gets called by a lot of bash scripts I am forced to use the config file.
Looks like "server" is not being resolved by DNS.
On the system you are sshing from, add something like this to /etc/hosts:
xxx.xxx.xxx.xxx server.domain.com server
Then try ssh again.

Postgres not allowing localhost but works with 127.0.0.1

Postgres not accepting connection if I say -h localhost but it works if I say -h 127.0.0.1
[root#5d9ca0effd7f opensips]# psql -U postgres -h localhost -W
Password for user postgres:
psql: FATAL: Ident authentication failed for user "postgres"
[root#5d9ca0effd7f opensips]# psql -U postgres -h 127.0.0.1 -W
Password for user postgres:
psql (8.4.20)
Type "help" for help.
postgres=#
My /var/lib/pgsql/data/pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
local all all ident
# IPv4 local connections:
host all all 127.0.0.1/32 trust
host all all 127.0.0.1/32 ident
# IPv6 local connections:
host all all ::1/128 ident
If I add following line then Postgres service failed to start:
host all all localhost ident
host all all localhost trust
Wwhat is wrong there?
Update
My /etc/hosts file:
[root#5d9ca0effd7f opensips]# cat /etc/hosts
172.17.0.2 5d9ca0effd7f
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
In pg_hba.conf, the first match counts. The manual:
The first record with a matching connection type, client address,
requested database, and user name is used to perform authentication.
There is no "fall-through" or "backup": if one record is chosen and
the authentication fails, subsequent records are not considered. If no
record matches, access is denied.
Note the reversed order:
host all all 127.0.0.1/32 trust
host all all 127.0.0.1/32 ident
But:
host all all localhost ident
host all all localhost trust
Remember to reload after saving changes to pg_hba.conf. (Restart is not necessary.) The manual:
The pg_hba.conf file is read on start-up and when the main server
process receives a SIGHUP signal. If you edit the file on an active
system, you will need to signal the postmaster (using pg_ctl reload,
calling the SQL function pg_reload_conf(), or using kill -HUP) to
make it re-read the file.
If you really "add" the lines like you wrote, there should not be any effect at all. But if you replace the lines, there is.
In the first case, you get trust authentication method, which is an open-door policy. The manual:
PostgreSQL assumes that anyone who can connect to the server is
authorized to access the database with whatever database user name
they specify (even superuser names)
But in the second case you get the ident authentication method, which has to be set up properly to work.
Plus, as Cas pointed out later, localhost covers both IPv4 and IPv6, while 127.0.0.1/32 only applies to IPv4.
If you are actually using the outdated version 8.4, go to the old manual for 8.4. You are aware that 8.4 has reached EOL in 2014 and is not supported any more? Consider upgrading to a current version.
In Postgres 9.1 or later you would rather use peer than ident.
More:
Run batch file with psql command without password
The Problem
Postgres will potentially use IPv6 when specifying -h localhost which given the above pg_hba.conf specifies ident, a password prompt will be returned.
However when -h 127.0.0.1 is specified, it forces Postgres to use IPv4, which is set to trust in above config and allows access without password.
The Answer
Thus the answer is to modify the IPv6 host line in pg_hba.conf to use trust:
# IPv6 local connections:
host all all ::1/128 trust
Remembering to restart the Postgres service after making config changes.

MPICH2 on multiple machines (HYDU_sock_connect error)

I am trying to execute an MPI program in 2 different PCs. However, when I ran this command in pc1:
mpirun -hosts user#host -n 4 bin/Demo_01.exe
I'm getting this error:
[proxy:0:0#pc2] HYDU_sock_connect (./utils/sock/sock.c:203): unable to connect from "pc2" to "pc1" (Connection refused)
[proxy:0:0#pc2] main (./pm/pmiserv/pmip.c:209): unable to connect to server ubuntu at port 57395 (check for firewalls!)
Although I configured SSH connections as without password and disabled firewalls on each machines, the error is still there. My operating system is Ubuntu 12.04 and mpi is MPICH2.
Is there anyone to help?
the error is caused by the the client not connecting back to server as it doesnt know the ip of the server i.e
..main (./pm/pmiserv/pmip.c:209): unable to connect to server ubuntu at...etc
the fix is to add each of hostname and related ip in the /etc/hosts i.e
172.17.0.2 master
172.17.0.3 node1
172.17.0.4 node2
this should allow for bi-directional communication of the master and the node clients
I had the same error, but the accepted answer did not help me.
For me in the hosts file I had:
localhost:8
CPUX:2
I should of had:
CPUZ:8
CPUX:2
I.e the name of the node instead of localhost. Maybe this might help some one.
Fixed. After I followed these steps, the error disappeared:
Create administrator user accounts in both machines with the same username and password.
Define hostnames by editing the file: /etc/hosts
Make a clean install of ssh in both machines.
Configure ssh for connecting without a password. To do this follow these links:
http://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/ and http://dustymabe.com/2012/08/18/exchanging-ssh-keys-using-ssh-copy-id/
Locate the executable MPI program into the same paths in both machines.
montekristo_07's answer is mostly correct but not minimal; steps #2 and #3 are not strictly necessary.
You do not need to edit all your hosts' /etc/hosts files, and, if your LAN uses DHCP and you have any local DNS service running, you should not edit all your hosts' /etc/hosts files.
Insure that:
only externally-resolvable hostnames are referenced in your mpiexec command line (i.e. not "localhost"), and
the /etc/hosts file on the master (the machine on which you run mpiexec) does not have a line associating the public name of the master with the loopback address (127.0.0.1)
A simple test is to use literal IP addresses in your mpiexec command line. If this fixes your problem, then it's a hostname resolution problem...somewhere.
What is essential is to remember is that what is passed on your mpiexec command line, in particular host names, are going to be sent to and resolved on remote hosts.

A way to specify a different host in an SSH tunnel from the host in use

I am trying to setup an SSH tunnel to access Beanstalk (to bypass an annoying proxy server).
I can get this to work, but with one caveat: I have to map my Beanstalk host URL (username.svn.beanstalkapp.com) in my hosts file to 127.0.0.1 (and use the ip in place of the domain when setting up the tunnel).
The reason (I think) is that I am creating the tunnel using the local SSH instance (on Snow Leopard) and if I use localhost or 127.0.0.1 when talking to Beanstalk, it rejects the authorisation credentials. I believe this is because Beanstalk use the hostname specified in a request to determine which account the username / password combination should be checked against. If localhost is used, I think this information is missing (in some manner which Beanstalk requires) from the requests.
At the moment I dig the IP for username.svn.beanstalkapp.com, map username.svn.beanstalkapp.com to 127.0.0.1 in my hosts file, then for the tunnel I use the command:
ssh -L 8080:ip:443 -p 22 -l tom -N 127.0.0.1
I can tell Subversion that the repo. is located at:
https://username.svn.beanstalkapp.com:8080/repo-name
This uses my tunnel and the username and password are accepted.
So, my question is if there is an option when setting up the SSH tunnel which would mean I wouldn't have to use my hosts file workaround?
I would add an entry to your hosts file that maps 127.0.0.1 to the hostname you need and then use the hostname to connect to your tunnel.
Update
The hosts file is IMO your best option.