MySQL उपयोगकर्ता पासवर्ड बदलें: ALTER USER कमांड (MySQL 5.7 / 8.0) + रूट पुनर्प्राप्ति

1. [Quick Answer] MySQL उपयोगकर्ता पासवर्ड परिवर्तन कमांड सूची (सबसे तेज़ समाधान)

MySQL में उपयोगकर्ता का पासवर्ड बदलने का मूल कमांड ALTER USER है।
यह विधि MySQL 5.7 और बाद के संस्करणों में अनुशंसित है, और इसे MySQL 8.0 में भी उसी तरह उपयोग किया जाता है।

1.1 मूल सिंटैक्स (सबसे अधिक उपयोग किया जाने वाला)

ALTER USER 'username'@'localhost' IDENTIFIED BY 'newpassword';

• username : अपडेट करने के लिए लक्ष्य उपयोगकर्ता नाम
• localhost : क्लाइंट होस्ट (एक MySQL खाता “उपयोगकर्ता नाम + होस्ट” द्वारा पहचाना जाता है)
• newpassword : नया पासवर्ड

कार्यान्वयन के बाद, परिवर्तन तुरंत प्रभावी हो जाता है। अधिकांश मामलों में, FLUSH PRIVILEGES; की आवश्यकता नहीं होती (ALTER USER स्वचालित रूप से विशेषाधिकार तालिकाओं को अपडेट करता है)।

सामान्य कठिनाइयाँ

• समान उपयोगकर्ता नाम होने पर भी, @'localhost' और @'%' को अलग-अलग खातों के रूप में माना जाता है
• पासवर्ड में प्रतीकों को एकल उद्धरण में बंद किया जाना चाहिए

1.2 रिमोट एक्सेस उपयोगकर्ता (%) को बदलना

ALTER USER 'username'@'%' IDENTIFIED BY 'newpassword';

% का अर्थ “कोई भी होस्ट” है।
यह क्लाउड वातावरण में या उन उपयोगकर्ताओं के लिए सामान्यतः उपयोग किया जाता है जिन्हें बाहर से कनेक्ट करने की अनुमति है।

नोट्स

• अग्रिम रूप से SELECT User, Host FROM mysql.user; चलाकर जांचना सुरक्षित रहता है
• यदि आप गलत होस्ट के लिए पासवर्ड बदलते हैं, तो आप लॉग इन नहीं कर पाएंगे

1.3 प्रमाणीकरण प्लगइन निर्दिष्ट करते हुए पासवर्ड बदलें (8.0 में महत्वपूर्ण)

MySQL 8.0 में, डिफ़ॉल्ट प्रमाणीकरण प्लगइन caching_sha2_password है।
यदि आप पुराने क्लाइंट्स से कनेक्ट नहीं कर पा रहे हैं, तो प्लगइन को स्पष्ट रूप से सेट करें।

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'newpassword';

• mysql_native_password : पुरानी विधि (संगतता को प्राथमिकता देती है)
• caching_sha2_password : MySQL 8.0 मानक (सिफ़ारिश किया गया)

सामान्य गलतियाँ

• पुराने PHP या क्लाइंट्स MySQL 8.0 के डिफ़ॉल्ट प्लगइन का समर्थन नहीं कर सकते
• प्रमाणीकरण प्लगइन की जाँच किए बिना “मैं लॉग इन नहीं कर पा रहा हूँ” का निर्णय लेना

1.4 यदि आपको विशेषाधिकार त्रुटि मिलती है

त्रुटि उदाहरण:

ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s)

इस मामले में, वर्तमान में लॉग इन किया हुआ उपयोगकर्ता परिवर्तन करने की अनुमति नहीं रखता।

जाँचें:

SHOW GRANTS FOR CURRENT_USER();

कमांड को रूट या पर्याप्त विशेषाधिकार वाले उपयोगकर्ता के रूप में चलाएँ।

1.5 बदलने के बाद कैसे सत्यापित करें

SELECT User, Host, plugin FROM mysql.user WHERE User='username';

• plugin कॉलम के माध्यम से प्रमाणीकरण प्लगइन की जाँच करें
• सबसे भरोसेमंद जाँच यह है कि वास्तव में लॉग इन करके कनेक्टिविटी की पुष्टि करें

