Kibana login username & password

Can I disable it ? Where do I set a username and password? It is the first time I am running the Kibana 5.

I think I understood the issue. I need to disable the xpack security in both elasticsearch.yml and kibana.yml.

Right?

Still stuck with no abilities to open the kibana without login user and pass

Hi @ssasporta,

setting xpack.security.enabled: false in both the elasticsearch.yml and the kibana.yml should remove the login screen and allow completely unauthorized access to both Elasticsearch and Kibana. Did you restart both processes after changing those settings?

After setting this line in both yml files & restarting both elasticsearch & kibana, when I am trying to reach the kibana via browser, I am getting a note in the browser:
This site can't be reached.
<My machine IP> refused to connect.

That sounds like an unrelated problem. Would it be able for you to provide the Elasticsearch and Kibana logs?

BTW: Instead of disabling Security, you can also opt to configure it to your needs. The documentation contains a detailed Getting Started With Security Guide, which introduces the concepts and also shows specific configuration steps.

How can I send the logs? email? I can't upload them here.

There seems to be a permission problem with some of the Kibana files, that prevents the Kibana server from serving the web UI. This is probably the result of kibana-plugin having been called as root, thereby setting the wrong owner on some files. Running chown -R kibana:kibana /usr/share/kibana/optimize should fix that.

I had to run this with sudo.

Anyway, I also tried to go on the direction of enabling the security.

In stage 4b it says: Copy the generated system key to the rest of the nodes in the cluster

I am not really understand to where else should I copy the generated key? What are the rest of the nodes in the cluster?

Elasticsearch has built-in clustering capabilities, which means that it can distribute the storage and processing across multiple cooperating Elasticsearch nodes. This key protects the communication between the nodes in the cluster from tampering. Since it is a symmetric key, it needs to be present on all nodes in the cluster. If you are only running a single-node cluster (which is not recommended for most production scenarios) you don't need to copy the key anywhere.

It is a test environment not distributed. I will implement it in production when time come.
Thanks

Actually I tried that, I saw that all owner of the files changed to kibana, But still I can't open the kibana.

This what the browser is returning:

The 10.235.81.127 page isn’t working

10.235.81.127 redirected you too many times.

I tried to unmark the monitoring enable line in both ymls, and I am getting the following from the browser:

This site can’t be reached

10.235.81.127 refused to connect.

Still not able to connect:

This is from the kibana log:

{"type":"response","@timestamp":"2016-12-14T19:44:15Z","tags":[],"pid":64840,"method":"get","statusCode":302,"req":{"            url":"/login?next=%2Fapp%2Fkibana","method":"get","headers":{"host":"10.235.81.127:5601","connection":"keep-alive","c            ache-control":"max-age=0","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebK            it/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36","accept":"text/html,application/xhtml+xml,applicatio            n/xml;q=0.9,image/webp,*/*;q=0.8","accept-encoding":"gzip, deflate, sdch","accept-language":"en-US,en;q=0.8"},"remote            Address":"10.233.161.168","userAgent":"10.233.161.168"},"res":{"statusCode":302,"responseTime":1,"contentLength":9},"            message":"GET /login?next=%2Fapp%2Fkibana 302 1ms - 9.0B"}
{"type":"response","@timestamp":"2016-12-14T19:44:15Z","tags":[],"pid":64840,"method":"get","statusCode":302,"req":{"            url":"/app/kibana","method":"get","headers":{"host":"10.235.81.127:5601","connection":"keep-alive","cache-control":"m            ax-age=0","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML            , like Gecko) Chrome/54.0.2840.99 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,imag            e/webp,*/*;q=0.8","accept-encoding":"gzip, deflate, sdch","accept-language":"en-US,en;q=0.8"},"remoteAddress":"10.233            .161.168","userAgent":"10.233.161.168"},"res":{"statusCode":302,"responseTime":3,"contentLength":9},"message":"GET /a            pp/kibana 302 3ms - 9.0B"}

When I try to connect kibana with enabling security,

In the elasticsearch, in the following log file: valuePack_access.log

I see:

[2016-12-14T21:51:43,308] [rest] [authentication_failed] origin_address=[127.0.0.1], principal=[kibana], uri=[/]
[2016-12-14T21:51:49,190] [rest] [authentication_failed] origin_address=[127.0.0.1], principal=[kibana], uri=[/]
[2016-12-14T21:51:49,374] [rest] [authentication_failed] origin_address=[127.0.0.1], principal=[kibana], uri=[/]
[2016-12-14T21:51:51,840] [rest] [authentication_failed] origin_address=[127.0.0.1], principal=[kibana], uri=[/]
[2016-12-14T21:51:52,363] [rest] [authentication_failed] origin_address=[127.0.0.1], principal=[kibana], uri=[/.reporting-*/esqueue/_search?version=true]

This indicates that Kibana itself fails to authenticate with Elasticsearch. After updating the password for the kibana user in Elasticsearch, have you also configured Kibana to use that password by setting elasticsearch.password: "<yournewkibanapassword>" in the kibana.yml (see Step 1 of https://www.elastic.co/guide/en/x-pack/current/kibana.html).

This is necessary, because there are two layers of access that are required for a secured Kibana:

  1. Kibana needs to be able to read and write the .kibana index and monitoring api. For this the configured elasticsearch.username and elasticsearch.password are used.
  2. The user needs to authenticate with Elasticsearch on each request to read the actual data he wants to visualize in Kibana. This is done using the username/password the user entered when logging in.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.