Recently I started learning php and sql because I have a fair bit of front end understanding, so I wanted to strengthen my understanding of back end systems. I bought a raspberry pi, and set up a simple LAMP server, which works great(ish). I can run php form it which is a good start.
However, I installed MariaDB v10.3.22 and I am having a lot of trouble with it. Upon successful installation, I went to log in, and expected a blank password. That didn't work.
mysql -u root -p
I get the error ERROR 1698 (28000): Access denied for user 'root'#'localhost' And because it was a fresh install I tried:
mysql_secure_installation
Anyway, I eventually found out that typing sudo mysql -u root -p would let me in, without a password at all. In fact even running the secure install with sudo made it work, meant I didn't need to enter a correct password. I could enter whatever password I wanted to get into the MariaDB shell and the secure script when running sudo, and it only worked with the root db user. Why is this? Why can sudo bypass all of this, especially because I haven't seen any use of sudo in the documentation.
I created a new user with full permissions and it works fine, I don't need sudo and the password actually works.
Sorry if this is confusing, but this is the best I can explain it because I am just as confused.
Thanks,
Angus
This may be due to the Unix Socket authentication plugin being used by the root user.
As the documentation for the plugin elaborates:
The unix_socket authentication plugin allows the user to use operating system credentials when connecting to MariaDB via the local Unix socket file.
The unix_socket authentication plugin works by calling the getsockopt system call with the SO_PEERCRED socket option, which allows it to retrieve the uid of the process that is connected to the socket. It is then able to get the user name associated with that uid. Once it has the user name, it will authenticate the connecting user as the MariaDB account that has the same user name.
Assuming that you aren't logged as root on your shell session, by running sudo mysql -u root -p you execute the command as root, and that's why you are not bypassing the authentication, it's just using the socket authentication as intended. It does not require a password since the OS user matches the MySQL user.
You can check if the root uses the Unix Socket authentication by doing the following:
MariaDB [(none)]> SELECT User, Host, plugin FROM mysql.user;
+------+-----------+-------------+
| User | Host | plugin |
+------+-----------+-------------+
| root | localhost | unix_socket |
+------+-----------+-------------+
I also suggest you to check this other question which addresses the same situation on MySQL.
Related
I have been locked out of ssh. I'm on the Google Cloud, so I can move the hd over and change the ssh config files, but after a few attempts, I cannot login still. The problem began shortly after I changed the password to the primary account, but since SSH was not using password authentication, I am surprised that affected SSH. I tried turning password authentication on, generating new keys, have Google's platform generate new keys, etc, but nothing has allowed me to log in.
I keep getting this error, regardless of key combo or whether or not password authentication is on.
Permission denied (publickey).
I have a slightly older backup (a couple hours, before the issue), and it's telling me too many authentication failures for any user (regarless of user#domain.com).
I was wondering if there are any config setting I can set to be able to log back in.
Not sure this belongs stackoverflow or serverfault but..
Try adding -vv to your ssh command. It shows a lot more debugging info
For example:
ssh -vv username#host
See if that gets you any hints! It could be a number of things, it searching for private key in the wrong place, etc.
The issue could be ssh keys saved in your local computer. Can you move the ssh keys from .ssh/ to a different directory in your local computer and see if that resolves the issue.
Or can you enable password authentication for your ssh and use -o flag with ssh command which forces non-key authentication to confirm if the issue was with the key: ssh -o PubkeyAuthentication=no username#
You also set MaxAuthTries to higher number in your sshd_config.
Jenkins keeps using the default "jenkins" user when executing builds. My build requires a number of SSH calls. However these SSH calls fails with Host verification exceptions because i haven't been able connect place the public key for this user on the target server.
I don't know where the default "jenkins" user is configured and therefore cant generate the required public key to place on the target server.
Any suggestions for either;
A way to force Jenkins to use a user i define
A way to enable SSH for the default Jenkins user
Fetch the password for the default 'jenkins' user
Ideally I would like to be able do both both any help greatly appreciated.
Solution: I was able access the default Jenkins user with an SSH request from the target server. Once i was logged in as the jenkins user i was able generate the public/private RSA keys which then allowed for password free access between servers
Because when having numerous slave machine it could be hard to anticipate on which of them build will be executed, rather then explicitly calling ssh I highly suggest using existing Jenkins plug-ins for SSH executing a remote commands:
Publish Over SSH - execute SSH commands or transfer files over SCP/SFTP.
SSH - execute SSH commands.
The default 'jenkins' user is the system user running your jenkins instance (master or slave). Depending on your installation this user can have been generated either by the install scripts (deb/rpm/pkg etc), or manually by your administrator. It may or may not be called 'jenkins'.
To find out under what user your jenkins instance is running, open the http://$JENKINS_SERVER/systemInfo, available from your Manage Jenkins menu.
There you will find your user.home and user.name. E.g. in my case on a Mac OS X master:
user.home /Users/Shared/Jenkins/Home/
user.name jenkins
Once you have that information you will need to log onto that jenkins server as the user running jenkins and ssh into those remote servers to accept the ssh fingerprints.
An alternative (that I've never tried) would be to use a custom jenkins job to accept those fingerprints by for example running the following command in a SSH build task:
ssh -o "StrictHostKeyChecking no" your_remote_server
This last tip is of course completely unacceptable from a pure security point of view :)
So one might make a "job" which writes the host keys as a constant, like:
echo "....." > ~/.ssh/known_hosts
just fill the dots from ssh-keyscan -t rsa {ip}, after you verify it.
That's correct, pipeline jobs will normally use the user jenkins, which means that SSH access needs to be given for this account for it work in the pipeline jobs. People have all sorts of complex build environments so it seems like a fair requirement.
As stated in one of the answers, each individual configuration could be different, so check under "System Information" or similar, in "Manage Jenkins" on the web UI. There should be a user.home and a user.name for the home directory and the username respectively. On my CentOS installation these are "/var/lib/jenkins/" and "jenkins".
The first thing to do is to get a shell access as user jenkins in our case. Because this is an auto-generated service account, the shell is not enabled by default. Assuming you can log in as root or preferably some other user (in which case you'll need to prepend sudo) switch to jenkins as follows:
su -s /bin/bash jenkins
Now you can verify that it's really jenkins and that you entered the right home directory:
whoami
echo $HOME
If these don't match what you see in the configuration, do not proceed.
All is good so far, let's check what keys we already have:
ls -lah ~/.ssh
There may only be keys created with the hostname. See if you can use them:
ssh-copy-id user#host_ip_address
If there's an error, you may need to generate new keys:
ssh-keygen
Accept the default values, and no passphrase, if it prompts you to add the new keys to the home directory, without overwriting existing ones. Now you can run ssh-copy-id again.
It's a good idea to test it with something like
ssh user#host_ip_address ls
If it works, so should ssh, scp, rsync etc. in the Jenkins jobs. Otherwise, check the console output to see the error messages and try those exact commands on the shell as done above.
I am writing a PAM module for SSH to enforce one more layer of authentication. For that I need terminal ID in close_session() and pam_sm_setcred() function in PAM module while OpenSSH hardcoded it "ssh". I made few changes in OpenSSh code so it can set terminal ID properly. These changes were :
added do_pam_set_tty() in session_pty_req(Session *s) function in session.c
and added do_pam_set_tty() in mm_pty_allocate() function in monitor_wrap.c
It works fine for root and I get appropriate tty in pam_sm_cred() and pam_sm_close_session() function.
But using same code, when I try to ssh through a non root account I am getting tty in pam_sm_close_session() but not in pam_sm_cred(). I am not sure why ssh is behaving differently for root and non-root accounts.
Is there anything which triggers SSH behavior for root and non-root accounts or can anyone suggest me what can be wrong here. I have no idea how can I proceed and it would be great if someone can give me some pointers.
I got the solution. It was due to privilege separation. Post-auth privilege separation is disabled for root users and and enabled for other users by default. To get the tty thing working I had disabled privilege separation in /etc/ssh/sshd_config file.
For more details :
http://www.citi.umich.edu/u/provos/papers/privsep.pdf
I'd like to know how to get Subversion to change the name that my changes appear under.
I'm just starting to use Subversion. I'm currently using it to version control code on an XP laptop where I'm always logged in under my wife's name. I'd like the subversion DB to show the changes under my name.
Later on I'll replicate the DB so it is accessible to the whole house. My wife uses the office computer where she is always logged in under my name. I'll probably set it up so that it automatically checks in modified documents... preferably under her name.
Eventually I'll probably be using it from a linux machine under another username.
Is there some way to modify the user environment to change the user name that Subversion calls you? I'd expect something like setting SVN_USERNAME='Mark' which would override however it usually gets the name.
Update: It looks like the --username flag that Michael referred to does work to change the name reported by "svn stat", even for local file: repositories. In addition, it is sticky so you don't need to specify it for the next command. I even rebooted and it still used the "--username" value from my previous boot.
Most Subversion commands take the --username option to specify the username you want to use to the repository. Subversion remembers the last repository username and password used in each working copy, which means, among other things, that if you use svn checkout --username myuser you never need to specify the username again.
As Kamil Kisiel says, when Subversion is accessing the repository directly off the file system (that is, the repository URL is of form file:///path/to/repo or file://file-server/path/to/repo), it uses your file system permissions to access the repository. And when you connect via SSH tunneling (svn+ssh://server/path/to/repo), SVN uses your FS permissions on the server, as determined by your SSH login. In those cases, svn checkout --username may not work for your repository.
For svn over ssh try:
svn list svn+ssh://[user_name]#server_name/path_to_repo
svn will prompt you for the user_name's password.
You can setup a default username via ~/.subversion/servers:
[groups]
yourgroupname = svn.example.com
[yourgroupname]
username = yourusername
Please be aware that older versions of svn do not support it (e.g. 1.3.1 [sic!]).
"svn co --username=yourUserName --password=yourpassword http://path-to-your-svn"
Worked for me when on another user account. You will be prompted to enter username/password again though. You need to login like the above once and you are all set for the subsequent times(Unless you restart your machine).
If you need to specify a username other than your logged in user for use with svn+ssh just add an entry to your .ssh/config file:
Host example.com
User jdoe
Subversion usually asks me for my "Subversion username" if it fails using my logged in username. So, when I am lazy (usually) I'll just let it ask me for my password and I'll hit enter, and wait for the username prompt and use my Subversion username.
Otherwise, Michael's solution is a good way to specify the username right off.
Most of the answers seem to be for svn+ssh, or don't seem to work for us.
For http access, the easiest way to log out an SVN user from the command line is:
rm ~/.subversion/auth/svn.simple/*
Hat tip: http://www.yolinux.com/TUTORIALS/Subversion.html
Using Subversion with either the Apache module or svnserve. I've been able to perform operations as multiple users using --username.
Each time you invoke a Subversion command as a 'new' user, your $HOME/.subversion/auth/<authentication-method>/ directory will have a new entry cached for that user (assuming you are able to authenticate with the correct password or authentication method for the server you are contacting as that particular user).
I believe if you use the file:// method to access your subversion repository, your changes are always performed under the user which accesses the repository. You need to use a method that supports authentication such as http:// or svn://.
See http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.choosing
If you are using svn+ssh to connect to the repository then the only thing that authenticates you and authorizes you is your ssh credentials. EVERYTHING else is ignored. Your username will be logged in subversion exactly as it is established in your ssh connection. An excellent explanation of this is at jimmyg.org/blog/2007/subversion-over-svnssh-on-debian.html
Go to ~/.subversion/auth/svn.simple/*, and you will see a list of files that contains the information about your svn user account. Just delete all others that you don't need.
After that, when you do anything that regards to SVN operation, such as commit, rm, etc,. You will be prompt again to enter username or passwords.
TortoiseSVN always prompts for username. (unless you tell it not to)
I believe you can set the SVN_USER environment variable to change your SVN username.
I develop using MAMP pro on my Mac. When I start MAMP it prompts me for a password if I use port 80. If I use a higher port it doesn't prompt me, but I have to append the port number in the URL ( eg dev.local:8888 ).
Does anyone know how to make it not prompt for password when using standard ports?
Thank you.
I've put together an app that allows you to start/stop MAMP's Apache and MySQL without the password request, even on port 80. It stores the password in Keychain, so you only need to enter it once. It has a nice icon too!
Download: http://www.46palermo.com/blog/run-mamp-without-password-easy-way/
According to a living-e rep they are considering adding an option to store the password in the keychain:
http://forum.webedition.de/phpBB/viewtopic.php?f=4&t=5517&p=12019
Update: I pestered Living-e support and got them to add it as a feature request to their bug tracker. The link is here: http://qa.living-e.de/tracker/view.php?id=3648 (requires registration) if you want to follow it.
Another update: Still following this issue. Looks like living-e moved their bug tracker, the new link to this issue is:
http://bugs.mamp.info/view.php?id=3652
It's in German but the Google translation is:
When will start and stop the server in
each case the admin password is
required if port is used as low-1024th
If we could get the password from the
OS X Keychain / keyring, allowed
themselves to avoid annoying popup
ads.
Or a German speaker's translation is:
When the Server starts/stops it will ask for the admin password each time.
If it could get the password from OS X Keychain / Keyring, the annoying popup could be avoided.
As found on Macworld and already mentioned by Tom in the other answer there is a way with applescript! Downside is you have to save your user credentials in plain text.
Open AppleScript Editor
Enter the following code replacing YOURPASSWORD and YOURUSERNAME with your user credentials
Save it as application. You might tick run-only to prevent other users from reading the plain text as a small security measure
do shell script "/Applications/MAMP/bin/startApache.sh &" password "YOURPASSWORD" user name "YOURUSERNAME" with administrator privileges
do shell script "/Applications/MAMP/bin/startMysql.sh > /dev/null 2>&1"
There might be an issue with the correct file path as MAMP apparently changed startmySQL.sh to startMysql.sh in some version, so double check if it's not working!
You can put the new application in the Login Items (System Preferences -> Users & Groups -> Login Items), so the Apache server and MySQL start automatically without even showing up the MAMP-App at startup (silent start).
In response to the commands that were posted:
1) Run MAMP on port > 1024
Running all of the servers on MAMP (nginx, apache, mysql) with port ranges above 1024 allows the Mac OS X account you logged in with to launch the services, so you will not be asked for a password in this instance. Any server that runs below port 1024 requires root privileges when being executed.
2) chmod -R a+w /tmp
This command would recursively go through all files and sub folders in /tmp and make them writable for the current user. When MAMP launches, servers create temporary files in this directory.
Also if you decide you want to run the servers below port 1024 and want a solution with applescript that does not store the password in plain text then see this link applescript password with keychain
I'm now using these two applescripts to start/stop MAMP, you can save startup script is a login item so it's always up when I boot. It does mean storing your password in plain text, as Im the only one using this machine I can live with it, better than typing in my password at least three times a day.
I bind apache to port 8080 and then use port forwarding from 80 to 8080
sudo ipfw add 100 fwd 127.0.0.1,8080 tcp from any to any 80 in
Works for me, but I'm working on making the above script permanent. So far, nothing I've tried sticks, so I just run the command above in terminal after restarting. But you can then freely start and stop MAMP without a password and use a URL without :8080 or :8888.
Its a security issue, and MacOS with its UNIX heritage like security (=Good Thing). That's why MacOS asks for passwords all the time. Not much you can do about it as far as I know.
1) Run MAMP on port > 1024
2) chmod -R a+w /tmp