1.6 मौजूदा सत्रों के साथ क्या होता है

पासवर्ड बदलने के बाद:

• नई कनेक्शन को नया पासवर्ड उपयोग करना होगा
• मौजूदा सत्र पर्यावरण के आधार पर तुरंत समाप्त हो सकते हैं
• उत्पादन में, बदलाव को व्यावसायिक घंटों के बाहर करने की सिफ़ारिश की जाती है

2. MySQL उपयोगकर्ता और होस्ट मूल बातें (सामान्य “अटके” मुद्दों को रोकें)

MySQL में, उपयोगकर्ता केवल “उपयोगकर्ता नाम” से पहचाना नहीं जाता। बल्कि, इसे “उपयोगकर्ता नाम + क्लाइंट होस्ट (Host)” के संयोजन से पहचाना जाता है।
यदि आप इसे नहीं समझते हैं, तो आप क्लासिक समस्या का सामना कर सकते हैं: “मैंने पासवर्ड बदल दिया लेकिन अभी भी लॉग इन नहीं कर पा रहा हूँ।”

2.1 एक उपयोगकर्ता “user@host” जोड़ी है

उदाहरण:

• 'appuser'@'localhost'
• 'appuser'@'%'
• 'appuser'@'192.168.1.%'

ये सभी अलग-अलग खातों के रूप में माने जाते हैं।
इसलिए यदि आप localhost के लिए पासवर्ड बदलते हैं, तो यह % खाते को प्रभावित नहीं करता।

जाँच कमांड:

SELECT User, Host FROM mysql.user ORDER BY User, Host;

सामान्य कठिनाइयाँ

• यह न समझ पाना कि समान उपयोगकर्ता नाम के साथ कई खाते मौजूद हैं
• आपने localhost के लिए पासवर्ड बदल दिया, लेकिन आप वास्तव में TCP (127.0.0.1) के माध्यम से लॉग इन कर रहे हैं

2.2 localhost और 127.0.0.1 को अलग तरह से माना जाता है

MySQL में:

• localhost → UNIX सॉकेट कनेक्शन (स्थानीय आंतरिक कनेक्शन)
• 127.0.0.1 → TCP/IP कनेक्शन

पर्यावरण के आधार पर, एक अलग खाता मेल खा सकता है।

जाँचें:

mysql -u username -p -h 127.0.0.1

यदि आप उपरोक्त के साथ लॉग इन नहीं कर पा रहे हैं, तो @'127.0.0.1' खाता मौजूद नहीं हो सकता है.

2.3 वर्तमान में प्रमाणित उपयोगकर्ता की जाँच करें

यह समझना महत्वपूर्ण है कि “आप किस खाते के रूप में प्रमाणित हैं”.

SELECT CURRENT_USER();

यह वास्तविक रूप से प्रमाणित “user@host” को प्रदर्शित करता है.

SELECT USER(); कनेक्शन अनुरोध की जानकारी दिखाता है, इसलिए यह मेल नहीं भी खा सकता.

2.4 विशेषाधिकार जाँचें (SHOW GRANTS)

यदि आप पासवर्ड नहीं बदल पा रहे हैं, तो अपर्याप्त विशेषाधिकार कारण हो सकते हैं.

SHOW GRANTS FOR 'username'@'host';

या वर्तमान में लॉग‑इन किए हुए उपयोगकर्ता के लिए:

SHOW GRANTS FOR CURRENT_USER();

न्यूनतम आवश्यक विशेषाधिकार

• ALTER USER
• या SYSTEM_USER (MySQL 8.0 और बाद में)

2.5 सामान्य विफलता पैटर्न

1. आपने गलत होस्ट के लिए पासवर्ड बदल दिया
2. प्रमाणीकरण प्लगइन अलग है (8.0 में बहुत सामान्य)
3. लक्ष्य खाता मूल रूप से ही मौजूद नहीं है

जाँचें कि उपयोगकर्ता मौजूद है या नहीं:

SELECT User, Host FROM mysql.user WHERE User='username';

एक बार जब आप इस मॉडल को समझ लेते हैं, तो आप अधिकांश पासवर्ड‑परिवर्तन संबंधित समस्याओं से बच सकते हैं.

3. अनुशंसित प्रक्रिया: ALTER USER के साथ सुरक्षित रूप से बदलें (MySQL 8.0 / 5.7 के लिए काम करता है)

