I am trying build new server Fedora 37 but when I trying to use PamMysql /because logins from postfix are stored in DB/ it is not working
very strange is, that only one ask to saslauthd will stop and broke saslauthd
I am using standard PamMysql and Saslauthd
smtp.postfix in pam.d
auth required pam_mysql.so user=postfix passwd=xxxx host=127.0.0.1 db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1
account sufficient pam_mysql.so user=postfix passwd=xxxx host=127.0.0.1 db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1
when I try only "testsaslauthd -u "yyy" -p "xxx" -s smtp"
It fails, stops Saslauthd and write me "size read failed"
Have anybody this error ?? on Fedora 37 ??
BTW: When I change SMTP.POSTFIX in PAM.D -> crypt=0 and write password to DB manually in cleartext - all works fine - but unusable, because of second one of mail - Dovecot is not able to authenticate cleartext passwords ;-)
I think, that problem will be in crypting of SASLAUTHD...because in Dovecot same logins are not problem...and on my older server is not problem too
BTW: I have built maybe 10 mailservers, same situation with no problems. but this is first on Fedora37
Related
Context
Running MariaDb 10.6.7 on Windows 11. Trying to use mariabackup to do a partial backup of my database. Database, target backup folder and backup process all on the same PC.
Issue
In a batch file I have this:
cd C:\"Program Files\MariaDB 10.6\bin"
mariabackup --backup --target-dir='D:\OneDrive\Backups\MariaDb' --databases-exclude="*test" --user=root --password=myPasswordWithNoQuotes
Which keeps giving me the response:
Failed to connect to MariaDB server: Access denied for user 'root'#'localhost' (using password: YES)
Things I've checked
Running the batch file as administrator
root has full priviliges
Password is correct - checked by logging into root with MySQL Workbench and MySQLClient and HeidiSQL.
Question
How do I set access rights so that the backup can proceed?
When I changed the root password to something simple everything worked. So it looks like the issue was a special character in the password (a % character perhaps) or the way that the password parameter was formed in the mariabackup command.
I have an ubuntu server running openldap to connect to our phones.
A while back I set this to use ldaps with letsencrypt which has worked fine with most things until recently they made a change ref the X3 cert. I am unable to install a late enough version so I can run the --preferred-chain "ISRG ROOT X1 and can't use the snap version as the box ix on lcx and wont run it.
The company has now bought a digi cert wild card certificate and would like this to be on the ldap server, but I can't get it to load the config
The original ldif file I created to import is below with the domain name changed.
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/letsencrypt/live/directory.mydomain.co.uk/fullchain.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/letsencrypt/live/test-directory.mydomain.co.uk/cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/letsencrypt/live/test-directory.mydomain.co.uk/privkey.pem
I have tried to change the file with modify commands and it's just wont have it and seem to keep getting the below.
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Inappropriate matching (18)
additional info: modify/add: olcTLSCACertificateFile: no equality matching rule
Any advise here would be great thanks.
I propose to check the contents of the ldif for special not intended characters. Like: $sudo cat -tve *.ldif?
I am new to salt-ssh and I have gotten it to work successfully for setting up a remote system. However, I have a login issue that I don't know how to address. What is happening is that when I try to run the salt-ssh commands I have to fight with then initial login process before eventually it just works. I am looking to see if I can narrow down what is causing me to have to fight with login process.
I am using OS X to run my salt-ssh commands against an ubuntu vagrant vm.
I have added my root user's ssh key to the root user authorized_keys on the vagrant vm. I have verified that I can log into the system using ssh without any issues
sudo ssh root#192.168.33.10
Here are what my config files look like:
roster
managed:
host: 192.168.33.10
user: root
sudo: true
Saltfile
salt-ssh:
config_dir: /users/vmcilwain/projects/salt-ssh-rails
roster_file: /users/vmcilwain/projects/salt-ssh-rails/roster
log_file: /users/vmcilwain/projects/salt-ssh-rails/saltlog.txt
master
file_roots:
base:
- /users/vmcilwain/projects/salt-ssh-rails/states
pillar_roots:
base:
- /users/vmcilwain/projects/salt-ssh-rails/pillars
I run this command:
sudo salt-ssh -i '*' test.ping
I enter my local user's password and I get this output
Permission denied for host 192.168.33.10, do you want to deploy the salt-ssh key? (password required):
[Y/n]
This is where my fight is. If the vagrant vm has the ssh key for the user I am executing salt-ssh as, why am I being told that permission is denied? Especially when I verified I could ssh into the system without using salt-ssh.
Clicking yes prompts me for the remote root user's password, which I didn't set and don't necessarily want to since an ssh key should have worked.
I'm hoping someone can tell me the best way to setup connections between both systems so that I don't have to have this fight every time.
I needed to set the priv in my roster to the rsa key that I am using to connect to the remote host:
priv: /Users/vmcilwain/.ssh/id_rsa
How to reset password in MariaDB? I use Windows and NOT Linux. Anyone who knows how to reset my MySQL MariaDB password? I tried to search on Google but did not help.
I bumped into the same problem. I lost the root password for a test server on a windows development machine.
Following the Linux step:
After
net stop mysql
Try invoking mysqld with
mysqld --skip-grant-tables
mysqld will only exit with a short message
[Note] mysqld.exe <...5.5.48.MariaDB> starting as process <pid> ...
then it quits. However I tried to launch mysqld directly, there is no mysqld.exe process. The service start command might have some argument combination that enabled mysqld to run. Tried to pass the settings through a configuration file and it works.
put
skip-grant-tables=TRUE
into MariaDB 5.5\data\my.ini
Restart mysqld, by
net stop mysql && net start mysql
then being able to login as root.
Don't forget to remove the inserted line and restart mysqld again.
As this is top result in Google here's a quick way to change the password:
Stop the DB server
create a text file containing your new password:
ALTER USER 'root'#'localhost' IDENTIFIED BY 'DontForgetMeAgain';
Run this command (don't forget to replace the path to file):
mysqld --init-file=C:\\path\\to\\file.txt
And we're done
Using skip-grant-tables led Maria Db to complain when changing a password even if logged in as root.
I had to do a little modification on Tom's answer in the content of the file to make it work for me:
After stopping the DBServer i created a file with this content:
SET PASSWORD FOR 'root'#'localhost' = PASSWORD('mynewpassword');
FLUSH PRIVILEGES;
then I run:
C:\Program Files\MariaDB 10.1\bin>mysqld --init-file=C:\\path\\to\\file.txt
I then managed to log in
How can we verify that SFTP access has been granted on a server, without installing any software/tools?
Most servers have curl and scp installed, which you can use to log into an SFTP server. To test if your credentials work using curl, you could do this:
$ curl -u username sftp://example.org/
Enter host password for user 'username':
Enter your password and if it works you'll get a listing of files (like ls -al), if it doesn't work you'll get an error like this:
curl: (67) Authentication failure
You could also try using scp:
$ scp username#example.org:testing .
Password:
scp: testing: No such file or directory
This verifies that you that you were able to log in, but it couldn't find the testing file. If you weren't able to log in you'd get a message like this:
Permission denied, please try again.
Received disconnect from example.org: 2: ...error message...
One of the many ways to check for SFTP access using password based authentication:
sftp username#serverName
or
sftp username#serverIP
And then entering password.
You will get "Permission denied, please try again." message if it fails otherwise you will be allowed inside the server with screen-
sftp>
You can test it fully works with commands like ls, mkdir etc.
Try logging in.
Not being snarky -- that really is probably the simplest way. By 'verify[ing] that SFTP access has been granted," what you're really doing is checking is a particular l/p pair is recognized by the server.
Alternatively, other than doing the "sftp -v" command mentioned above, you can always cat the SSH/SFTP logs stored on any server running sshd and direct them to a file for viewing.
A command set like the following would work, where 1.1.1 would be the /24 of the block you are trying to search.
cd /var/log/
cat secure.4 secure.3 secure.2 secure.1 secure |grep sshd| grep -v 1.1.1> /tmp/secure.sshd.txt
gzip -9 /tmp/secure.sshd.txt
G'day,
What about telnet on to port 115 (if we're talking Simple FTP) and see what happens when you connect. If you don't get refused try sending a USER command, then a PASS command, and then a QUIT command.
HTH
cheers,
In SFTP , the authentication can be of following types :
1. Password based authetication
2. Key based authentication
But if u r going for key based authentication then u have to prepare setup according to that and
proceed the login procedure.If the key based authentication fails it automatically asks for password means it automatically switches to password based mode. By the way if u want to verify u can use this on linux :
"ssh -v user#IP "
It will show u all the debug messages , and if the authentication is passed u will be logged in otherwise u will get "Permission denied". Hope this will help u.