bconsole - Authorization problem with Director

[George Anchev]

Hi,

I have a problem starting bconsole. Logged in as root I am getting:

# bconsole
Connecting to Director i7:9101
Authorization problem with Director at "i7:9101"
Most likely the passwords do not agree.
If you are using TLS, there may have been a certificate validation error during the TLS handshake.
Please see http://doc.bareos.org/master/html/bareos-manual-main-reference.html#AuthorizationErrors for help.

and in /var/log/bareos/bareos.log:

28-Nov 18:03 i7-dir JobId 0: Security violation: bnet_server_tcp.c:330 Connection from 192.168.0.1:50115 refused by hosts.access

Next attempts give different ports in the log:

28-Nov 18:03 i7-dir JobId 0: Security violation: bnet_server_tcp.c:330 Connection from 192.168.0.1:50117 refused by hosts.access
28-Nov 18:04 i7-dir JobId 0: Security violation: bnet_server_tcp.c:330 Connection from 192.168.0.1:50118 refused by hosts.access
28-Nov 18:04 i7-dir JobId 0: Security violation: bnet_server_tcp.c:330 Connection from 192.168.0.1:50119 refused by hosts.access

I looked at the documentation but it doesn't seem to give an answer to this. All my passwords are ok and even testing with the default .conf files which are created automatically with installation, the situation is the same. I am not using any TLS (as far as I am aware?)

I tried stopping the firewall - nothing changed. Actually I am logged on the machine on which I am testing.

I am using openSUSE Leap 42.1 and Bareos installed and updated from the Bareos repo.

How can I fix this?

[George Anchev]

P.S. All services (dir, fd, sd) are started normally, no errors. But still I can't use the bconsole (same story with bat).

[Bruno Friedmann]

On Saturday 28 November 2015 08.20:40 George Anchev wrote:
> P.S. All services (dir, fd, sd) are started normally, no errors. But still I can't use the bconsole (same story with bat).
>
>

it seems you use hosts.access

If those files exist and are not empty tcpd enforcement is made.
You will have to fill it with the port and hosts necessary to connect bareos.

# See 'man tcpd' and 'man 5 hosts_access' for a detailed description
# of /etc/hosts.allow and /etc/hosts.deny.

By default on openSUSE they are empty.

--

Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot

[Jörg Steffens]

Hi George,

from the error message, your system is using the host_access mechanism,
configured by /etc/hosts.allow and /etc/hosts.deny.

A line of

ALL: LOCAL

in your /etc/hosts.allow should solve this. Anyhow, I doubt, this is
the default behavior of openSUSE Leap 42.1, as this is part of our
automated testing and I've not seen this behavior before.

regards,
Jörg

--
Jörg Steffens joerg.s...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 630693-91
http://www.bareos.com Fax: +49 221 630693-10

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer:
S. Dühr, M. Außendorf, Jörg Steffens, P. Storz, M. v. Wieringen

[George Anchev]

Thanks for the quick responses!

Before replying I spent some time educating myself as I was not familiar with hosts.{allow,deny}. Here is what I found:

1. tcpd is not installed on my system. I wonder: why does Bareos use the hosts.* files then?

2. Interestingly I have these lines in files:

----

# /etc/hosts.deny

# This one is by default from the system installation itself. I read it is a default security measure

http-rman : ALL EXCEPT LOCAL

----

# /etc/hosts.allow

# These I have configured when setting up my NUT configuration according to this guide

upsd : localhost, LOCAL, 127.0.0.1,    [::1]               : ALLOW

upsd : ALL :  spawn (/bin/mail -r hosts.allow@localhost\

                    -s '%s@%h (myusername) refused access to %d from %c'\

                    myusername@localhost) &                    : DENY       

# And now the denials which previously appeared in /etc/hosts.deny

#

ALL :  ALL                                                 : DENY

----

If I comment out this last line (ALL: ALL: DENY) - I can connect to director from bconsole. But here is something interesting: If hit Enter after that last DENY (i.e. there is a new line) in hosts.allow - I cannot connect via bconsole. BUT! if there is no new line - bconsole connects.