MySQL 5.7 और बाद में, ALTER USER के साथ पासवर्ड बदलना मानक और अनुशंसित तरीका है।
UPDATE mysql.user जैसी प्रत्यक्ष अपडेट्स संस्करण के अनुसार अलग व्यवहार कर सकते हैं और भविष्य की संगतता जोखिम लाते हैं, इसलिए इन्हें टालना बेहतर है.

3.1 पूर्व‑जाँच (बदलने से पहले हमेशा पुष्टि करें)

पासवर्ड बदलने से पहले, इन तीन वस्तुओं की पुष्टि करें.

① लक्ष्य उपयोगकर्ता और होस्ट की पुष्टि करें

SELECT User, Host FROM mysql.user WHERE User='username';

• जाँचें कि समान उपयोगकर्ता नाम के साथ कई खाते मौजूद हैं या नहीं
• localhost को % के साथ भ्रमित न करें

② वर्तमान प्रमाणीकरण प्लगइन की पुष्टि करें (8.0 में महत्वपूर्ण)

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

• caching_sha2_password (MySQL 8.0 मानक)
• mysql_native_password (पुराना प्लगइन)

कुछ कनेक्शन विफलताएँ प्रमाणीकरण प्लगइन के कारण होती हैं.

③ वर्तमान में प्रमाणित उपयोगकर्ता की पुष्टि करें

SELECT CURRENT_USER();

विशेषाधिकार त्रुटियों से बचने के लिए, कमांड्स को root या उपयुक्त विशेषाधिकार वाले उपयोगकर्ता के रूप में चलाएँ.

3.2 ALTER USER चलाएँ (मानक रूप)

ALTER USER 'username'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

परिवर्तन तुरंत प्रभावी हो जाता है।
अधिकांश मामलों में, FLUSH PRIVILEGES; की आवश्यकता नहीं होती.

नोट्स

• यदि पासवर्ड नीति (validate_password) का उल्लंघन होता है, तो ERROR 1819 हो सकता है
• यदि पासवर्ड में विशेष अक्षर हैं, तो हमेशा इसे सिंगल कोट्स में रखें

3.3 प्रमाणीकरण प्लगइन निर्दिष्ट करते हुए बदलें (केवल आवश्यक होने पर)

यदि आप MySQL 8.0 वातावरण में पुराने क्लाइंट्स का उपयोग कर रहे हैं:

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

ऐसे मामलों में जहाँ आपको इसे बदलना चाहिए:

• पुराने PHP / पुराने MySQL क्लाइंट्स के साथ कनेक्ट नहीं हो पा रहा है
• ऐसा वातावरण जो caching_sha2_password का समर्थन नहीं करता

ऐसे मामलों में जहाँ आपको इसे नहीं बदलना चाहिए:

• यदि आप आधुनिक वातावरण में बिना समस्या के कनेक्ट कर सकते हैं (मानक प्लगइन अधिक सुरक्षित है)

3.4 परिवर्तन‑के‑बाद सत्यापन

① प्रमाणीकरण प्लगइन की जाँच करें

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

② वास्तव में लॉग‑इन करके सत्यापित करें

mysql -u username -p

हमेशा परीक्षण करें कि आप लॉग इन कर सकते हैं.

3.5 मौजूदा सत्रों पर प्रभाव

पासवर्ड बदलने के बाद:

• नई कनेक्शन → नए पासवर्ड का उपयोग करना आवश्यक है
• मौजूदा कनेक्शन → वातावरण के अनुसार जारी रह सकते हैं
• प्रोडक्शन → एप्लिकेशन कनेक्शन को पुनः शुरू करना पड़ सकता है

सामान्य गलतियाँ

• एप्लिकेशन के कनेक्शन क्रेडेंशियल्स को अपडेट न करना
• कॉन्फ़िगरेशन फ़ाइलों में पुराने पासवर्ड अभी भी रहना

3.6 प्रोडक्शन के लिए सुरक्षित संचालन टिप्स

• व्यापारिक घंटों के बाहर परिवर्तन करें
• एप्लिकेशन कॉन्फ़िगरेशन फ़ाइलों को पहले से जाँचें
• अपना SSH सत्र डिस्कनेक्ट किए बिना काम करें
• रूट बदलते समय सुनिश्चित करें कि आपके पास एक पुनर्प्राप्ति विधि तैयार है

