Console won't accept the same password the default UI does

  • Platform information:

    • Hardware: x64, 64GB RAM, 4TB disk
    • OS: Fedora 33
    • Java Runtime Environment: openjdk 11.0.11 2021-04-20
    • openHAB version: 3.0.2
  • Issue of the topic: So I’ve installed OpenHAB, and hit up localhost:8080. I ran through the quick start wizard there, and set up a new administrator user and password. However, I can’t start the console, it seems. I tried:

      openhab-cli console -u dmwit
      /usr/share/openhab/runtime/bin/client -u dmwit
      ssh -p 8101 dmwit@localhost
    

    All three fail in essentially the same mode: they prompt me for my password a few times, then tell me there are no more authentication methods available and exit with a non-zero code. (Full output included below.) I confirmed by jumping to localhost:8080 in my browser, logging out, and logging back in that the user and password I was entering are correct. I also peeked in /var/lib/openhab/jsondb/users.json. The user there looks sane (though I wasn’t able to work out the right way to combine my password and the base64-decoded salt to get the same base64-encoded hash as is listed there). I’ll include the full content of that file below as well, though I’m going to manually cut out the apiTokens section since I’m not as confident that it has no secrets in it as I am about the other bits.

    Just for fun, I also tried using the user/password reported in many places online as the default (openhab/habopen) as well as waving a dead chicken over it (openhab/admin, openhab/<dmwit’s password>, admin/admin, admin/habopen, admin/<dmwit’s password>), all with the same behavior.

    What am I doing wrong?

  • Please post configurations (if applicable):

      /var/lib/openhab/jsondb/users.json:
      {
        "dmwit": {
          "class": "org.openhab.core.auth.ManagedUser",
          "value": {
            "name": "dmwit",
            "passwordHash": "IWkm2xjNcbLzQwKsZiCYYOr1ukp1hb/xLOyxyfzOazMMSMyLZ18zzIZoK+7zhzDwGzretbVGVYAVfspU9ZTtgA==",
            "passwordSalt": "y8PtC4FoKLWidOqUNEvnBI2a5E0TN0Pm+F6Gn85Z7WFzi6tYysI/tU78pY6XMr7wjlUF+guFQCSLU57iENrAKA==",
            "roles": [
              "administrator"
            ],
            "sessions": [
              {
                "sessionId": "865e91a8-f486-4787-ba38-006f8baf0f02",
                "refreshToken": "b9cad681843b4a2d9e2bf7f0c611ee83",
                "createdTime": "May 22, 2021, 9:16:59 PM",
                "lastRefreshTime": "Jun 1, 2021, 10:41:52 PM",
                "clientId": "http://localhost:8080",
                "redirectUri": "http://localhost:8080",
                "scope": "admin",
                "sessionCookie": true
              },
              {
                "sessionId": "ca5e1ea2-83fd-4350-b099-06f5fa912b3a",
                "refreshToken": "2990bdf86cdb4df897361fc530f35e3b",
                "createdTime": "Jun 1, 2021, 10:56:15 PM",
                "lastRefreshTime": "Jun 1, 2021, 10:56:15 PM",
                "clientId": "https://localhost:8443",
                "redirectUri": "https://localhost:8443",
                "scope": "admin",
                "sessionCookie": true
              }
            ]
          }
        }
      }
    
  • If logs were generated please post these here using code fences:

      openhab-cli console -u dmwit OR /.../client -u dmwit:
      Logging in as dmwit
      Password:  
      Password:  
      Password:  
      No more authentication methods available
      zsh: exit 1
    
      ssh -p 8101 dmwit@localhost
      Password authentication
      Password: 
      Password authentication
      Password: 
      Password authentication
      Password: 
      dmwit@localhost's password: 
      Permission denied, please try again.
      dmwit@localhost's password: 
      Permission denied, please try again.
      dmwit@localhost's password: 
      dmwit@localhost: Permission denied (keyboard-interactive,password,publickey).
      zsh: exit 255

I ssh to the server openhab is on.

ssh -p 8101 openhab@localhost

Password is habopen

Webbased login and karaf console login users are not the same they are separated and use different user ‘database’ configuration.
To login to the karaf console openhab/habopen works:


openhab-cli console

