The salted hash being different is fine, the bcrypt library generates a random 128 bit salt when encrypting a new password. The salt is then encoded in the hashed string so you'd expect a different salted_hash each time a given plaintext string is encoded.
I inserted exactly that data into a clean system, then switched it to use PasswordAuthenticator and I can login using the default credentials without any issue. Did you also drop the legacy credentials table (system_auth.credentials) as per the upgrade docs that I linked yesterday (in NEWS.txt)? If you didn't, the authenticator will continue to read from the old table (you don't need a restart after dropping, the switch will happen immediately). On 18 July 2018 at 12:12, Thomas Lété <thomas.l...@soprism.com> wrote: > It’s my mail client that changed the quote mark, I didn’t see it, it’s > just an export of the data I get from DevCenter, the salted hash is not the > same as I saw in this guide : https://support.datastax. > com/hc/en-us/articles/207932926-FAQ-How-to-recover- > from-a-lost-superuser-password > But it should be correct as it was generated by Cassandra itself yesterday. > > The export : > cassandra@cqlsh> SELECT * from system_auth.roles; > > role | can_login | is_superuser | member_of | salted_hash > -----------+-----------+--------------+-----------+--------- > ----------------------------------------------------- > cassandra | True | True | null | $2a$10$ > 7sXeNr3okw61oisR9pCyHeWEO3wPzx3w8r/LKwtDSW2Tt68f4KFmi > > Le 18 juil. 2018 à 12:26, Sam Tunnicliffe <s...@beobal.com> a écrit : > > It may be an artifact of the email client, but that's not a valid INSERT > statement - the closing quote on the password hash is U2019 (right side > quotation mark) but the opening quote is U0027 (apostrophe) - which is what > cqlsh expects. Can you just SELECT * from system_auth.roles and check that > the salted_hash is correct? > > On 18 July 2018 at 11:06, Thomas Lété <thomas.l...@soprism.com> wrote: > >> Yes it’s the config I’m using and I’m trying to add the Password Auth to >> :-) >> >> Here is the content of the roles table : >> >> INSERT INTO roles (role,can_login,is_superuser,member_of,salted_hash) >> VALUES ('cassandra',true,true,null,'$2a$10$7sXeNr3okw61oisR9pCyHeWE >> O3wPzx3w8r/LKwtDSW2Tt68f4KFmi’); >> >> It seems correct but I’m not able to authenticate (using cqlsh v5.0.1 or >> DevCenter 1.6.0) >> >> I’m starting to consider going from scratch and use the default config >> and check if it works... >> >> Le 18 juil. 2018 à 12:03, Sam Tunnicliffe <s...@beobal.com> a écrit : >> >> With that config you'll be using the default AllowAllAuthenticator, so I >> assume you are able to connect cqlsh without any credentials? If so, can >> you verify the contents of the system_auth.roles table? It should contain >> only the cassandra user. >> >> On 18 July 2018 at 08:02, Thomas Lété <thomas.l...@soprism.com> wrote: >> >>> I’m using the default ones, the commented parts are the one I use when I >>> try the PasswordAuthenticator :) (line 19 to 24) >>> >>> > Le 18 juil. 2018 à 08:51, Horia Mocioi <horia.moc...@ericsson.com> a >>> écrit : >>> > >>> > If this is the file that you are currently using...he first things that >>> > I see is that you do not have any authenticator and role_manager: >>> > >>> > https://github.com/apache/cassandra/blob/1d506f9d09c880ff2b2 >>> 693e3e27fa5 >>> > 8c02ecf398/conf/cassandra.yaml#L103 >>> > >>> > https://github.com/apache/cassandra/blob/1d506f9d09c880ff2b2 >>> 693e3e27fa5 >>> > 8c02ecf398/conf/cassandra.yaml#L123 >>> > >>> > On ons, 2018-07-18 at 08:33 +0200, Thomas Lété wrote: >>> >> Unfortunately, I’m not a java dev so I’m not able to create an >>> >> authenticator… >>> >> >>> >> I don’t like to do that usually but I share with you a gist of the >>> >> config, it was generated by OpsCenter when it was free, I just >>> >> updated it for Cassandra >= 3… Maybe you will see something : >>> >> >>> >> https://gist.github.com/bistory/ececc0bef7627f39a21e4e8f0c8d841c >>> >> >>> >>> Le 18 juil. 2018 à 00:28, Horia Mocioi <horia.moc...@ericsson.com> >>> >>> a écrit : >>> >>> >>> >>> Cassandra allows to use custom authenticators so I would create a >>> >>> CustomPasswordAuthenticator. This would be a copy of the existing >>> >>> PasswordAuthenticator. I would add several debugging info like: >>> >>> provided username and password, the output of the checkpw function, >>> >>> what cql statement is executed etc (any other info that would help >>> >>> me to understand what is being executed in the authenticator). >>> >>> From: Thomas Lété <thomas.l...@soprism.com> >>> >>> Sent: Tuesday, July 17, 2018 5:24:39 PM >>> >>> To: user@cassandra.apache.org >>> >>> Subject: Re: System auth empty, how to populate it >>> >>> >>> >>> Thanks for your reply, >>> >>> >>> >>> - I have not defined role_manager in the config >>> >>> - I dropped the users table, it was present in the keyspace >>> >>> - Cassandra then created a record in the roles table, yay ! >>> >>> >>> >>> But when I do clash -u cassandra -p cassandra >>> >>> >>> >>> => Invalid credentials supplied. >>> >>> Authentication error on host xxxxxx: Provided username cassandra >>> >>> and/or password are incorrect >>> >>> >>> >>> I already repaired system_auth a few times, nothing help... >>> >>> >>> >>>> Le 17 juil. 2018 à 16:47, Sam Tunnicliffe <s...@beobal.com> a >>> >>>> écrit : >>> >>>> >>> >>>> The default superuser is only created at startup if 3 conditions >>> >>>> are met: >>> >>>> >>> >>>> i) The default role manager is configured. In cassandra.yaml, you >>> >>>> should see "role_manager: CassandraRoleManager". This is also the >>> >>>> default value, so unless you're explicitly using a custom role >>> >>>> manager it should be good. >>> >>>> ii) The system_auth.users table (legacy, pre-2.2) should not be >>> >>>> present. Present means present in the schema, not on disk. Unlike >>> >>>> most system tables, this table is droppable (in fact this is a >>> >>>> necessary step in upgrading from earlier versions). >>> >>>> iii) There should be no preexisting roles present in the >>> >>>> system_auth.roles table. This is verified with a regular query, >>> >>>> so you must either use CQL to delete existing roles, or remove >>> >>>> the data directories and commit logs on *all* nodes. >>> >>>> >>> >>>> Even if these three conditions are met, but the default user >>> >>>> isn't being created the manual insert that Horia suggested should >>> >>>> work. If system_auth.roles table exists and you are able to >>> >>>> perform the insert, I'm very surprised when you say it's empty >>> >>>> after you issue the insert. If you check again and it turns out >>> >>>> the manual insert is working as expected, you need to make sure >>> >>>> that the legacy tables have been dropped from schema (assuming >>> >>>> you upgraded from a pre-3.0 version at some point). If the legacy >>> >>>> tables are still present, the authenticator will continue to read >>> >>>> from them and so would be ignoring the new entry in the roles >>> >>>> table. (see: https://github.com/apache/cassandra/blob/cassandra-3 >>> >>>> .11.2/NEWS.txt#L619-L640) >>> >>>> >>> >>>> >>> >>>> On 17 July 2018 at 15:18, Thomas Lété <thomas.l...@soprism.com> w >>> >>>> rote: >>> >>>> Yes I did that multiple time, always following the same procedure >>> >>>> : stop Cassandra, on all nodes, remove data, update config then >>> >>>> restart nodes one by one… >>> >>>> >>> >>>> I really don’t understand when I could have done wrong... >>> >>>> >>> >>>>> Le 17 juil. 2018 à 16:15, Simon Fontana Oscarsson <simon.fontan >>> >>>> a.oscars...@ericsson.com> a écrit : >>> >>>>> >>> >>>>> This is very strange behavior if Cassandra won't recreate the >>> >>>> cassandra user when you delete the folder. >>> >>>>> So just to make sure, you are stopping Cassandra on all nodes >>> >>>> and deleting the data directory? >>> >>>>> >>> >>>>> -- >>> >>>>> SIMON FONTANA OSCARSSON >>> >>>>> Software Developer >>> >>>>> >>> >>>>> Ericsson >>> >>>>> Ölandsgatan 1 >>> <https://maps.google.com/?q=%C3%96landsgatan+1+%0D%0A+37133+Karlskrona,+Sweden&entry=gmail&source=g> >>> >>>>> 37133 Karlskrona, Sweden >>> <https://maps.google.com/?q=%C3%96landsgatan+1+%0D%0A+37133+Karlskrona,+Sweden&entry=gmail&source=g> >>> >>>>> simon.fontana.oscars...@ericsson.com >>> >>>>> www.ericsson.com >>> >>>>> >>> >>>>> On tis, 2018-07-17 at 16:01 +0200, Thomas Lété wrote: >>> >>>>>> It’s empty... >>> >>>>>> >>> >>>>>>> >>> >>>>>>> Le 17 juil. 2018 à 15:59, Horia Mocioi <horia.mocioi@ericsson >>> >>>> .com> a écrit : >>> >>>>>>> >>> >>>>>>> Could you also send the output of "select * from >>> >>>> system_auth.roles"? >>> >>>>>>> (you will need to change authenticator to >>> >>>> AllowAllAuthenticator and >>> >>>>>>> authorizer to AllowAllAuthorizer) >>> >>>>>>> >>> >>>>>>> On tis, 2018-07-17 at 15:43 +0200, Thomas Lété wrote: >>> >>>>>>>> >>> >>>>>>>> Ok I tried that, nothing better (I already tried dropping >>> >>>> the entire >>> >>>>>>>> system_auth folder that way, same result) >>> >>>>>>>> >>> >>>>>>>> When I open the log, I found nothing about « Password » and >>> >>>> when I >>> >>>>>>>> search for « roles », I only find that : >>> >>>>>>>> >>> >>>>>>>> DEBUG [main] 2018-07-17 15:37:39,420 >>> >>>>>>>> CompactionStrategyManager.java:380 - Recreating compaction >>> >>>> strategy - >>> >>>>>>>> disk boundaries are out of date for system_auth.roles. >>> >>>>>>>> DEBUG [main] 2018-07-17 15:37:39,420 >>> >>>> DiskBoundaryManager.java:53 - >>> >>>>>>>> Refreshing disk boundary cache for system_auth.roles >>> >>>>>>>> DEBUG [main] 2018-07-17 15:37:39,422 >>> >>>> DiskBoundaryManager.java:56 - >>> >>>>>>>> Updating boundaries from >>> >>>>>>>> >>> >>>> DiskBoundaries{directories=[DataDirectory{location=/home/cassandr >>> >>>> a/da >>> >>>>>>>> ta}], positions=[max(9223372036854775807)], ringVersion=3, >>> >>>>>>>> directoriesVersion=0} to >>> >>>>>>>> >>> >>>> DiskBoundaries{directories=[DataDirectory{location=/home/cassandr >>> >>>> a/da >>> >>>>>>>> ta}], positions=[max(9223372036854775807)], ringVersion=16, >>> >>>>>>>> directoriesVersion=0} for system_auth.roles >>> >>>>>>>> >>> >>>>>>>> The configuration I use for Auth is the following : >>> >>>>>>>> >>> >>>>>>>> authorizer: CassandraAuthorizer >>> >>>>>>>> permissions_validity_in_ms: 2000 >>> >>>>>>>> permissions_update_interval_in_ms: 2000 >>> >>>>>>>> authenticator: PasswordAuthenticator >>> >>>>>>>> credentials_validity_in_ms: 2000 >>> >>>>>>>> credentials_update_interval_in_ms: 2000 >>> >>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> Le 17 juil. 2018 à 15:26, Simon Fontana Oscarsson >>> >>>> <simon.fontana.os >>> >>>>>>>>> cars...@ericsson.com> a écrit : >>> >>>>>>>>> >>> >>>>>>>>> Could you try the following steps? >>> >>>>>>>>> >>> >>>>>>>>> Stop Cassandra. >>> >>>>>>>>> Change authenticator in yaml to PasswordAuthenticator if >>> >>>> not >>> >>>>>>>>> already done. >>> >>>>>>>>> Remove data directory with `rm -rf data/system_auth/roles- >>> >>>> *` >>> >>>>>>>>> Start Cassandra. >>> >>>>>>>>> Login with `cqlsh -u cassandra -p cassandra` >>> >>>>>>>>> >>> >>>>>>>>> Works for me. >>> >>>> >>> >>>> >>> >>>> --------------------------------------------------------------- >>> >>>> ------ >>> >>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> >>>> For additional commands, e-mail: user-h...@cassandra.apache.org >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> > For additional commands, e-mail: user-h...@cassandra.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: user-h...@cassandra.apache.org >>> >>> >> >> > >