4. MySQL 8.0 और 5.7 के बीच अंतर

MySQL पासवर्ड बदलते समय सबसे बड़ी समस्या MySQL 8.0 और 5.7 के बीच प्रमाणीकरण विधियों के अंतर है।
विशेष रूप से, कई “मैंने बदल दिया लेकिन लॉग इन नहीं हो पा रहा हूँ” मामलों का कारण प्रमाणीकरण प्लगइन में अंतर होता है।

MySQL 5.7 और MySQL 8.0 के बीच प्रमाणीकरण अंतर

4.1 डिफ़ॉल्ट प्रमाणीकरण प्लगइन अंतर

MySQL 8.0 में, caching_sha2_password को अधिक सुरक्षितता के लिए मानक बना दिया गया है।
हालाँकि, पुराने क्लाइंट (पुराने PHP संस्करण, पुराने MySQL कनेक्टर आदि) इसे समर्थन नहीं कर सकते।

जाँचने का तरीका:

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

सामान्य समस्याएँ

• पुराने क्लाइंट MySQL 8.0 पर बनाए गए उपयोगकर्ताओं से कनेक्ट नहीं हो पाते
• त्रुटि होने पर भी आप नहीं समझ पाते कि मूल कारण प्रमाणीकरण प्लगइन है

4.2 संगतता के लिए प्रमाणीकरण प्लगइन बदलने का तरीका

केवल तब जब आपको पुराने वातावरण से कनेक्ट करना हो, तब इसे इस प्रकार बदलें:

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

बदलाव करने के बाद हमेशा कनेक्शन टेस्ट चलाएँ।

नोट्स

• सुरक्षा के दृष्टिकोण से, caching_sha2_password अधिक सुरक्षित है
• अनावश्यक रूप से लेगेसी प्लगइन में न बदलें
• संभव हो तो क्लाइंट साइड को अपडेट करना बेहतर है

4.3 सीधे UPDATE का उपयोग अनुशंसित नहीं

MySQL 5.7 और उससे पहले, निम्नलिखित जैसी विधियों का उपयोग किया जाता था:

UPDATE mysql.user
SET authentication_string=PASSWORD('newpassword')
WHERE User='username';
FLUSH PRIVILEGES;

हालाँकि, यह तरीका:

• संस्करण-निर्भरता बहुत अधिक है
• 8.0 में स्पेसिफिकेशन परिवर्तन के अधीन है
• भविष्य में अप्रचलित हो सकता है

सामान्य नियम: ALTER USER का उपयोग करें

4.4 validate_password प्लगइन के व्यवहार में अंतर

MySQL 5.7 और 8.0 में, पासवर्ड नीति (स्ट्रेंथ चेक) सुविधाएँ डिफ़ॉल्ट रूप से उपलब्ध हैं।

जाँचें:

SHOW VARIABLES LIKE 'validate_password%';

यदि आप नीति का उल्लंघन करते हैं, तो आपको यह मिल सकता है:

ERROR 1819 (HY000)

।

क्योंकि कई 8.0 वातावरण अधिक कड़ी सुरक्षा बेसलाइन लागू करते हैं,
5.7 से अपग्रेड करने के बाद आप देख सकते हैं कि पासवर्ड परिवर्तन अधिक कठोर नीति आवश्यकताओं के कारण अब पास नहीं हो रहा है।

4.5 अपना संस्करण कैसे जाँचें

यदि आप सुनिश्चित नहीं हैं कि कौन सा संस्करण चल रहा है:

SELECT VERSION();

यदि आप संस्करण की पुष्टि किए बिना फिक्स लागू करते हैं, तो आप गलत विधि का उपयोग कर सकते हैं।

5. भूल गए root पासवर्ड की पुनर्प्राप्ति (सुरक्षा‑उन्मुख प्रक्रिया)

यदि आप MySQL root उपयोगकर्ता (प्रशासक) का पासवर्ड भूल जाते हैं, तो आप सामान्य रूप से लॉग इन नहीं कर सकते।
ऐसे में आपको अस्थायी रूप से ग्रांट टेबल्स को निष्क्रिय करके पासवर्ड रीसेट करना होगा। हालांकि, यह प्रक्रिया सुरक्षा जोखिम रखती है, इसलिए चरणों को सावधानीपूर्वक पालन करें।