Logging in as openhab
Password:  

                           _   _     _     ____  
   ___   ___   ___   ___  | | | |   / \   | __ ) 
  / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \ 
 | (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )
  \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/ 
       |_|       3.0.2 - Release Build

Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.

openhab>

Karaf login users are stored in /var/lib/openhab/etc/users.properties
webui login users are stored in /var/lib/openhab/jsondb/users.json

As mentioned in the original post, I have tried user openhab, password habopen, with the same results: three failed password prompts, then an error message and it quits.

Is this openjdk or is it Zulu 11 ? If it is not Zulu, please change your java version. See the prerequisits, openjdk is not recommended.

You don’t need to add -u to pass a user. the console parameter automatically uses user openhab.

ok. But it was not shown in the explicitly mentioned code you used.
What is the content of you /var/lib/openhab/etc/users.properties file ?

@hmerk Thanks for the suggestion. I have switched to Zulu 11:

% java --version
openjdk 11.0.11 2021-04-20 LTS
OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)

Even after stopping and restarting openhab, the behavior remains the same: neither dmwit/<dmwit’s password> nor openhab/habopen are accepted as username/password pairs, for either openhab-cli console or ssh.

@Wolfgang_S users.properties looks like this:

################################################################################
#
#    Licensed to the Apache Software Foundation (ASF) under one or more
#    contributor license agreements.  See the NOTICE file distributed with
#    this work for additional information regarding copyright ownership.
#    The ASF licenses this file to You under the Apache License, Version 2.0
#    (the "License"); you may not use this file except in compliance with
#    the License.  You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#    Unless required by applicable law or agreed to in writing, software
#    distributed under the License is distributed on an "AS IS" BASIS,
#    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#    See the License for the specific language governing permissions and
#    limitations under the License.
#
################################################################################

#
# This file contains the users, groups, and roles.
# Each line has to be of the format:
#
# USER=PASSWORD,ROLE1,ROLE2,...
# USER=PASSWORD,_g_:GROUP,...
# _g_\:GROUP=ROLE1,ROLE2,...
#
# All users, groups, and roles entered in this file are available after Karaf startup
# and modifiable via the JAAS command group. These users reside in a JAAS domain
# with the name "karaf".
#
openhab = {CRYPT}4F61A0FD056BC0FD8231899EC4D9F9CA06AF0DEC895B2A3B0773F6FBC1C99776{CRYPT},_g_:admingroup
_g_\:admingroup = group,admin,manager,viewer,systembundles

From some documentation for karaf online, I also checked org.apache.karaf.jaas.cfg and can confirm that it is using sha256 and that echo -n habopen | sha256sum produces the 4f…76 hash included in users.properties. For reference, its contents is:

encryption.prefix = {CRYPT}
encryption.suffix = {CRYPT}
encryption.algorithm = SHA-256
encryption.encoding = hexadecimal
encryption.enabled = true
encryption.name = basic

that is expected behavior.

that is unexpected.
Just to check if java is listening on the port 8101 could you show what the output of command

netstat -tulpn | grep java

that should show a collection of ports that OH is listening on

What is the content of /etc/hosts ?

Looks like java (and specifically openhab, verified via cat /proc/98336/cmdline) is listening on quite a few ports:

tcp6       0      0 :::8443                 :::*                    LISTEN      98336/java          
tcp6       0      0 127.0.0.1:8101          :::*                    LISTEN      98336/java          
tcp6       0      0 127.0.0.1:39749         :::*                    LISTEN      98336/java          
tcp6       0      0 :::5007                 :::*                    LISTEN      98336/java          
tcp6       0      0 :::8080                 :::*                    LISTEN      98336/java          
udp6       0      0 :::5353                 :::*                                98336/java          
udp6       0      0 :::5353                 :::*                                98336/java

My /etc/hosts is super boring:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

That looks ok.

Could you please once again post a screenshot of what command you use and what is shown when you are asked for the password.

@hmerk Don’t trust me, eh? :slight_smile:

I don’t blame you, beginners can screw up or lie without even realizing they’re doing it; I’ve seen it happen myself with other technologies where I’m the expert. That said, I’m morally opposed to taking a screenshot when a text dump will do; if this is the part where I’m lying without realizing it I guess I’ll be pretty shocked!

I’ve tried many, many things at this point, but I suspect these two will be the ones you are most interested in:

~% openhab-cli console