Is that a bug?

But perhaps a bigger question is: Why does Bareos use these hosts files at all when tcpd is not installed at all? A bit of a side topic but thinking further - I guess even for upsd I might have not needed to add those lines (it seems I have followed the NUT guide a little blindly but that hasn't caused connectivity issues as with Bareos).

I hope you can look into that and explain how this works.

---

George Anchev

[George Anchev]

More info: I just had a look at journalctl which seems to reflect my attempts:

Nov 29 00:47:05 i7 bareos-dir[6400]: warning: /etc/hosts.allow, line 82: missing newline or line too long

Nov 29 00:48:36 i7 bareos-dir[6400]: warning: /etc/hosts.allow, line 82: missing newline or line too long

Nov 29 00:48:37 i7 bareos-sd[6435]: warning: /etc/hosts.allow, line 82: missing newline or line too long

Nov 29 00:49:29 i7 bareos-dir[6400]: warning: /etc/hosts.allow, line 82: missing newline or line too long

Nov 29 00:49:30 i7 bareos-sd[6435]: warning: /etc/hosts.allow, line 82: missing newline or line too long

[George Anchev]

ALL: LOCAL in /etc/hosts.allow indeed worked (although the questions still remain). But I wonder - if that is a security measure (supposed to work even without tcpd installed) isn't there a way to allow only for Bareos? I tried:

bareos-dir, bareos-fd, bareos-sd : localhost, LOCAL, 127.0.0.1, 192.168.0.0/255.255.255.0, [::1] : ALLOW

bareos-dir, bareos-fd, bareos-sd : LOCAL : ALLOW

but none of these works.

[Bruno Friedmann]

The fact that bareos is builded with tcpwrapper enable
explain why it use those files
See https://en.wikipedia.org/wiki/TCP_Wrapper
see buildout.log in bareos-common package
TCP Wrappers support: yes -lwrap


If you don't manage hosts.allow and hosts.deny correctly you're
just getting trouble.

Again see man 5 host_access

If any lines exist in deny it will deny access especially yours

# And now the denials which previously appeared in /etc/hosts.deny
#
ALL : ALL : DENY

Will deny any access of daemons that are not specified in allow.
By defaut on openSUSE only one line exist

http-rman : ALL EXCEPT LOCAL

I don't know from where come yours.

I don't really understand what you try to achieve, when simple
firewall rules and configuration in bareos would to the same.

btw, here's a man page for bacula which also apply to bareos
to get some inspiration
http://manpages.ubuntu.com/manpages/hardy/man8/bacula-dir.8.html

TCP-WRAPPERS CONFIGURATION

Tcpwrappers looks for the service name of the bacula daemons in
hosts.allow , and the service names of these daemons is configured to
be different from the binary. The service names are configured to be
%hostname%-%component% rather than bacula-dir (As defined in the
bacula-dir.conf.in file)

So the hosts.allow entry has to match %hostname%-%component%
(servername-dir for example) instead of bacula-%component%

WARNING: This means that if the hosts.allow file has the entry:

bacula-dir: ALL

you will not be able to run bconsole to connect to the local director!

The entry would have to read:

server-dir: ALL

and this will allow the console to connect to the director. (The
process running is bacula-dir.)


Hope this help.

[George A.]

Thanks Bruno! This really helped:

servername-dir : localhost, LOCAL, 127.0.0.1, 192.168.0.0/255.255.255.0, [::1] : ALLOW

Do I also need to add lines like:

servername-fd : ...
servername-sd : ...

in the hosts.allow for each file/storage daemon on the LAN to make it possible for all daemons to communicate with each other OR is that necessary only for the director?

Also do I need to add such lines on each separate machine running a file daemon? This is the first time I am using a tcpwrapper program.

[George Anchev]

I found the answer to my own question: Yes, server-fd and server-sd also need to be allowed in hosts.allow.