5.1 पुष्टि करें कि क्या आपको वास्तव में root पासवर्ड चाहिए

पहले, निम्नलिखित जाँचें:

• क्या आपके पास OS‑स्तर पर sudo विशेषाधिकार हैं
• क्या auth_socket प्रमाणीकरण सक्षम है (Ubuntu‑आधारित सिस्टम में सामान्य)

उदाहरण जाँच:

SELECT User, Host, plugin
FROM mysql.user
WHERE User='root';

यदि plugin auth_socket है, तो आप OS root उपयोगकर्ता के रूप में लॉग इन कर सकते हैं।

sudo mysql

यदि यह काम करता है, तो आपको केवल पासवर्ड रीसेट करने की आवश्यकता है।

5.2 पुनर्प्राप्ति प्रवाह (सामान्य प्रक्रिया)

① MySQL सर्वर को रोकें

sudo systemctl stop mysql

② ग्रांट टेबल्स को निष्क्रिय करके शुरू करें

sudo mysqld_safe --skip-grant-tables &

--skip-grant-tables प्रमाणीकरण को निष्क्रिय करता है।
इस स्थिति में कोई भी कनेक्ट कर सकता है, इसलिए प्रक्रिया को शीघ्रता से पूरा करें।

③ MySQL से कनेक्ट करें

mysql -u root

आप बिना पासवर्ड के कनेक्ट कर सकते हैं।

④ root पासवर्ड रीसेट करें (सिफ़ारिश किया गया तरीका)

ALTER USER 'root'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

महत्वपूर्ण

• सीधे UPDATE mysql.user का उपयोग न करें
• संस्करण संगतता के लिए ALTER USER का उपयोग करें

⑤ grant tables को पुनः सक्षम करें

FLUSH PRIVILEGES;

⑥ सामान्य मोड में MySQL को पुनः प्रारंभ करें

sudo systemctl restart mysql

फिर सामान्य लॉगिन सत्यापित करें:

mysql -u root -p

5.3 सामान्य गलतियाँ

• --skip-grant-tables को सक्षम छोड़ना (गंभीर सुरक्षा जोखिम)
• अनजाने में root Host बदलना
• प्रमाणीकरण प्लगइन को गलत तरीके से बदलना और खुद को लॉक कर देना

5.4 उत्पादन वातावरण के लिए नोट्स

• सार्वजनिक सर्वरों पर हमेशा रखरखाव विंडो के दौरान यह करें
• काम करते समय अपना SSH सत्र सक्रिय रखें
• यदि संभव हो तो पहले से बैकअप बनाएं

Root पासवर्ड पुनर्प्राप्ति सुरक्षित रूप से की जा सकती है यदि सावधानीपूर्वक किया जाए।

6. सामान्य त्रुटियाँ और समाधान (त्रुटि संदेश द्वारा ट्रैफ़िक कैप्चर)

MySQL पासवर्ड बदलते समय कई सामान्य त्रुटियाँ होती हैं। नीचे, हम अक्सर खोजे जाने वाले त्रुटि कोड के आधार पर सामान्य कारणों और समाधानों को व्यवस्थित करते हैं।

6.1 ERROR 1819 (पासवर्ड नीति आवश्यकताओं को पूरा नहीं करता)

त्रुटि उदाहरण:

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

कारण

पासवर्ड validate_password प्लगइन द्वारा लागू शक्ति सत्यापन में विफल रहा।

वर्तमान नीति जांचें

SHOW VARIABLES LIKE 'validate_password%';

महत्वपूर्ण सेटिंग्स:

• validate_password.length
• validate_password.policy
• validate_password.mixed_case_count
• validate_password.number_count
• validate_password.special_char_count

समाधान ① (सिफारिश): अधिक मजबूत पासवर्ड उपयोग करें

• कम से कम 12 अक्षर
• बड़े अक्षर, छोटे अक्षर, संख्याएँ और प्रतीक शामिल करें
• शब्दकोश शब्दों से बचें

समाधान ② (अस्थायी रूप से नीति को ढीला करें)

SET GLOBAL validate_password.policy = LOW;

