I am running an HSQLDB instance in server mode as a systemd service. To shut it down, I issue the following command:
java -cp $CLASSPATH:/usr/share/java/hsqldbutil.jar:/usr/share/java/hsqldb.jar "org.hsqldb.cmdline.SqlTool" --inlineRc=url=jdbc:hsqldb:hsql://localhost/$DB_NAME,user=SA,password=`cat ~/SA.pwd` --sql="SHUTDOWN;"
As one can see in the command, I connect as user SA with a password read from a file (which only that particular user can read), and specify both in the JDBC URL.
This works as long as SA has an empty password and I just supply password= in the command.
However, if SA has a real password and I supply it here, this fails with the error message:
'password' element must have empty value. For non-empty password, give no password element and you will be prompted for the value.
Is there any way to supply the password in a non-interactive way?
It works if you use a sqltool.rc file instead of --inline-rc. Place a file with the following contents in the home folder of the account which will be issuing the stop command:
urlid my-server
url jdbc:hsqldb:hsql://localhost/db_name
username SA
password CorrectHorseBatteryStaple
Then modify the command line as follows:
java -cp $CLASSPATH:/usr/share/java/hsqldbutil.jar:/usr/share/java/hsqldb.jar "org.hsqldb.cmdline.SqlTool" --sql="SHUTDOWN;" my-server
Where:
my-server is an arbitrary identifier that you define in sqltool.rc and quote in the command line invocation of SqlTool
db_name is the database name assigned at startup
CorrectHorseBatteryStaple is the SA password (as currently stored in ~/SA.pwd).
Change these as appropriate for your system. As sqltool.rc contains credentials, be sure to lock down its permissions as you would for ~/SA.pwd.
Related
I just have a little question about the ktpass command.
I have a user my-test-user with a password myPassword!. I can log in with this account via the username and the password.
But when I use the following command to generate a keytab file, I just can log in with the keytab file (kinit for example).
ktpass /out test.keytab /princ HTTP/test.example.com#MY.REALM /pass * /mapuser my-test-user#MY.REALM /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT
If I try to connect with the username/password, the badPwdCount property is incremented.
My question is : is the ktpass command disable password authentication?
Many thanks.
Short answer: no.
The /pass * option means prompt for password. The /mapuser option means to lookup details in AD. If the value passed in via /pass doesn't match what's stored in AD the /mapuser call will set the password in AD to whatever is passed in.
What build of Windows are you running this on? The build of ktpass that shipped in Windows 2012 has a bug in the /pass parameter handling that appends the enter key escape character into the string sent to AD, so it resets it incorrectly. This was fixed in later OSes.
No, but there are a couple possible factors at play here:
One is that, if /mapuser is specified without also specifying -SetUPN, ktpass will change the UPN of the account in question to match whatever SPN was specified with the /Princ parameter in the command (in either case, /mapuser will register the SPN being requested to the specified user, but it only changes the UPN of that account if -SetUPN is absent).
This is apparently so that Linux clients can successfully get a ticket with this keytab (since from a Linux client using kinit, if we try to obtain a Kerberos ticket using an SPN that is registered to an account as an SPN, but that does not match any account's UPN, kinit will tell us the principal does not exist). Windows clients are able to obtain tickets for SPNs that are just registered as SPNs, without requiring that the service account's UPN match the SPN being requested.
So, if we were to try and authenticate using the account's "regular" UPN (the UPN it had prior to running ktpass, e.g. user#domain.com), after generating the keytab without specifying -SetUPN, then authentication would fail because that UPN is no longer valid.
The other issue is that ktpass does seem to "mangle" the password that is entered when using the /Pass * parameter to force it to prompt for password input. ktpass will either set the password to what we specify (if -SetPass is not included) or it will just create the keytab using the password we specify, taking our word that it is correct (but of course the resulting keytab won't work if an invalid password is given).
Based on my testing, if we enter the password in the command itself (e.g. /Pass P#ssw0rd), the keytab will work fine (assuming the password was correct) and password authentication should also work, although only if we either specify the username in DOMAIN\username format or if we included -SetUPN in our ktpass command, due to the UPN issue noted above.
However, the problem comes when we try to use the /Pass * parameter to avoid having to enter the password in plaintext on the command line. In this case, ktpass prompts us for a password, but it apparently modifies whatever value we enter somehow (behind-the-scenes). This will produce two possible results, depending on the options we specified in our command:
Either the resulting keytab file will be invalid and won't work - this happens if we included the -SetPass parameter (which tells ktpass not to change the account's password), because then ktpass generates a keytab with the mangled password even though the "real" password on the account is the value we entered at the prompt.
Or, the resulting password on the account will be set to an unknown value (and not the value we expect it to be) - i.e. the mangled version of the password we entered - this happens if we did not include -SetPass, in which case ktpass changes the password of the account to whatever value it mangles our input into. In this scenario, the keytab will work, but when we try to authenticate with this account using a password we will get an invalid password error (because the password on the account is not the one we think it is - its not the value we entered at the prompt).
I tested and confirmed this behavior on 2008R2, 2012 and 2012R2 - I was not able to test on anything newer.
To summarize - if you need to know the account's password so that you can authenticate with either method (password or keytab) after the keytab is generated, then you need to enter your password in the ktpass command itself instead of asking ktpass to prompt for it (i.e. use /Pass P#ssw0rd rather than /Pass *). Just be sure you do this in a secure setting where there is no possibility of somebody looking over your shoulder or silently monitoring your screen (luckily Windows by default doesn't log cmd history persistently).
On the other hand, if you don't need to know the account's password once the keytab is created, then its probably best to just use +rndPass - this will force ktpass to generate a random password for the account and the keytab will work just fine.
*EDIT/UPDATE: One other quirk I found when testing is that it seems if a new account is created w/ a known password, and ktpass is run to create a keytab for that account, specifying the password in the command as noted above, but with the -SetPass parameter, the resulting keytab will not work. If we run ktpass and specify the password without -SetPass, to let ktpass "reset" the password (to the same value it already was - the value we set when creating the account), the resulting keytab works fine, as does password authentication. And any subsequent keytabs created from that point onward will work (even if created with -SetPass). I do not have an explanation for this behavior (observed on Server 2012 and 2012R2).
SQL shell(psql) throws me this error when prompting pasword for user postgress psql: error: could not connect to server: fe_sendauth: no password supplied
tried CMD
C:\Users\myuser>psql
Password for user myuser:
psql: error: could not connect to server: fe_sendauth: no password supplied
C:\Users\myuser>psql -U postgres
Password for user postgres:
psql: error: could not connect to server: FATAL: password authentication failed for user "postgres"
found this 1. answer :maybe is this isue
pgpass.conf file needs to put it to PostgreSQL server and not with pgAdmin (client's dir)?? but cant find such file in explorer
pgAdmin 4 works just fine problem is with psql shell
im on WIN 10 ,anyone have same problem and how to solve it?
PS: i managed to work psql shell by setting pg_hba.config file to
host all all 127.0.0.1/32 md5
for ip4 and ip6 i set trust instade md5 and relaoded Postgress service ,but when i reverted back after seting new pasword to md5 same problem and same error
psql: error: could not connect to server: fe_sendauth: no password supplied
pgAdmin 4 still works
I've installed and uninstalled many times and I have managed to get the desired result in the picture below...
Install postgres without changing anything, except entering a new password and open the sql shell by entering 'psql' in your Windows search menu.
Inside SQL shell, keep pressing enter until it prompts you for your
password which you created on the installer
Type your password here, even though it doesn't look like it is
being keyed in and press enter once done.
It should look like...
Server [localhost]:
Database [postgres]:
Port [5432]:
Username [postgres]:
Password for user postgres:
psql (12.2)
WARNING: Console code page (850) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
postgres=#
Install pgadmin from this link pgadmin, enter the password from psql
and you should then see the following...
Click on the server database icon top left and add the password which you entered in psql.
Create a database and get the list.
postgres=# CREATE DATABASE your_database_name OWNER postgres; #Click enter here
CREATE DATABASE #result
postgres=# \l #to get the below datbase list
Go back to pg admin, refresh the browser, and click on the server icon.
Note: Should you need to uninstall/re-install you will need to manually delete the folder where you have installed Postgres and pgadmin. This is even after uninstalling from system settings. For some reason, Postgres folder's don't remove entirely even though you select the option.
I am writing a shell script in Jenkins that logs into a database and runs an sql file. All of the commands are logged to the console, so if I use the simple login method for sqlplus (sqlplus -s $USERNAME/$PASSWORD#connectionstring), the password gets logged, which isn't ideal.
This works:
sqlplus -S ${USERNAME}/${PASSWORD}#connectionstring #sql_update.sql
but the logging on Jenkins shows the command once the values have been substituted:
+ sqlplus user123/pass123#connectionstring #sql_update.sql
To avoid having the password logged, I am trying to use the sqlplus login method where you just provide the username and then get asked to input the password.
I have tried the following, but I am getting ORA-01-17: invalid username/password; logon denied
sqlplus -s ${USERNAME}#\"connectionstring\" <<EOF
${PASSWORD}
sql_update.sql
exit
EOF
Is there something obviously wrong with this?
It's worth noting that simply disabling the console logging isn't an option, as we need it for other things in the script.
Also, the difference between this question and Connect to sqlplus in a shell script and run SQL scripts is that I am asking about providing the password separately.
EDIT I managed to partially resolve the issue thanks to Echo off in Jenkins Console Output. My script now contains set +xbefore the commands are run, which hides the commands. However, I'd still like to know what was wrong with the above, so am leaving this question open for now.
I am using sonarqube from command line. I have a local server (sonarqube 64) on my windows 7 (x86-64). I successfully installed and I can open the web host http://localhost:9000/. but I cannot login the admin/admin login details are not working.
I know there is way of resetting the password but I need database that I don't have and i am the only user/admin.
Is there any way to recover the password or change it? should I uninstall the server and install it again?
It is not said how to properly unistall the server either
Thanks
I'm running 8.5 and this appears to be different, I used:
Change directory to /opt/sonarqube/lib/jdbc/h2
cd /opt/sonarqube/lib/jdbc/h2
Run the command line below to open h2 shell
java -cp h2-1.4.199.jar org.h2.tools.Shell
you will be prompted to fill the following:
URL jdbc:h2:tcp://localhost:9092/sonar
Driver org.h2.Driver
User [none]
Password [none]
You will be prompted now to sql command line (sql>), then type your query:
update users set crypted_password = '$2a$12$uCkkXmhW5ThVK8mpBvnXOOJRLd64LJeHTeCkSuB3lfaR2N0AYBaSi', salt=null, hash_method='BCRYPT' where login = 'admin'
There is no real "installation" for SonarQube; you explode the zip and run one of the start scripts. So if you do decide to scrap your current instance, all you need to do is shut it down, delete the directory and re-explode the zip. However, once you do that, you should seriously consider connecting it to a production database. So far you're running with the embedded H2 database, and that's not appropriate for long-term use. Among other things, migration to new versions is not supported for the H2 database.
Once you've done that, you can reset the admin password by executing the following query:
update users set crypted_password = '88c991e39bb88b94178123a849606905ebf440f5', salt='6522f3c5007ae910ad690bb1bdbf264a34884c6d' where login = 'admin'
That sets it back to 'admin'
For the config below (openjdk-11, sonarqube-8), follow the steps:
Change directory to /opt/sq/lib/jdbc/h2
cd /opt/sq/lib/jdbc/h2
Run the command line below to open h2 shell
java -cp h2-1.3.176.jar org.h2.tools.Shell
you will be prompted to fill the following:
URL jdbc:h2:localhost:9000/data/sonar
Driver org.h2.Driver
User sonar
Password sonar
You will be prompted now to sql command line (sql>), then tap your query:
update users set crypted_password = '88c991e39bb88b94178123a849606905ebf440f5', salt='6522f3c5007ae910ad690bb1bdbf264a34884c6d' where login = 'admin'
Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'admin'#'localhost' (using password: YES) in C:\wamp\www\connect.php on line 6
I've looked for a solution but haven't been able to find one.
The part on line 6 is
mysql_connect($server,$username,$password)
If it has to do with the problem, I'm using WampServer 2.1
Users admin#% and admin#localhost can have different passwords in MySQL. Try without a password.
Check the contents of the mysql.user table to see if your have multiple user records for admin.
This is a nice access model which allows different access depending on server the user is connecting from.
username/password combination should be incorrect.
You must have been prompted to set the password while installing WAMP Server.
You sure you are using the same password?
You can reset the root password by executing the following statement int the command line:-
mysqladmin -u root password NEWPASSWORD
If it complains mysqladmin is not a recognized command, then navigate to <WAMP-FOLDER>/mysql/bin folder before executing that statement.