I've problem here, I've been trying to load data in my postgreSQL Database, by using
psql -h suggestedorder.postgres.database.azure.com -d remote_mydb -U dev_ext#suggestedorder -c "\copy planning.PRUEBA (CENTRO, ALMACEN, FECHA_CARGA) from 'C:\Users\geradiaz.MODELO\Desktop\Envase\Selección_Envase\Inputs\No_Seleccionado\PRUEBA.csv' with delimiter as ','
Somehow after type this sentence CMD ask for a password:
But when I try to enter my password it just doesn't work, I can't type anything, so I push enter and it shows the next message "Unable to connect to server: FATAL: SSL connection is required. Please specify SSL options and retry."
Do you know guys if there is any way to make it? or How can I specify SSL options without disable them in azure?
But when I try to enter my password it just doesn't work, I can't type anything,
You don't get any feedback as you enter your password. You just have to take it on faith that your keyboard is working.
so I push enter and it shows the next message "Unable to connect to server: FATAL: SSL connection is required. Please specify SSL options and retry."
Actually the next message you got was "password authentication failed". I guess because you panicked when you noticed you weren't getting feedback, and so you never finished typing the password. (Also, "Unable to connect to server" doesn't appear in your screenshot at all, just the SSL part does)
Once psql's attempt to connect over SSL failed due to the password issue, it decided to try again without SSL. But the server rejected this attempt, leading to the 2nd error message (I don't know what caused the exact wording of that error message, it is not a wording I have seen before). If you set PGSSLMODE=require, then it won't bother to make this 2nd attempt, leading to cleaner error output.
Related
The bounty expires in 3 days. Answers to this question are eligible for a +50 reputation bounty.
Squazz wants to draw more attention to this question:
It either seems I haven't been able to explain myself well enough, or that the answer is not well known. Either way I hope for clarification on what could be going on here.
I have a .NET 6 service running in a container (based on the mcr.microsoft.com/dotnet/aspnet:6.0-focal image). When my service needs to talk to the SQL Server database, I must set SECLEVEL=1 in my OpenSSL config. I run the following when creating the container (taken from this github issue: https://github.com/dotnet/SqlClient/issues/776#issuecomment-825418533)
RUN sed -i '1i openssl_conf = default_conf' /etc/ssl/openssl.cnf && echo "\n[ default_conf ]\nssl_conf = ssl_sect\n[ssl_sect]\nsystem_default = system_default_sect\n[system_default_sect]\nMinProtocol = TLSv1.2\nCipherString = DEFAULT:#SECLEVEL=1" >> /etc/ssl/openssl.cnf
If I don't, I get this error:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31 - Encryption(ssl/tls) handshake failed)
But... my connection string has not set anything about encrypt or anything else that indicates that I must make an encrypted connection. And when I look at EF Core 6 or less, Encrypt=False is the default. So if you don't do anything explicit, I assume that the connection is not encrypted.
My connection string looks like this
Server=123,456;Database=123;User ID=123;PWD=123;multipleactiveresultsets=True;
On the .NET side I'm using Microsoft.EntityFrameworkCore.SqlServer 6.0.13, which has a dependency on Microsoft.Data.SqlCliet 2.1.4. Both of these has encrypt=false as default for the connection strings.
And that's where I'm unable to understand what happens.
If the connection is not encrypted, why do I have to set SECLEVEL=1 to avoid handshake errors? Why does a handshake even happen?
If the SQL Server you are connecting to is configured with force encryption, TLS/SSL will be used for all communication regardless of whether the client requests encryption or not.
Even if encryption is not required by client or server, login packets for the credential exchange are still encrypted. The setup needed to do so occurs as part of the pre-login handshake as described in this answer. This introduces the TLS/SSL requirement.
Context: I keep raising this error when I try to execute an SSRS Email or File Drop subscription - and I have no idea why. The empty string '' seems to imply I need to add some specific user information but I have no idea where.
I was able to send a test email through the Database Mail wizard in the management studio. I noticed in the SQL Server sysmail_event_log record for that event the last_mod_user was NTService\MSSQLSERVER. But the failed subscription execution attempts are showing up under the sa in the last_mod_user I suspect something is at play between this discrepancy but idk how to fix it.
The error description also reads:
The mail could not be sent to the recipients because of the mail
server failure. (Sending Mail using Account 4 (2022-04-22T17:41:01).
Exception Message: Cannot send mails to mail server. (The SMTP server
requires a secure connection or the client was not authenticated. The
server response was: 5.7.57 Client not authenticated to send mail.
[BN0P110CA0026.NAMP110.PROD.OUTLOOK.COM]). )
Questions: Can someone please assist?
Add the account to the Local Admin of the Machine to fix the Operation.Mail one
I'm still learning how to work with a databases using python libraries
An operational error has occurred while executing the following code
screenshot
Code snippet:
import pymysql
db1=pymysql.connect(host="127.0.0.1",user="root",password='root',port=3306,db='world')
a=db1.cursor()
sql='SELECT * from CITY'
print(a.execute(sql))
Error:
(1045, "Access denied for user 'root'#'localhost' (using password: NO)")
what could be the reason for this?
An operational error has occurred while executing the following code screenshot. what could be the reason for this?
Error in question is:
(1045, "Access denied for user 'root'#'localhost' (using password: NO)")
It reveals that you are attempting to connect without password while you actually supplied one in connection arguments. This was at one point known bug with pymysql so answer can be version dependent. If you can normally connect to mysql with mysql -u root -proot world (database, password and user from your connect arguments) that means that your database is indeed with proper credentials and expects password while connect method is not sending one, most probably due to old version. On the other hand if you can't connect then most probably your root password is blank and you need to set it properly. Also there is option that you have issues with access to database 'world' for root user.
I realised a few minutes ago , in my sql server log; there was an error:
SSPI handshake failed with error code 0x8009030c, state 14 while
establishing a connection with integrated security; the connection has
been closed. Reason: AcceptSecurityContext failed. The Windows error
code indicates the cause of failure. The logon attempt failed
[CLIENT: 222.186.61.15]
But i don't have an sqlclient ip 222.186.61.15
I research this ip and :
Continent: Asia
Country: China cn flag
State/Region: Jiangsu Sheng
City: Nanjing
Is my Sql Server under attack?:)
What is this?
Thanks for help.
Short answer; probably, but don't panic.
Someone tried to log onto your SQL server with invalid login credentials. If its coming from an IP that's totally out there, then it's probably not just someone mistyping their password. I wouldn't be overly worried about it, though. Its pretty common to see stuff like this every once in a while. Usually, its someone or some tool going through a list of SQL servers and trying common login credentials in hopes of getting lucky.
Just make sure you have solid login credentials, maybe update your firewall/IDS, and watch your logs to make sure that IP (or another weird one) logs in later.
I'm trying to open a password protected package in SQL Server BIDs and I keep getting the following error message each time I pu in the correct password:
Failed to remove package protection with error 0x80131940 "(null)"
This occurs in the CPaqckage::LoadFromXML method.
Any Ideas?
I ran into the same problem and discovered that caps-lock was on. Typing the correct password with caps-lock on gives the error message "Failed to remove package protection with error 0x80131940 "(null)", whereas typing the wrong password gives the "The password you have entered is incorrect" message. Very misleading but simple to fix.
I believe you thought you had the right password but that you really didn't.
I recently ran into this problem. I know you posted a long time ago but I could not find an answer when I ran into the same situation. Turns out I had the wrong password when I thought I had it right (I was not the one who created the package).
I had assumed that since some wrong passwords produced a wrong password error message that I must have had the right password with the one that did not produce a wrong password message - it turns out that different wrong passwords can return different error messages when opening a password encrypted SSIS package!
Very odd. At any rate, after finally getting a hold of the original developer, and getting the correct password, I was able to open the package just fine.
For what its worth I would never recommend encrypting the whole package with password, sensitive data maybe, but not the entire package.
I just received the same error. My issue was targeting SQL Server 2017 instead of SQL Server 2016 (Project > Propertied > Configuration Properties > General > Deployment Target Version > TargetServerVersion)
I got this message running a package built on vs 2017 enterprise on my laptop. In this situation people always fuss about your password. If you can get into the package with visual studio, you know your password. I was setting encryptAllWithPassword at the solution and package level. It was only failing with this message on my laptop as dtexec. When I moved the package to azure it ran with the /DECRYPT statement. So if you're only testing in one environment and it fails, try it in another environment (azure or server environment) and it might work.