अपना कार्य पूरा करने के बाद, मूल सेटिंग को पुनर्स्थापित करने की सिफारिश की जाती है।

सामान्य गलतियाँ

• उत्पादन में नीति को ढीला छोड़ देना
• यह न देखना कि इस सेटिंग को बदलने के लिए SUPER विशेषाधिकार आवश्यक हैं

6.2 ERROR 1227 (अपर्याप्त विशेषाधिकार)

त्रुटि उदाहरण:

ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s)

कारण

वर्तमान उपयोगकर्ता के पास ALTER USER या SYSTEM_USER विशेषाधिकार नहीं है।

विशेषाधिकार जांचें

SHOW GRANTS FOR CURRENT_USER();

समाधान

कमांड को रूट या पर्याप्त विशेषाधिकार वाले उपयोगकर्ता के रूप में चलाएँ।

यदि आवश्यक हो:

GRANT ALTER USER ON *.* TO 'username'@'host';
FLUSH PRIVILEGES;

नोट

• MySQL 8.0 में, SYSTEM_USER विशेषाधिकार भी आवश्यक हो सकता है
• उत्पादन में न्यूनतम विशेषाधिकार सिद्धांत का पालन करें

6.3 पासवर्ड बदलने के बाद लॉगिन नहीं हो पा रहा है

मुख्य कारण

1. गलत Host
2. प्रमाणीकरण प्लगइन असंगतता
3. क्लाइंट असंगतता
4. एप्लिकेशन कॉन्फ़िगरेशन अपडेट नहीं किया गया

① Host जांचें

SELECT User, Host FROM mysql.user WHERE User='username';

② प्रमाणीकरण प्लगइन जांचें

SELECT plugin FROM mysql.user WHERE User='username';

③ प्रमाणीकरण प्लगइन बदलें (यदि आवश्यक हो)

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

④ एप्लिकेशन कॉन्फ़िगरेशन जांचें

• .env
• config.php
• कनेक्शन स्ट्रिंग (DSN)

सामान्य गलतियाँ

• MySQL बदलना लेकिन एप्लिकेशन को अपडेट न करना
• Docker वातावरण में कंटेनर को पुनः प्रारंभ न करना

6.4 बदलाव के बाद भी पुराने पासवर्ड से लॉगिन संभव है

सामान्यतः, ALTER USER से किए गए परिवर्तन तुरंत प्रभावी होते हैं।

संभावित कारण:

• आपने वास्तव में किसी अलग Host खाते को बदला है
• कनेक्शन किसी अन्य सर्वर (प्रतिलिपि) की ओर इशारा कर रहा है
• सेशन कैशिंग

जाँचें:

SELECT CURRENT_USER();

सटीक रूप से जुड़े सर्वर और प्रमाणित उपयोगकर्ता दोनों की पुष्टि करना अत्यंत महत्वपूर्ण है।

7. सुरक्षा संचालन: पासवर्ड नीतियां और सर्वोत्तम प्रथाएं

पासवर्ड बदलना एक बार का कार्य नहीं है।
वास्तविक दुनिया के संचालन में, आप शक्ति प्रवर्तन, विशेषाधिकार डिजाइन, और संचालन नियम को मिलाकर सुरक्षा बनाए रखते हैं।

7.1 validate_password प्लगइन का उपयोग

MySQL पासवर्ड की शक्ति लागू करने के लिए अंतर्निहित कार्यक्षमता प्रदान करता है।

वर्तमान सेटिंग्स जांचें

SHOW VARIABLES LIKE 'validate_password%';

मुख्य कॉन्फ़िगरेशन पैरामीटर

• validate_password.length (न्यूनतम लंबाई)
• validate_password.policy (LOW / MEDIUM / STRONG)
• validate_password.mixed_case_count
• validate_password.number_count
• validate_password.special_char_count

उदाहरण कॉन्फ़िगरेशन (न्यूनतम 12 अक्षर, MEDIUM नीति)

SET GLOBAL validate_password.length = 12;
SET GLOBAL validate_password.policy = MEDIUM;

नोट

• GLOBAL परिवर्तन पुनः आरंभ के बाद रीसेट हो सकते हैं
• सेटिंग्स को स्थायी बनाने के लिए, उन्हें कॉन्फ़िगरेशन फ़ाइल (my.cnf / my.ini) में कॉन्फ़िगर करें