Logging in as openhab
Password:  
Password:  
No more authentication methods available
zsh: exit 1     openhab-cli console
openhab-cli console  0.90s user 0.11s system 31% cpu 3.226 total
~% ssh -p 8101 openhab@localhost
Password authentication
Password: 
Connection to localhost closed by remote host.
Connection to localhost closed.
zsh: exit 255   ssh -p 8101 openhab@localhost

At each password prompt, I typed habopen and pressed enter.

Not a matter of trust, but your former post showed using -u as pram and I wanted to make shure this is not the case now.
You proofed it.
I have seen the „no more authentication methods available“ when using an older version of putty to ssh into my servers.
So as a rough guess, there could be something wrong with your ssh client…
You could do a google search for this error message in combination with your OS and ssh.

EDIT: please try

ssh -vvv -p 8101 openhab@localhost

which gives a more verbose output.

the openhab-cli console command runs java to start the console - so it is independent of the ssh client.
Nevertheless it is a good idea to check the -vvv output of a ssh login trial.

Good point, never looked into the scripts, so did not know.

I just realized that also the openhab-cli command support verbose output which might be very usefull:

openhab-cli console -v -v -v

resp.

openhab-cli console -v -v -v -v
1 Like

Sheesh, verbose mode! Should have thought of that myself in the first place. Shameful.

@Wolfgang_S Thank you very much for that suggestion. With a bit of digging through that output, I discovered why openhab-cli console wasn’t working right: I have the following snippet in ~/.ssh/config:

Host *
User dmwit

This almost always does the right thing – but in this case, it seems to be overriding openhab’s selection of a user when calling its client. I consider that a bug in client – a user specified on the openhab-cli console command line should override any passive configuration available from ~/.ssh/config, like it does for the OpenSSH SSH client. Anyway, for future visitors, here’s the workaround I’m using for now. I’ve added another host to my SSH config, like this:

Host openhab
HostName localhost
User openhab

After that, openhab-cli console -h openhab does the trick.

…even after that, ssh -p 8101 openhab@openhab doesn’t do the right thing, and even adding -vvv didn’t reveal anything I found enlightening. What’s especially puzzling there is that it seems as though I successfully authenticate, and then it kicks me out. Here’s a snippet from the end of the output:

debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
Password authentication
debug2: input_userauth_info_req: num_prompts 1
Password: 
debug3: send packet: type 61
debug3: receive packet: type 52
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to localhost ([127.0.0.1]:8101).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 5 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
<snipped: a bunch more similar lines listing which environment variables got ignored and which sent>
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 2097152 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 6/7/8 sock -1 cc -1)

debug3: fd 1 is not O_NONBLOCK
Connection to localhost closed by remote host.
Connection to localhost closed.
Transferred: sent 1968, received 1464 bytes, in 0.0 seconds
Bytes per second: sent 155246.1, received 115487.9
debug1: Exit status -1
debug1: compress outgoing: raw data 469, compressed 322, factor 0.69
debug1: compress incoming: raw data 27, compressed 33, factor 1.22
zsh: exit 255   ssh -p 8101 openhab@openhab -vvv

I’m happy to include the entire output if you think it would be useful, but the first bits looked mostly like setup and checking that my public keys weren’t good enough authentication (they’re not, and I don’t expect them to be).

Although I think probability of it is caused by the following is very low let me ask:

  • is SELinux enabled on your system ? If yes, does it behave different in case it’s disabled ?
  • fd 1 mentioned in the debug output is STDOUT isn’t it ? This makes me remembering that I once had a problem with redirecting them with a specific shell. Could you try using a different ( default ) shell than zsh ?
  • try a strace run ( strace ssh -p 8101 openhab@openhab ) maybe it helps to identify what is failing as last step

I am also having this issue with OH 2.5.12.


                  openHAB 2.5.12 (Release Build)


Looking for a place to get started? Check out 'sudo openhabian-config' and the
documentation at https://www.openhab.org/docs/installation/openhabian.html
The openHAB dashboard can be reached at http://openHABianDevice:8080
To interact with openHAB on the command line, execute: 'openhab-cli --help'

openhabian@openHABianDevice:~ $ openhab-cli console

Logging in as openhab
Password:
Password:
No more authentication methods available

Any suggestions?

what did you enter ?
Is the issue new and it worked before ?