7.2 मजबूत पासवर्ड के न्यूनतम आवश्यकताएँ

व्यावहारिक रूप से अनुशंसित मानक:

• कम से कम 12 अक्षर
• बड़े अक्षर, छोटे अक्षर, संख्याएँ और प्रतीक शामिल करें
• शब्दकोश शब्दों से बचें
• अन्य सेवाओं में पुन: उपयोग न करें

उदाहरण:

X9v!pQ4z#Lm2

बचने के उदाहरण

password123
mysql2025
companyname!

7.3 आवधिक परिवर्तनों से अधिक महत्वपूर्ण

“हर छह महीने में बदलने” से अधिक महत्वपूर्ण है संभावित प्रमाणपत्र लीक की धारणा के तहत डिजाइन करना।

① अलग-अलग एप्लिकेशन उपयोगकर्ता

• एप्लिकेशनों में root का उपयोग न करें
• न्यूनतम विशेषाधिकार वाले उपयोगकर्ता बनाएं

उदाहरण:

GRANT SELECT, INSERT, UPDATE ON dbname.* TO 'appuser'@'localhost';

② विशेषाधिकार कम करें (न्यूनतम विशेषाधिकार सिद्धांत)

संभावित नुकसान को सीमित करने के लिए केवल आवश्यक संचालन की अनुमति दें।

③ ऑडिटिंग और लॉग्स का उपयोग करें

उदाहरण लॉग जांच:

tail -f /var/log/mysql/mysql.log

MySQL Enterprise भी ऑडिट प्लगइन्स का समर्थन करता है।

7.4 उत्पादन वातावरण के लिए संचालन टिप्स

• उत्पादन परिवर्तन करने से पहले स्टेजिंग में परीक्षण करें
• परिवर्तन इतिहास को ट्रैक करें (Git या दस्तावेज़ीकरण)
• परिवर्तनों के बाद हमेशा कनेक्शन परीक्षण चलाएँ
• काम करते समय अपना SSH सत्र सक्रिय रखें

7.5 ऐसी चीजें जो आपको कभी नहीं करनी चाहिए

• एप्लिकेशनों में root खाता उपयोग करें
• स्रोत कोड में पासवर्ड हार्ड-कोड न करें
• validate_password को अक्षम करें और उसी तरह छोड़ दें
• --skip-grant-tables के साथ सर्वर को चलने दें

पासवर्ड प्रबंधन एक बार का कार्य नहीं है बल्कि निरंतर संचालन डिजाइन का हिस्सा है।

8. अक्सर पूछे जाने वाले प्रश्न (FAQ)

8.1 प्रश्न: पासवर्ड बदलने के बाद सक्रिय सत्रों के साथ क्या होता है?

उ: सिद्धांत रूप में, नई कनेक्शन को नया पासवर्ड चाहिए।
मौजूदा सत्रों के लिए, वे या तो तुरंत समाप्त हो सकते हैं या पर्यावरण और कॉन्फ़िगरेशन के आधार पर सक्रिय रह सकते हैं।

व्यावहारिक रूप में:

• उत्पादन में व्यापारिक घंटों के बाहर परिवर्तन करें
• कनेक्शन रीफ़्रेश करने के लिए एप्लिकेशन को पुनः आरंभ करें

की सिफारिश की जाती है।

8.2 प्रश्न: मैंने पासवर्ड बदल दिया लेकिन अभी भी लॉग इन नहीं कर पा रहा हूँ

तीन सबसे सामान्य कारण हैं:

1. गलत होस्ट (localhost बनाम %, आदि)
2. प्रमाणीकरण प्लगइन असंगति (8.0 में बहुत सामान्य)
3. एप्लिकेशन कॉन्फ़िगरेशन अपडेट नहीं हुआ

जाँचें:

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

plugin कॉलम पर विशेष ध्यान दें।

8.3 प्रश्न: क्या मैं केवल एक विशिष्ट उपयोगकर्ता को पासवर्ड बदलने की अनुमति दे सकता हूँ?

हाँ।

GRANT ALTER USER ON *.* TO 'username'@'host';
FLUSH PRIVILEGES;

MySQL 8.0 में, SYSTEM_USER विशेषाधिकार भी आवश्यक हो सकता है।

SHOW GRANTS FOR 'username'@'host';

विशेषाधिकार सत्यापित करने के लिए इसका उपयोग करें।

8.4 प्रश्न: क्या MariaDB में विधि समान है?

बुनियादी रूप से, ALTER USER उपलब्ध है, लेकिन:

• प्रमाणीकरण प्लगइन्स
• पासवर्ड नीति व्यवहार
• संस्करण-विशिष्ट अंतर

पर्यावरण के आधार पर भिन्न हो सकते हैं।

जाँचें:

SELECT VERSION();

MySQL Community Edition डिफ़ॉल्ट रूप से निर्मित पासवर्ड इतिहास ट्रैकिंग प्रदान नहीं करता है।

8.5 Q. क्या मैं पासवर्ड परिवर्तन इतिहास देख सकता हूँ?

संभव उपाय:

• ऑडिट लॉगिंग सक्षम करें
• बाहरी लॉग प्रबंधन का उपयोग करें
• संचालन दस्तावेज़ीकरण में इतिहास ट्रैक करें

उदाहरण:

tail -f /var/log/mysql/mysql.log

8.6 Q. क्या मैं –skip-grant-tables के साथ गैर-रूट उपयोगकर्ताओं को पुनः प्राप्त कर सकता हूँ?

हाँ, लेकिन यह एक बहुत खतरनाक स्थिति बनाता है।
प्रक्रिया पूरी होने के बाद तुरंत सामान्य मोड में लौटें।

9. सारांश

MySQL पासवर्ड बदलना सरल लग सकता है, लेकिन user@host मॉडल, प्रमाणीकरण प्लगइन्स, और विशेषाधिकार डिज़ाइन को समझे बिना यह आसानी से समस्याओं का कारण बन सकता है।

इस लेख के मुख्य बिंदु हैं:

9.1 मानक विधि के रूप में ALTER USER का उपयोग करें

ALTER USER 'username'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

• MySQL 5.7 और बाद के संस्करणों में मानक विधि
• सीधे UPDATE mysql.user की अनुशंसा नहीं की जाती
• FLUSH PRIVILEGES आमतौर पर आवश्यक नहीं है

9.2 उपयोगकर्ताओं को “user@host” के रूप में प्रबंधित किया जाता है

• localhost और % अलग-अलग खाते हैं
• समान उपयोगकर्ता नाम वाले कई खाते मौजूद हो सकते हैं
• SELECT User, Host FROM mysql.user; के साथ जाँच करें

9.3 8.0 में प्रमाणीकरण प्लगइन्स पर ध्यान दें

• 8.0 डिफ़ॉल्ट: caching_sha2_password
• लेगेसी संगतता: mysql_native_password
• यदि आप कनेक्ट नहीं कर पा रहे हैं, तो plugin कॉलम देखें

  SELECT plugin FROM mysql.user WHERE User='username';
  

9.4 रूट पासवर्ड पुनर्प्राप्त करते समय सावधान रहें

• --skip-grant-tables केवल एक अस्थायी उपाय है
• समाप्ति के बाद हमेशा सामान्य मोड में लौटें
• उत्पादन में रखरखाव विंडो के दौरान करें

9.5 अधिकांश त्रुटियों के स्पष्ट कारण होते हैं

• ERROR 1819 → पासवर्ड नीति उल्लंघन
• ERROR 1227 → अपर्याप्त विशेषाधिकार
• लॉग इन नहीं हो पा रहा है → होस्ट मिलान नहीं या प्रमाणीकरण प्लगइन मिलान नहीं

9.6 व्यवहार में, न्यूनतम विशेषाधिकार और संचालन डिज़ाइन सबसे अधिक महत्वपूर्ण हैं

• अनुप्रयोगों में रूट का उपयोग न करें
• समर्पित उपयोगकर्ता बनाएं
• मजबूत पासवर्ड नीतियों को लागू करें
• परिवर्तन के बाद हमेशा कनेक्शन का परीक्षण करें

MySQL पासवर्ड प्रबंधन केवल मान बदलने के बारे में नहीं है—यह सुरक्षित डेटाबेस संचालन की नींव है। अपने वातावरण के लिए उपयुक्त विधि चुनें और इसे सावधानीपूर्वक लागू करें।