تحرير: إذا كنت تواجه هذه المشكلة ، فنحن نقدر مساعدتك في استكشاف الأخطاء وإصلاحها. أقوم بتحديث هذا التعليق للحصول على رؤية أفضل لخطوات استكشاف الأخطاء وإصلاحها.

استكشاف الأخطاء وإصلاحها

تتمثل الخطوة الأولى لاستكشاف الأخطاء وإصلاحها في تحديد ما إذا كانت المشكلة تتعلق ببيانات الاعتماد نفسها أم مع CLI. لاختبار ذلك ، حاول استخدام بيانات الاعتماد هذه في مجموعات AWS SDK أخرى (جافا سكريبت ، روبي ، جافا ، إلخ). للمساعدة في ذلك ، قمت بإنشاء برنامج نصي للاختبار يستخدم AWS SDK للغة python و javascript والمتوفر هنا: https://github.com/jamesls/aws-creds-test . بعد الاستنساخ ، ما عليك سوى تشغيل make install ، make test . سيطالبك ببيانات الاعتماد (على غرار CLI) وإجراء استدعاء API إلى sts.GetCallerIdentity .

/tmp $ mkdir /tmp/repro-cli-602
/tmp $ cd /tmp/repro-cli-602/
/tmp/repro-cli-602 $ git clone git://github.com/jamesls/aws-creds-test
Cloning into 'aws-creds-test'...
...
/tmp/repro-cli-602 $ cd aws-creds-test/
/tmp/repro-cli-602/aws-creds-test (master u=) $ make install
npm install
[email protected] /private/tmp/repro-cli-602/aws-creds-test
├─┬ [email protected]
...
pip install -r requirements.txt
Requirement already satisfied: botocore<2.0.0,>=1.5.0 in /usr/local/lib/python2.7/site-packages (from -r requirements.txt (line 1))
...



/tmp/repro-cli-602/aws-creds-test (master u=) $ make test
./test-creds.sh
Testing python...
Access Key:
Secret Access Key:
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20

SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Successfuly made an AWS request with the provided credentials.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20


SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Sucessfully made an AWS request with the provided credentials.

بالنسبة للأشخاص الذين يواجهون هذه المشكلة ، يرجى تشغيل البرنامج النصي للاختبار ومشاركة الإخراج.

يجب أن يمنحنا هذا نظرة ثاقبة حول مكان حدوث هذه المشكلة:

• إذا مر النص أعلاه لكل من python و javascript ولكنه فشل عند استخدام CLI ، فمن المحتمل أن يكون مشكلة CLI.
• إذا فشل البرنامج النصي في لغة python ولكنه مر إلى جافا سكريبت ، فمن المحتمل وجود مشكلة في botocore (التي يستخدمها CLI).
• إذا فشل البرنامج النصي أعلاه في كل من python و javascript ، فمن المحتمل وجود مشكلة في بيانات الاعتماد الفعلية.

شكرًا مقدمًا لأي شخص يمكنه مساعدتنا في تحري الخلل وإصلاحه. اسمحوا لي أن أعرف إذا كان هناك أي أسئلة.

هذه عن كيفية الشبه:

thomas<strong i="6">@iMac</strong>:~ $ echo $AWS_ACCESS_KEY_ID
AKIAXXXXXXXXXXXXXXXX
thomas<strong i="7">@iMac</strong>:~ $ echo $AWS_SECRET_ACCESS_KEY
abcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa+0
thomas<strong i="8">@iMac</strong>:~ $ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
              env    AWS_ACCESS_KEY_ID
              env    AWS_SECRET_ACCESS_KEY
    region                eu-west-1              env    AWS_DEFAULT_REGION

أي تحديثات بشأن هذه المسألة؟ أواجه هذا الخطأ أيضًا ولم يتغير ملف بيانات الاعتماد الخاص بي.

عندى نفس المشكلة. المكون الإضافي Jenkins s3 قادر على وضع كائن باستخدام بيانات الاعتماد الخاصة بي ، لكن aws-cli يعطيني الأخطاء أدناه.

aws s3 cp s3://my-bucket/folder/test.txt test.txt
A client error (Forbidden) occurred when calling the HeadObject operation: Forbidden Completed 1 part(s) with ... file(s) remaining

aws s3api get-object --bucket my-bucket --key folder/test.txt test.txt
A client error (SignatureDoesNotMatch) occurred when calling the GetObject operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

أنا على التوالي في نفس القضية. إذا اختلقت سرًا ، فسأعطيني خطأ مختلف (AuthFailure).

[[email protected]]]$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************AMKA              env    AWS_ACCESS_KEY_ID
secret_key     ****************jPU2              env    AWS_SECRET_ACCESS_KEY
    region                us-west-2              env    AWS_DEFAULT_REGION

هذا إلى حد كبير يوقفني تماما. يمكنني القيام ببعض الأشياء باستخدام الأدوات المساعدة لـ ec2-blah-stuff عن طريق تحديد شهادات x509 لكن المساعدة تقول إن هذا مهمل لذا لا أريد الاعتماد عليها. أي مساعدة في استكشاف الأخطاء وإصلاحها أو أي شيء سيكون حقًا موضع تقدير.

ستكون الخطوة الأولى هي التأكد من أن مفاتيح الوصول / المفاتيح السرية صالحة بالفعل. بعض الأشياء التي يمكنك تجربتها:

• هل تعمل بيانات اعتماد الوصول / المفتاح السري هذه مع أدوات أخرى؟ (جافا / جافا سكريبت / روبي / بيثون SDK؟)
• هل تعمل الأوامر الأخرى إلى جانب "aws s3" من أجلك؟ هل ما زالت عبارة "aws ec2 تصف الحالات" تولد أخطاء المصادقة؟

أنها لا تعمل مع أدوات أخرى (على سبيل المثال ، وصف ec2).

أعتقد أنني أمتلك الحقوق المناسبة منذ استخدام أعمال الشهادات. للتأكد من أنها ليست محطة عمل ، قمت بإنشاء مثيل Amazon Linux وأنا أستخدم إصدار awscli الذي يأتي معه ولكني أتلقى نفس الرسالة.

أيضا مشكلة بالنسبة لي. أنا أستخدمه في حاوية عامل إرساء ، تم إنشاؤها باستخدام نفس ملف Docker.
إنه يعمل بشكل جيد عند بنائه على EC2 ، لكنه لا يعمل عند بنائه محليًا على صندوق متشرد coreos.

يبدو أن المشكلة تتعلق بأوراق الاعتماد نفسها. لقد راجعت هذا الأمر مرتين ، ولا يمكنني إعادة معالجة هذه المشكلة. تحقق مرة أخرى من بيانات الاعتماد على صفحة بيانات اعتماد الأمان . إذا كان بإمكان شخص ما تقديم مجموعة دقيقة من الخطوات التي توضح المشكلة ، فسيسعدني إلقاء نظرة أخرى.

حدث هذا لي للتو وكان نتيجة لانقطاع الوقت في نظامي كثيرًا على الرغم من أنه لم يبلغ عن ذلك. تشغيل ntpdate ضد pool.ntp.org وإصلاح هذه المشكلة بالنسبة لي.

إذا كنت تتلقى هذا الخطأ عند إعداد الاعتماد باستخدام متغير env ، فجرب sudo

إذا كنت تستخدم جهازًا افتراضيًا ، فتأكد من أن وقت نظام التشغيل المضيف يطابق وقت نظام تشغيل الضيف. إذا لم يكن الأمر كذلك ، فسوف تدخل في الخطأ الذي وصفته.

يحدث خطأ مشابه جدًا بالنسبة لي مع بيانات اعتماد جيدة ، أثناء إدراج دلو يحتوي على الكثير من المفاتيح. ها هو الخطأ:

A client error (SignatureDoesNotMatch) occurred when calling the ListObjects operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

هذا هو إنتاجي من aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************4UNA shared-credentials-file
secret_key     ****************MNOG shared-credentials-file
    region                <not set>             None    None

لاحظ أن بيانات الاعتماد هذه تعمل بشكل جيد مع استدعاءات أخرى aws ، وفي الواقع يتم تشغيل هذا list op لفترة طويلة (أكثر من ساعة) قبل الكفالة بهذا الخطأ. لدي ملف به أكثر من 82000 سطر من الإخراج من الأمر الذي فشل في النهاية.

لقد تلقيت هذه المشكلة ، وإذا أنام النص الخاص بي لثانية وحاول مرة أخرى ، فسيتم ذلك. يكاد يكون الأمر وكأنه يتم خنقه ويعيد الخطأ الخطأ أو شيء من هذا القبيل.

يمكنني الإبلاغ عن هذه المشكلة أيضا. أثناء محاولة تحميل ملف بحجم 11 جيجابايت باستخدام aws cp foo s3: // mybucket / foo / bar ، أحصل على العديد من الأخطاء مثل:

A client error (SignatureDoesNotMatch) occurred when calling the UploadPart operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

و

Max retries exceeded with url: /***REDACTED***?partNumber=196&uploadId=B2viwGFF4Lmq5itbs8ipqwBExx0BWGRm3gkG_D5EYTiU8uEO_tmUT.d.i7BcgPnP5npZa.OW7yMfJ3ZhhLJD61zP7EVv.5.ZftCJQbKNdkEBeijGBqWlrxz4vMx3B05Q (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known)

لقد تحققت من صحة وقت نظامي. لقد لاحظت أيضًا بطءًا كبيرًا (على مستوى مهلة طلبات http) على نفس النظام أثناء التحميل ، لذا فإن هذه مشكلة الاختناق تبدو معقولة. كما أنه يعمل بشكل جيد لتحميل الملفات الصغيرة بنفس بيانات الاعتماد ، واستخدام وحدة تحكم الويب من نفس الجهاز ، لذلك يبدو أن هذا يمثل مشكلة aws-cli.

حدث هذا لي أيضًا مع aws-cli 1.5.5 ، أدى تحديث aws-cli إلى 1.6.2 إلى حلها.

يحدث لي مع 1.6.2

حدث هذا لي اليوم. هذا جديد بالنسبة لي. تم استخدام awl-cli لبضعة أشهر ولا توجد مشكلة ولا تغيير في أوراق اعتماد AFAIK.

$ aws configure --profile ye list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                       ye           manual    --profile
access_key     ****************ERMQ shared-credentials-file    
secret_key     ****************E8Id shared-credentials-file    
    region                us-east-1      config-file    ~/.aws/config

أعتقد أنه تم حل هذه المشكلة الآن عبر https://github.com/boto/botocore/pull/388 ، وستكون متاحة في إصدار AWS CLI التالي.

jamesls أكد أنه ثابت على إصدار awscli 1.6.4 . كنت أستخدم 1.5.4 . شكرا!

أحصل على هذه المشكلة على نظام أوبونتو جديد.

A client error (SignatureDoesNotMatch) occurred when calling the PutObject operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

تثبيت aws-cli عبر نقطة

$ pip list
ansible (1.5.4)
apt-xapian-index (0.45)
argparse (1.2.1)
awscli (1.6.5)
bcdoc (0.12.2)
botocore (0.76.0)
chardet (2.0.1)
Cheetah (2.4.4)
cloud-init (0.7.5)
colorama (0.2.5)
configobj (4.7.2)
docutils (0.11)
html5lib (0.999)
httplib2 (0.8)
Jinja2 (2.7.2)
jmespath (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Landscape-Client (14.01)
MarkupSafe (0.18)
mercurial (2.8.2)
oauth (1.0.1)
PAM (0.4.2)
Pillow (2.3.0)
pip (1.5.4)
prettytable (0.7.2)
pyasn1 (0.1.7)
pycrypto (2.6.1)
pycurl (7.19.3)
Pygments (1.6)
pyinotify (0.9.4)
pyOpenSSL (0.13)
pyserial (2.6)
python-apt (0.9.3.5)
python-dateutil (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
requests (2.2.1)
roman (2.0.0)
rsa (3.1.2)
setuptools (3.3)
six (1.5.2)
Sphinx (1.2.2)
ssh-import-id (3.21)
Twisted-Core (13.2.0)
urllib3 (1.7.1)
wsgiref (0.1.2)
zope.interface (4.0.5)

أي أفكار حول كيفية إصلاح ذلك؟

كان الحل هو النوم لبضع ثوان ثم المحاولة مرة أخرى ، لكن ذلك
يبدو أنه قد يكون هناك تحديث للأداة التي تعمل على إصلاحه أيضًا.

في الثلاثاء ، 2 ديسمبر 2014 ، الساعة 3:38 صباحًا ، كتب مارك وولف [email protected] :

أحصل على هذه المشكلة على نظام أوبونتو جديد.

حدث خطأ العميل (SignatureDoesNotMatch) عند استدعاء عملية PutObject: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاحك وطريقة التوقيع.

تثبيت aws-cli عبر نقطة

قائمة النقاط بالدولار
أنسبل (1.5.4)
مؤشر apt-xapian (0.45)
argparse (1.2.1)
أوسكلي (1.6.5)
بكدوك (0.12.2)
botocore (0.76.0)
شارديت (2.0.1)
الفهد (2.4.4)
سحابة init (0.7.5)
كولوراما (0.2.5)
configobj (4.7.2)
دوكوتيلس (0.11)
html5lib (0.999)
HTplib2 (0.8)
Jinja2 (2.7.2)
جميسباث (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
عميل المناظر الطبيعية (14.01)
MarkupSafe (0.18)
زئبقي (2.8.2)
oauth (1.0.1)
بام (0.4.2)
وسادة (2.3.0)
نقطة (1.5.4)
جميل (0.7.2)
pyasn1 (0.1.7)
pycrypto (2.6.1)
بيكورل (7.19.3)
بيجمنتس (1.6)
بيينوتيفي (0.9.4)
pyOpenSSL (0.13)
جرسي (2.6)
python-apt (0.9.3.5)
بيثون داتوتيل (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
الطلبات (2.2.1)
روماني (2.0.0)
rsa (3.1.2)
setuptools (3.3)
ستة (1.5.2)
أبو الهول (1.2.2)
ssh-import-id (3.21)
الملتوية النواة (13.2.0)
urllib3 (1.7.1)
wsgiref (0.1.2)
zope.interface (4.0.5)

أي أفكار حول كيفية إصلاح ذلك؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/aws/aws-cli/issues/602#issuecomment -65198065.

wolfeidau ونعم لقد تحدثت في وقت قريب جدا. يعطي awscli المثبت محليًا للنقطة أخطاء SignatureDoesNotMatch مرة أخرى. ييكيس!

A client error (SignatureDoesNotMatch) occurred when calling the DeregisterInstancesFromLoadBalancer operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/

host:elasticloadbalancing.us-east-1.amazonaws.com
user-agent:aws-cli/1.6.5 Python/2.7.8 Darwin/13.4.0
x-amz-date:20141203T015747Z

host;user-agent;x-amz-date
1d9dafbf4bfa9b1225d91bdbf99d8645503484d174b9094e4c3af637e6664b5b'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20141203T015747Z
20141203/us-east-1/elasticloadbalancing/aws4_request
5a56d12a4920502f4124e37a92aad475c36edda93d9865871e6a4fe1e49045c3'

هل تحدث هذه المشكلة فقط عند إعادة محاولة الطلب؟ أو هل يحدث هذا في كل مرة تقوم فيها بتشغيل الأمر إلغاء تسجيل مثيلات من تحميل موازن؟

jamesls هذا يحدث كل مرة الآن :(

أعلم أن هذه المشكلة مغلقة ولكن أردت أن أشارك أنه يمكنك رؤية هذا الخطأ عند التشغيل في جهاز افتراضي يسبات. في مثل هذه الحالات ، لا تعمل ساعة النظام باستمرار على اللحاق بالركب إذا كنت تستخدم Ubuntu. ما عليك سوى تحديث الوقت لإصلاحه (على سبيل المثال sudo ntpdate -s time.nist.gov).

مرحبًا ، هل هناك أي إصلاح نهائي لهذا؟

+1

باستخدام الإصدار 1.7.8 من CLI ، كنت أرى نفس خطأ SignatureDoesNotMatch عند تجربة ما يلي:
$ aws iam list-users

والحصول على AuthFail لهذا:
$ aws ec2 describe-security-groups

بعد حذف المفاتيح الخاصة بي وتجربة مفاتيح جديدة ، يعمل كلا الأمرين.

هذا هو مفتاح الوصول السري القديم الذي ربما كان سبب مشاكلي ، لاحظ النسبة المئوية ، بالإضافة إلى الأحرف المائلة للأمام: H2J7 / oT3Fib15SwFVB1s3EnTCmg + SC7wF7qoP + dw٪

: +1: @ gsterndale. مفتاح الوصول الخاص بي مع % بداخله لم يعمل. اضطررت إلى إنشاء مفاتيح جديدة.

لقد واجهت هذه المشكلة أيضًا عدة مرات. في كل مرة يتم فيها إعادة إنشاء المفتاح حتى أحصل على مفتاح بدون أي حرف خاص فيه (على وجه الخصوص ، كنت أواجه مشكلات مع علامة + في السر) يتم إصلاحه.

بصدق ، تلاشت جميع مشكلات مفتاح التوقيع الخاصة بي عندما قمت بالتبديل من تشغيل الأمر على جهاز ubuntu بدلاً من تثبيت mac homebrew المحلي.

أنا جديد جدًا على AWS ، وقد واجهت هذا الإصدار على الفور على node js

              ^

SignatureDoesNotMatch: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاح AWS Secret Access وطريقة التوقيع. استشر s
نائب التوثيق للحصول على التفاصيل.

يجب أن تكون السلسلة المتعارف عليها لهذا الطلب
'بريد
/

المضيف: email.us-west-2.amazonaws.com
x-amz-content-sha256: 89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39
x-amz- التاريخ: 20150809T053346Z

مضيف ؛ x-amz-content-sha256 ؛ x-amz-date
89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39 '

يجب أن يكون String-to-Sign
AWS4-HMAC-SHA256
20150809T053346Z
20150809 / us-west-2 / ses / aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e "

+1

أواجه هذه المشكلة مع جميع أوامر aws s3 (awscli 1.8.6 على ubuntu 14.04 LTS).
هل هناك حلول معروفة؟ حاولت حذف ملف بيانات الاعتماد الخاص بي وتشغيل تكوين aws وإعادة التشغيل وإعادة تثبيت awscli.

mcobzarenco ، هل جربت مفاتيح جديدة؟

gsterndale لقد رأيت التعليق أعلاه حول وجود

mcobzarenco لا أعتقد أنه عصر المفاتيح ، بل الأحرف الخاصة الموجودة فيها. عندما أنشأت المفاتيح في الأصل ، حدث أنها تحتوي على أحرف مائلة ، بالإضافة إلى الأحرف المائلة للأمام. أثناء تصحيح المشكلة ، حاولت حذف وإنشاء مفاتيح جديدة. هؤلاء الأشخاص الجدد لحسن الحظ لم يكن لديهم أي من هذه الشخصيات وهم يعملون.

واجهت للتو هذه المشكلة على أوبونتو. عندما قمت بإدخال المفاتيح عبر cli ، تم تخزينها في ~ / .aws / config ، لكنها جردت من الحرف "+". يسمح لي تحرير الملف يدويًا لإضافة علامة "+" بالاتصال.

gsterndale شكرًا على النصيحة ، يمكنني أن أؤكد أن إنشاء مفتاح جديد لا يحتوي على + مفيدًا لي أيضًا. حل stebl رائع إذا كان من غير

لقد واجهت نفس المشكلة عند استخدام AWS SDk مع node js. لحل هذه المشكلات ، اتبعت بالضبط نفس الخطوات المذكورة هنا
http://aws.amazon.com/developers/getting-started/nodejs/

أعتقد أن AWS SDK تم تطويره بإصدار معين من العقدة js ، وعدم التطابق في العقدة js سيؤدي إلى مشكلات مثل هذه.

لدي نفس المشكلة ونعم ، تم حلها باستخدام مفتاح بدون رموز خاصة ( + في حالتي الخاصة)

لقد واجهنا هذا الخطأ (حيث يمكن لجهاز واحد وصف المثيلات باستخدام awscli ولكن الآخر حصل على خطأ رفض الوصول بنفس مفتاح الوصول. في الجهاز الأخير ، أعطى المستخدمون قائمة iam هذا الخطأ SignatureDoesNotMatch). تم حلها عن طريق تصحيح وقت ساعة النظام على الجهاز مع المشكلة.

كما قال tukaaa ، هناك خطأ إذا كان مفتاح الوصول السري يحتوي على حرف غير أبجدي (مثل +). أعتقد أن هروبًا سيئًا في مكان ما ؛- (

ebuildy هل يمكنك تأكيد إصدار CLI الذي تشاهده على ( aws --version )؟ إذا كان هذا هو إصدار سبب من CLI ، فسأمضي قدمًا وأعيد فتح هذه المشكلة.

أحصل على هذا على aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

كنت أواجه نفس المشكلة في مربع Windows واحد ، باستخدام مفتاح بدون أي أحرف غير ألفا. لقد تحققت من أنه ليس خطأ نسخ / لصق باستخدام نفس مخزن اللصق في مربع آخر. إلغاء تثبيت / إعادة تثبيت AWS cli وحذف بيانات الاعتماد / ملفات التكوين ، ثم إعادة تشغيل تكوين aws لإصلاحه.

رأيت هذا للتو على aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25 .

إعادة إنشاء مفتاح بدون إصلاح الأحرف الخاصة. FWIW في حالتي كان الحرف الخاص / وكنت أستخدم ملف INI.

حسنًا إعادة الافتتاح ، سنبحث في هذا.

I أن أؤكد لدي نفس المشكلة كماgsterndale يصف.

aws --version
aws-cli/1.10.6 Python/2.7.11 Linux/3.10.0-327.4.5.el7.x86_64 botocore/1.3.28

لكن مفتاحي لا يحتوي على أي رموز خاصة.

أحصل على نفس الخطأ باستخدام وحدة العقدة s3-cli. يحتوي مفتاحي السري على [ .

لقد اكتشفت أخيرًا ما هو الخطأ. لقد أضفت بطريق الخطأ عدة أحرف إلى المفاتيح. هذا هو السبب.

كنت أواجه هذه المشكلة مع السيناريو التالي ؛ كلاهما على rhel7 و ubuntu. أعتقد أن الأمر يتعلق بشخصيات ليست ألفا كما ذكر آخرون

• دلو s3 محمي لدور واحد
• مثيل ec2 مع الدور المذكور يجب أن يتولى نفس الدور قبل الوصول إلى حاوية s3 المحمية

aws sts assume-role --role-arn <role_name> --role-session-name default --output json --query Credentials > credentials.json
export AWS_ACCESS_KEY_ID=`sed -n 's/.*"AccessKeyId": "\(.*\)"/\1/p' credentials.json`
export AWS_SECRET_ACCESS_KEY=`sed -n 's/.*"SecretAccessKey": "\(.*\)",/\1/p' credentials.json`
export AWS_SESSION_TOKEN=`sed -n 's/.*"SessionToken": "\(.*\)",/\1/p' credentials.json`

أعتقد أن شيئًا ما باستخدام الاستعلام - كان يفسد أوراق الاعتماد. عند تشغيل الأوامر يدويًا ونسخ القيم ولصقها ؛ ثم تحديد متغيرات البيئة يبدو أنها تعمل بشكل جيد.

واجهت نفس المشكلة عند تشغيل الإصدار 1.10 من awscli على نظام التشغيل Mac (مثبت عبر نقطة) مقابل الإصدار 1.2.9 من Ubuntu (صورة أمازون). ينتج aws configure --profile user تكوينين مختلفين تحت كل منهما. أنتج الإصدار 1.10 ملفين: التكوين وبيانات الاعتماد. الإصدار 1.2.9 أنتج للتو ملف تكوين (ولكن مع معلومات الاعتماد). عندما قمت بحذف بيانات الاعتماد وملف التكوين الذي تم إنتاجه بواسطة الإصدار 1.10 وقمت بنسخ ملف التكوين الذي تم إنتاجه بواسطة الإصدار 1.2.9 ، فقد نجح كل شيء ، حتى مع الأحرف الخاصة وتشغيل الإصدار 1.10 من awscli. ملف التكوين الناتج عن الإصدار 1.2.9 هو

[profile FOO0]
aws_secret_access_key = FOO1
aws_access_key_id = FOO2
output = FOO3
region = FOO4

يمكن تأكيد أنه بسبب أحرف غير أبجدية رقمية.

لدي نفس المشكلة مع مفتاح سري يحتوي على +. ومع ذلك ، فأنا لست صاحب حساب S3 ولا يمكنني إنشاء حساب جديد بسهولة. هل وجد أي شخص أي إصلاح بخلاف إنشاء مفتاح جديد بدون أحرف خاصة؟

tl ؛ dr الحل: إعادة إنشاء بيانات الاعتماد بشكل متكرر حتى لا يحتوي مفتاح aws_secret_access_key الخاص بك على أحرف غير أبجدية رقمية ... في حالتي احتوى aws_secret_access_key على + (علامة الجمع)

لقد أجريت للتو تثبيتًا جديدًا ... نفس المشكلة ... هذه على Ubuntu ... إنها ليست مشكلة نظام تشغيل محلي ، إنها مشكلة Amazon API ، لذا تجاهل التعليقات الأخرى التي تقول إن الخروج من OSX يصلحها

أوس ec2 وصف الحالات

حدث خطأ (AuthFailure) عند استدعاء عملية DescriptionInstances: لم تكن AWS قادرة على التحقق من صحة بيانات اعتماد الوصول المقدمة

------------------------------------------------

AWS EC2 وصف مجموعات الأمان

حدث خطأ (AuthFailure) عند استدعاء عملية DescriptionSecurityGroups: لم تكن AWS قادرة على التحقق من صحة بيانات اعتماد الوصول المقدمة

------------------------------------------------

AWS ECR get-login

حدث خطأ (InvalidSignatureException) عند استدعاء عملية GetAuthorizationToken: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاح AWS Secret Access وطريقة التوقيع. راجع وثائق الخدمة للحصول على التفاصيل.

يجب أن تكون السلسلة المتعارف عليها لهذا الطلب
'بريد
/

نوع المحتوى
المضيف: ecr.us-east-1.amazonaws.com
x-amz- التاريخ: 20160615T182955Z
x-amz- الهدف: AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

نوع المحتوى ؛ مضيف ؛ x-amz-date ؛ x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a '

يجب أن يكون String-to-Sign
AWS4-HMAC-SHA256
20160615T182955Z
20160615 / us-east-1 / ecr / aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7 "

------------------------------------------------

Aws iam قائمة المستخدمين

حدث خطأ (SignatureDoesNotMatch) عند استدعاء عملية ListUsers: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاح AWS Secret Access وطريقة التوقيع. راجع وثائق الخدمة للحصول على التفاصيل.

يجب أن تكون السلسلة المتعارف عليها لهذا الطلب
'بريد
/

المضيف: iam.amazonaws.com
x-amz- التاريخ: 20160615T183516Z

المضيف ؛ x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2 "

يجب أن يكون String-to-Sign
AWS4-HMAC-SHA256
20160615T183516Z
20160615 / us-east-1 / iam / aws4_request
ad9f7581f0bf25ecae56355a6c96b60f3dc3188efbbdb3d0d4806e9f2c5cf8a9 '

------------------------------------------------

AWS - الإصدار
aws-cli / 1.10.38 Python / 2.7.11 + Linux / 4.4.0-22-generic botocore / 1.4.28

------------------------------------------------

cat /root/.aws/credentials
[إفتراضي]
aws_access_key_id = AKIAJ7FCEUVVSGX7KZGQ
aws_secret_access_key = inCv47xj + eGE2C9crwilZJmKZg6vN / 3JTh5LDaNb

    Notice the plus sign ( + ) in above aws_secret_access_key   !!!!

   aws only works when aws_secret_access_key does NOT contain non-alpha chars

------------------------------------------------

المحلول :
بعد حذف وإنشاء بيانات اعتماد جديدة
حيث لم يكن لدى aws_secret_access_key علامة الجمع (+) كان كل شيء أعلى بكثير من الأوامر التي بدأت في العمل بشكل جيد

كان لي نفس المشكلة. إعادة إنشاء بيانات الاعتماد إلى أن لم يكن لدي أي أحرف خاصة في العمل بالنسبة لي.

لقد وجدت أنه عندما قمت بنسخ بيانات الاعتماد ولصقها ، كان لديهم ^ M حرفًا في النهاية مما تسبب في حدوث الخطأ.

الحصول على مفتاح سري بدون + إصلاحه لي أيضًا ...

ملاحظة - إذا كنت ترى هذه المشكلة ضمن عامل إرساء (boot2docker VM'd) ، فمن الممكن أن تكون ساعة الجهاز الظاهري غير متزامنة.
انظر: http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

لدي نفس المشكلة. ماذا لو لم يكن لدي أذونات لإعادة إنشاء بيانات الاعتماد .. أي إصلاحات ممكنة باستخدام طرق أخرى؟

تحديث: لقد أصلحت هذا عن طريق تشغيل rm -rf .aws/cli/cache/

أواجه هذه المشكلة الآن أيضًا. عند محاولة تولي الدور

الإصدار:
aws-cli/1.11.17 Python/2.7.10 Darwin/16.1.0 botocore/1.4.74

تحرير: حاولت أيضًا التحديث مرة أخرى الآن ، نفس المشكلة:
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

انتاج:

Assuming role arn:aws:iam::XXXXXXXX:role/XXXX-staging using profile default

An error occurred (SignatureDoesNotMatch) when calling the AssumeRole operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/

host:sts.amazonaws.com
x-amz-date:20161118T102600Z

host;x-amz-date
41db88384d54dc0783e616aa0662ebffce8832b35025195052029a5dc0e33c0e'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20161118T102600Z
20161118/us-east-1/sts/aws4_request
786b3d624f5aeea9ffcb2b802b177a4c2aebbfed608a2464ee684c6972bc6bc6'

لا تزال نفس المشكلة موجودة مع أحدث إصدار (محدث) من AWS CLI أيضًا. لقد قمت للتو بترقية 1.8.3 CLI الخاص بي إلى 1.11.19 - ولم أتمكن من تنفيذ أي أوامر باستخدام مستخدم / مفاتيح جديدة قمت بإنشائها. اضطررت إلى إعادة تدوير حوالي 5 مفاتيح قبل أن أحصل على زوج حيث لا يحتوي المفتاح السري على أي أحرف غير أبجدية. بمجرد أن عثرت على مثل هذا الزوج - يعمل CLI بشكل جيد.

مزعج للغاية - أتمنى ألا تقوم أمازون بإنشاء مفاتيح غير صالحة لا يمكنها معالجتها .....

@ mpopova-yottaa هل حاولت مسح ذاكرة التخزين المؤقت للرهبة تمامًا؟ حاول حذف الدليل ~/.aws بالكامل (قم بعمل نسخة من ملفات التهيئة / الاعتماد)

aws ec2 describe-instances بالنسبة لي ، ولكن عند محاولة إنشاء مكدس تكوين السحابة:

"استثناء في الموضوع" main "com.amazonaws.services.cloudformation.model.AmazonCloudFormationException: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاح AWS Secret Access وطريقة التوقيع. راجع وثائق الخدمة للحصول على التفاصيل.

يجب أن تكون السلسلة المتعارف عليها لهذا الطلب
'بريد
/

amz-sdk- استدعاء المعرف: 18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz- sdk- أعد المحاولة: 3/345/470
المضيف: cloudformation.us-west-1.amazonaws.com
وكيل المستخدم
x-amz- التاريخ: 20161127T194448Z

amz-sdk-invitation id؛ amz-sdk-retry؛ host؛ user-agent؛ x-amz-date
aca0973fb4ac4029ec038d9c80b4afa23b6d305822b10e6bc32751ee1bd311d5 '

يجب أن يكون String-to-Sign
AWS4-HMAC-SHA256
20161127T194448Z
20161127 / us-west-1 / cloudformation / aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428 '(الخدمة: AmazonCloudFormation ؛ رمز الحالة: 403 ؛ رمز الخطأ: SignatureDoesNotMatch ؛ معرف الطلب: f52abbd4-b4d9-11e6-b9d50-d5c

config details:

`$: aws --version`           >>       `aws-cli/1.11.21 Python/2.7.12 Darwin/14.5.0 botocore/1.4.78`

`$: aws configure list`     >>
```   Name                Value                Type     Location
      ----                   -----                  ----        --------
profile                    not set>             None    None
access_key     ****************RTSA                env
secret_key     ****************UC3r                  env
region                us-west-1              env       AWS_DEFAULT_REGION

يحتوي المفتاح السري فقط على أحرف أبجدية رقمية ، لذلك أنا عالق.

@ aebrow4 إنه أسفل ذاكرة التخزين المؤقت للرهبة. حاول حذف: .aws/cli/cache/

cultavix لا يوجد دليل cli داخل .aws

حصلت على هذا الخطأ عند تشغيل aws glacier upload-archive مع --archive-description "`date`" . عندما أستخدم --archive-description "`date +%Y/%m/%d`" فإنه يعمل بشكل جيد ، لذلك يبدو أن هناك مشكلة في الهروب.

كنت أواجه مشكلة مماثلة:

λ aws s3 sync s3://foo-bar-assets/ . --exclude "*/*.mp4" --exclude "*.mp4" fatal error: An error occurred (SignatureDoesNotMatch) when calling the ListObjects operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

حاولت مزامنة الوقت مع خادم NTP (بنجاح) ، لكن هذا لم يحل المشكلة. إعادة إنشاء المفاتيح حتى أصلح مجموعة بدون أحرف خاصة.

λ aws --version aws-cli/1.11.16 Python/2.7.9 Windows/8 botocore/1.4.73

لدي نفس المشكلة باستخدام awscli ونموذج كود بيثون (boto3).
لاحظ أنني أستخدم وحدة تخزين كائن IBM S3 API متوافقة ، ويمكنني سرد ​​الحاويات ومحتوياتها ولكن لا يمكنني التحميل (لكل من كود pyhton و cli).
اختبرت السيناريو مع ruby aws-sdk وهو يعمل بشكل جيد (تحميل / تنزيل).
-- ترتيب
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

بدأت للتو في مواجهة هذه المشكلة نفسها مع برنامج نصي كنت أستخدمه منذ شهور لإيداع تحميلات متعددة الأجزاء في Glacier. لا يزال بإمكانك الإيداع بشكل جيد عبر aws cli ، لذلك لا تزال بيانات الاعتماد تعمل ، لكن البرنامج النصي الذي يستخدم boto3 يفشل مع:

"botocore.

AWS - الإصدار هو
aws-cli / 1.11.38 Python / 2.7.10 داروين / 15.6.0 botocore / 1.5.1

(نعم ، لقد قمت بتحديث كل شيء يفكر في أنه قد يحل المشكلة ... لا يوجد مثل هذا الحظ.)

الحصول على زوج جديد من المفاتيح بدون أي أحرف خاصة (كان + في حالتي) أصلح المشكلة بالنسبة لي

تأكيد آخر هنا لمعالجة غير صحيحة لـ + في المفتاح السري.

مرحبًا بالجميع ، إليك برنامج نصي استخدمته لمحاولة إعادة معالجة هذه المشكلة: https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . هذا ما يفعله البرنامج النصي:

• يقوم بإنشاء زوج access_key / secret_key جديد عبر aws iam create-access-key في حلقة حتى يعثر على بيانات الاعتماد التي تحتوي إما على + أو / char.
• يقوم بإنشاء ملف تعريف "testcreds" جديد باستخدام بيانات الاعتماد التي تم إنشاؤها حديثًا
• يحاول استدعاء أوامر AWS CLI المختلفة لضمان عمل بيانات الاعتماد هذه

يقوم بذلك في حلقة لا نهائية حتى يفشل استدعاء API. حتى الآن لم أتمكن من جعلها تفشل. المفاتيح السرية التي تحتوي على + و / تعمل من أجلي.

في هذه المرحلة ، أكدنا أنه من الممكن بالتأكيد استخدام مفاتيح secret_keys التي لها + أو / لذلك لا أعتقد أن السبب الجذري هو شيء مباشر مثل خطأ في رمز التوقيع لدينا ينكسر عند وجود + . إعادة قراءة التعليقات في سلسلة الرسائل هذه ، قد تكون هناك مشكلة في كيفية إدخال بيانات الاعتماد في الملف ~/.aws/config أو ~/.aws/credentials . ربما هناك بعض الأشياء الخاصة بالنظام الأساسي والتي تقوم بتغيير الأحرف التي تحتوي على + أو / .

لذلك بالنسبة لأي شخص لا يزال يواجه هذه المشكلة ، سيكون من المفيد حقًا إذا كان بإمكانك تقديم بعض المعلومات الإضافية:

1. كيف تحصل على بيانات الاعتماد (نسخ / لصق من وحدة التحكم ، aws iam create-access-key ، ملف CSV من وحدة التحكم ، إلخ)؟
2. كيف يتم تكوين CLI لاستخدام بيانات الاعتماد هذه؟ هل تقوم بتشغيل aws configure وتقوم بإدخال القيم عندما يُطلب منك ذلك؟ هل تقوم بهذا برمجيًا عن طريق تشغيل aws configure set ؟ هل تقوم بتحرير ~/.aws/config و / أو ~/.aws/credentials يدويًا؟ تعيين مختلف AWS_* vars؟

أشياء إضافية قد تكون أكثر فائدة إن أمكن:

1. إذا كنت تستخدم حزم SDK أخرى ، فهل تعمل بيانات الاعتماد التي لا تعمل في CLI في مجموعات AWS SDK الأخرى؟
2. إذا كان لديك حساب تجريبي أو مستخدم اختبار IAM ، فهل يفشل تشغيل البرنامج النصي الذي أستخدمه للاختبار ؟

أي معلومات إضافية قد تساعدنا في إعادة معالجة هذه المشكلة من جانبنا ستكون رائعة.

ما زلت أواجه هذه المشكلة. للإجابة على أسئلتكم:
تم إنشاء بيانات الاعتماد في وحدة تحكم أمازون وقصها / لصقها في بيانات اعتماد ~ / .aws / (تم تحريرها باستخدام emacs على جهاز Mac)

من عملية استكشاف الأخطاء وإصلاحها التي قمت بها حتى الآن (وأنا مبتدئ في هذا ...) فإن "السلسلة الأساسية" صحيحة ، لكن "String-to-Sign" خاطئة ، ولها سطر أخير مختلف. أي عندما أطبع القيمة المرجعة لـ auth.py string_to_sign ، فإن الرقم الناتج من 'sha256 (canonical_request.encode (' utf-8 ')). hexdigest ())' يختلف عن الرقم المبلغ عنه في الخطأ المُعاد "السلسلة -to-Sign كان يجب أن يكون ".

لا توجد أحرف خاصة في بيانات الاعتماد الخاصة بي ، ويتم العمل عند استخدام أدوات أخرى ، مثل CrossFTP (الذي لا أريد استخدامه !!!)

فإن أي رؤى سيتم تقدير كبير!!

@ samato88 الذي يبدو أنه مشكلة مختلفة هناك. إذا كان بإمكانك مشاركة أي معلومات تصحيح (مع التأكد من إزالة أي معلومات حساسة) فمن شأن ذلك أن يساعدك.

لا تتأثر السلسلة string_to_sign بالمفتاح secret_access_key. عندما نوقع طلبًا ، فإننا نأخذ طلب HTTP الذي نحن على وشك إرساله ، ونحوله إلى سلسلة (مثل علامة ot) ، ثم باستخدام المفتاح السري ، نوقع هذه السلسلة بالمفتاح السري (تخطي القليل التفاصيل هنا). لذا فإن أي مشكلات تتعلق بالسلسلة المراد توقيعها ستكون منفصلة عن هذه المشكلة.

هل يمكنك فتح مشكلة أخرى وتقديم ناتج --debug (أو تضمين الطلب الكامل ورسالة الخطأ من الخدمة)؟ سنكون سعداء للنظر في هذا الأمر من أجلك.

شكرًا jamesls - لقد فتحت عددًا منفصلاً في:
https://github.com/aws/aws-cli/issues/2474

أي أفكار محل تقدير كبير.

إذا توقف وقت النظام لديك لأكثر من 5 دقائق ، فلن تتمكن من استخدام CLI

فقط تشغيل ... sudo ntpdate -s time.nist.gov

ثم أعد المحاولة

لدي نفس المشكلة ، المفتاح السري الخاص بي يحتوي على علامة "+". لقد حذفت ملف .aws / بيانات الاعتماد الخاص بي وأعد تشغيل تكوين aws. بعد أن عملت استفساري إلى قائمة انتظار sqs لتلقي الرسالة.

شكرا @ AlexParra03 . لدي نفس المشكلة وساعدتني تعليقاتك في حل .... :-)

robotzero هل تتذكر كيف أدخلت بيانات الاعتماد الخاصة بك؟ هل قمت بتشغيل aws configure ثم نسخ / لصق القيم من وحدة تحكم الويب؟

نعم ، قمت بتشغيل AWS تكوين ونسخ لصق القيم.

نعم ، كان لدي + في سري ، مما تسبب في حدوث هذا الخطأ حتى الآن. عمل مفاتيح جديدة بدون أحرف خاصة حل المشكلة.

AWS - الإصدار
aws-cli / 1.11.78 Python / 3.6.1 داروين / 15.6.0 botocore / 1.5.41

كان لدي + و / في سري. أسرار بدون هذه حلت المشكلة بالنسبة لي.

كما كانت هذه المشكلة.

$ aws --version
aws-cli/1.11.44 Python/3.5.3 Linux/4.10.0-19-generic botocore/1.5.7

$ lsb_release -sd 
Ubuntu 17.04

كان لديه "+" في أوراق الاعتماد. تم حلها عن طريق إعادة إنشاء مفتاح الوصول بدونها. كملاحظة: "/" هي شخصية رائعة يجب أن تمتلكها.

adityanatrajshwetapurushedamienrj يمكنك فقط الإجابة على هذه الأسئلة هنا ؟ في هذه المرحلة نحاول الحصول على مزيد من المعلومات حول بيئتك وكيف تقوم بإدخال بيانات الاعتماد. كما هو مذكور في هذا التعليق ، فإن إنشاء مفتاح سري باستخدام + لا يعيد حل المشكلة بالنسبة لنا ، لذلك من المحتمل أن يكون مرتبطًا بمجموعة من بيئتك و / أو كيفية إدخال بيانات الاعتماد.

بعبارة أخرى ، نحن بحاجة إلى مزيد من المعلومات من الأشخاص حتى نتمكن من استكشاف الأخطاء وإصلاحها.

تضمين التغريدة

1. كيف حصلت على أوراق الاعتماد؟

حصلت على بيانات الاعتماد بنسخها من وحدة تحكم الويب.

1. كيف أقوم بتهيئة CLI لاستخدامها؟

لقد قمت بإنشاء الملفين يدويًا:

~ / .aws / config

[default]
region = us-east-1
output = json

~ / .aws / أوراق الاعتماد

[default]
aws_access_key_id = ACCESS_KEY_HERE 
aws_secret_access_key = SECRET_ACCESS_KEY_THAT_BREAKS_WITH_A_+_SIGN

عذرًا ، لا يمكنني المساعدة في أسئلة المكافأة لأنني قمت بإزالة مفاتيح الوصول الخاصة بي التي تحتوي على علامات "+" ، وبالتالي لا تظهر المشكلة.

شكرًا adityanatraj ، كل جزء يساعد.

الخطوة التالية التي ستساعدنا في استكشاف الأخطاء وإصلاحها هي معرفة ما إذا كانت هذه مشكلة في CLI فقط أو مشكلة في بيانات الاعتماد نفسها. بالنسبة لأي شخص لا يزال يواجه هذه المشكلة ، سيكون من المفيد حقًا أن تجرب بيانات الاعتماد هذه في حزم AWS SDK الأخرى. للمساعدة في ذلك ، قمت بتجميع عينة من الريبو / البرنامج النصي معًا مما يجعل هذا الأمر سهلاً إذا كنت لا ترغب في إعداد هذا بنفسك: https://github.com/jamesls/aws-creds-test . ما عليك سوى استنساخ الريبو وتشغيل make install ، make test .

/tmp $ mkdir /tmp/repro-cli-602
/tmp $ cd /tmp/repro-cli-602/
/tmp/repro-cli-602 $ git clone git://github.com/jamesls/aws-creds-test
Cloning into 'aws-creds-test'...
...
/tmp/repro-cli-602 $ cd aws-creds-test/
/tmp/repro-cli-602/aws-creds-test (master u=) $ make install
npm install
[email protected] /private/tmp/repro-cli-602/aws-creds-test
├─┬ [email protected]
...
pip install -r requirements.txt
Requirement already satisfied: botocore<2.0.0,>=1.5.0 in /usr/local/lib/python2.7/site-packages (from -r requirements.txt (line 1))
...



/tmp/repro-cli-602/aws-creds-test (master u=) $ make test
./test-creds.sh
Testing python...
Access Key:
Secret Access Key:
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20

SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Successfuly made an AWS request with the provided credentials.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20


SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Sucessfully made an AWS request with the provided credentials.

بالنسبة للأشخاص الذين يواجهون هذه المشكلة ، يرجى تشغيل البرنامج النصي للاختبار ومشاركة الإخراج.

حدث هذا الاستثناء نفسه بالنسبة لي عند طلب PutObject (C #) ، عندما تحتوي بيانات تعريف الكائن على أحرف Unicode.

كان لي نفس القضية. مفاتيح سرية جديدة مع + و / لا تعمل. لقد قمت بإنشاء مفاتيح جديدة بدون هذه الأحرف وهي تعمل بشكل جيد.
البرنامج النصي للاختبار خاص بنظام Linux وأنا أقوم بتشغيل windows.
لقد قمت بلصق بيانات الاعتماد الخاصة بي باستخدام Control-C و Control-V باستخدام windows shell و _aws configuration_
وكنت أستخدم فقط _aws cp_

تم اختبار هذا أيضًا ، وهو يعمل بشكل جيد طالما أن المفتاح السري لا يحتوي على رموز ، كما هو مذكور أعلاه.

آمل أن يتم حل هذا الأمر قريبًا ، إنه لأمر مؤلم أن تستمر في تجديد بيانات الاعتماد حتى أحصل على واحدة تعمل!

لقد رفعت بطاقة دعم إلى AWS بالأمس ، ويبدو اليوم أنه تم حلها

لقد اختبرت عدة مرات و + و / يبدو أن كلاهما يعمل الآن؟ لم يعد بإمكاني إعادة إنتاج هذا الخطأ.

لدي نفس المشكلة على Pi الخاص بي.
مع أحدث إصدار من awscli (aws-cli / 1.11.85 Python / 3.4.2 Linux / 4.9.24-v7 + botocore / 1.5.48) ما زلت أواجه المشكلة:

الجذر @ pi : ~ # aws s3 ls s3: //
حدث خطأ (SignatureDoesNotMatch) عند استدعاء عملية ListBuckets: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته.
تحقق من مفتاح الوصول السري الخاص بك وطريقة التوقيع. لمزيد من المعلومات ، راجع مصادقة REST ومصادقة SOAP للحصول على التفاصيل.

حتى مع وجود مفتاح سري لا يحتوي على أحرف خاصة (+ أو /) ، فإن الوصول لا يعمل. كان الوقت دائمًا متزامنًا ، وللأسف لم تكن هذه هي المشكلة أيضًا.

في ملف ".aws / config" أضفت منطقة صالحة (للاختبار فقط ..) وفجأة نجحت. نظرًا لأنني أستخدم وحدة تخزين s3 متوافقة (وليس s3 من Amazon)

[إفتراضي]
aws_secret_access_key = MYKEY
aws_access_key_id = MYID
region = us-east-1 <- كانت هناك قيمة "وهمية" من قبل.

كما يبدو ، يجب أن يكون للمنطقة قيمة "صحيحة". عندما أعيده إلى شيء مختلف مثل "dummyvalue" ، أحصل على نفس الخطأ المذكور أعلاه.
الآن بالقيمة "us-east-1" تعمل!
أمل أن هذا يساعد شخصاما.

أنا فقط واجهت هذا أيضا. يبدو أيضًا أن هناك مشكلة في "+" في المفتاح السري. إذا كان لدي اعتمادات في متغيرات البيئة أحصل على الخطأ. إذا قمت بوضعها في ملف ~ / .aws / أوراق الاعتماد (عن طريق التحرير باليد) فلن أحصل على الخطأ.

[عدل] لاحظت للتو أن متغيرات البيئة كانت في ملف منسق من أجل دوس (صص = دوس في فيم). كان هذا لأنني أخذت للتو ملف .csv كما تم تنزيله وقمت بتحريره لتغيير الإدخالات إلى متغيرات البيئة. عندما أعدت تنسيق الملف إلى 'ff = unix' لم أعد أحصل على الخطأ. الاختلاف الوحيد بين 2 هو إرجاع السطر ، يستخدم dos "CR-NL" بينما unix هو "NL" فقط. تخميني هو أن شخصية "CR" كانت هي المشكلة.

أنا أيضًا ، وقم أيضًا بتأكيد مشكلة "+"

إذا واجهت هذا عند استخدام Docker لنظام التشغيل Mac ، فإن إعادة تشغيل Docker ستعمل ببساطة على إصلاح التناقض في وقت النظام.

كنت أواجه نفس المشكلة.
دقق في السر ، وكان يحتوي على + / فيه.
كان لا بد من إنشاء زوج معرف جديد بدون شخصية خاصة لجعله يعمل

إنشاء أزواج مفاتيح جديدة حتى حصلت على واحدة بدون أحرف خاصة وحلها لي أيضًا ؛ الأحرف الخاصة (على وجه التحديد +) لا تعمل في ~ / .aws / أوراق الاعتماد.

مفتاح تم إنشاؤه بدون أحرف خاصة (على وجه التحديد + ) أصلح المشكلة بالنسبة لي أيضًا.

يؤدي تنسيق الملف وفقًا لتعليقeikenb إلى حل المشكلة أيضًا.

لقد نجح حذف المفتاح وإنشاء مفتاح جديد بالنسبة لي.

تلقيت للتو هذا الخطأ. وقت النظام المحدّث والذي بدا أنه يبعد أكثر من 6 دقائق عن توقيت جرينتش. تم إصلاح المشكلة على الفور.

كان الأمر غريبًا وصعبًا بالنسبة لي.
لقد عانيت من هذه المشكلة وكنت أحاول عدة مرات حلها.
في هذه اللحظة عملت فجأة! لقد تفاجأت لذلك صنعت دلوًا جديدًا لكنه لم ينجح. نظرًا لأنني لم أفعل شيئًا سوى تغيير الرمز ، فقد انتظرت لساعات. أخيرًا ، نجح الأمر على الرغم من أنني لم أفعل شيئًا. لا أصدق ذلك ...

باستخدام aws configure في bash shell على Windows 7 ، وجدت أن لديّ سطرين aws_secret_access_key في .aws/credentials وكان السطر الثاني حيث أخطأت في كتابة حمولة من القمامة . تم حذف السطر الثاني وعمل كل شيء.

aws-cli/1.11.119 Python/2.7.12 Linux/4.4.0-53-generic botocore/1.5.82

رؤية هذه المشكلة على Linux Mint هنا ، مع عدم وجود + في مفتاحي أو سرّي.

الإخراج من نص الاختبار:

/aws-creds-test $ make test
./test-creds.sh
Testing python...
Access Key: 
Secret Access Key: 
AKID   hash: 36b0df669bfc2fa232f31ada2b40e8f58ec152b0afee875f28b21e32e2d59a30
AKID length: 20

SAK    hash: 02b21158d3ab7d2691ceef468951c3b3551704a8eea19ad4a8f59c7be38378f6
SAK  length: 40
Error making AWS request: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 36b0df669bfc2fa232f31ada2b40e8f58ec152b0afee875f28b21e32e2d59a30
AKID length: 20


SAK    hash: 02b21158d3ab7d2691ceef468951c3b3551704a8eea19ad4a8f59c7be38378f6
SAK  length: 40
Error making AWS request
{ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
  message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.',
  code: 'SignatureDoesNotMatch',
  time: 2017-09-18T20:33:23.951Z,
  requestId: '9e62c6c2-9cb0-11e7-9856-a5fd5c3e417d',
  statusCode: 403,
  retryable: false,
  retryDelay: 60.66602455065775 }
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 1

بعد ترقية awscli إلى aws-cli/1.11.154 Python/2.7.12 Linux/4.4.0-53-generic botocore/1.7.12 :

$ make test
./test-creds.sh
Testing python...
Access Key: 
Secret Access Key: 
AKID   hash: 0cdf83ac8cf800ca46738682ff5a0ab35d94891a568fc6fd9115ecf13dcce542
AKID length: 20

SAK    hash: 7ae856b46f3d5cd23b94f60765adbeb13215f6c226a2953ab93eed9e26d51694
SAK  length: 40
Error making AWS request: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 0cdf83ac8cf800ca46738682ff5a0ab35d94891a568fc6fd9115ecf13dcce542
AKID length: 20


SAK    hash: 7ae856b46f3d5cd23b94f60765adbeb13215f6c226a2953ab93eed9e26d51694
SAK  length: 40
Error making AWS request
{ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
  message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.',
  code: 'SignatureDoesNotMatch',
  time: 2017-09-18T20:43:21.662Z,
  requestId: '02ab939a-9cb2-11e7-a1f3-87975b0dbd52',
  statusCode: 403,
  retryable: false,
  retryDelay: 86.52138921193912 }
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 1

لقد قمت للتو بإعادة إنشاء مفاتيحي - لا يزال مفتاحي الجديد يحتوي على "+" ، لكن الآن قادر على استخدام cli

يمكن أن يكون بهذه السهولة

@ DanAbbz92 في الواقع ، لقد وجدت نفس الحل الآن. لا توجد فكرة عن سبب عدم عمل المفاتيح القديمة أبدًا ، ولكن المفاتيح الجديدة كانت جيدة باستخدام نفس العملية.

كان لدي مفتاح ^ V في مفتاحي السري من محاولة لصق سيئة. قد يكون من الحكمة وضع تحذير أقوى عند التحقق من الأحرف السيئة في المفاتيح. سيمنع المزيد من التصعيد غير الضروري.

تم الإبلاغ عن هذه المشكلة في عام 2014. واليوم هو 26 تشرين الأول (أكتوبر) 2017. لقد واجهت هذه المشكلة ، وكان سري بداخلها علامة "+". لقد أنشأت مفتاحًا جديدًا ووضعته في ~ / .aws / config
تعال إلى أمازون ، هل تخطط يومًا لإصلاح هذا الخطأ * ؟؟؟

لقد واجهت هذه المشكلة اليوم بعد تثبيت cli وتشغيل aws configure . لم تكن مفاتيحي تحتوي على أحرف خاصة ولكن ما يلي حل مشكلتي:

• rm -r ~/.aws/
• أعاد إنشاء المجلد .aws والملف credentials وإضافة بيانات الاعتماد مرة أخرى يدويًا

tl ؛ يعمل دكتور إيقاف تشغيله وتشغيله مرة أخرى بالنسبة لي ¯_ (ツ) _ / ¯

بالنسبة للأشخاص الذين يستخدمون Hadoop ينتهي بهم الأمر هنا: تم إصلاح الخلل ذي الصلة لـ Hadoop 2.8.0:
" s3:" تنقطع عناوين URL عندما يحتوي المفتاح السري على شرطة مائلة ، حتى لو كانت مشفرة

مرحبًا ، لقد التقطت اليوم نفس المشكلة.
كان على الصندوق وقت خاطئ. بعد تحديث الوقت كل شيء يعمل.

إضافة "أنا أيضًا" أخرى

كان لدي مفتاح سري يحتوي على حرفين '+' بداخله ، وقد نجح ذلك من ملف .aws / بيانات الاعتماد الخاص بي على Windows VM (عند استخدامه بواسطة تطبيق .NET) ، ولكن عندما قمت بتثبيت awscli من الشراب على جهاز MacBook Pro الخاص بي ، ونسخ ملفات .aws عبر (اختبار ترميز الملفات ، وتنسيقات نهاية السطر ، إلخ) فشلت مع SignatureDoesNotMatch.

حاولت إعادة إنشاء بيانات الاعتماد حتى حصلت على مفتاح سري بدون أي أحرف أبجدية رقمية ، وهي تعمل الآن من awscli على جهاز Mac الخاص بي. نسخ بيانات الاعتماد هذه مرة أخرى إلى جهاز Windows الخاص بي وتشغيل تطبيق .NET ، الذي لا يزال يعمل.

لم أقم بإجراء أي تغييرات على الوقت على أي من الجهازين (كان Mac يستخدم NTP بالفعل ، ويبدو أن Windows VM يبدو وكأنه يعمل متأخرًا بحوالي 12 دقيقة عن الوقت الفعلي)

لقد قمت بتثبيت awscli مع: brew install awscli

و aws - إرجاع الإصدار: aws-cli / 1.14.30 Python / 3.6.4 Darwin / 16.7.0 botocore / 1.8.34

حسنًا ، لقد دفعت الكود إلى لامدا بعد ظهر اليوم (2018-02-01 15:48 EST مع لامدا في us-east-1).
الآن في الساعة 6 مساءً ، أتلقى أخطاء في التوقيع على كل نظام في المكتب.
إذا نظرنا إلى الوراء من خلال هذا الموضوع: وقتي صحيحة ، ولم يتغير شيء ، وبيانات الاعتماد عمرها أقل من عام ، وتعمل منذ يوم إنشائها ، باستخدام إصدار البيرة aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (لقد حاولت الرجوع إلى 1.14. نسخة 2x ، لا حب)

هذا هو بعض المالاركي

وجود نفس المشكلة وحلها إنشاء مفاتيح جديدة دون أي أحرف خاصة (مثل / ، + وما إلى ذلك).

شكرا لـ hellais على المدخلات!

فقط واجهت نفس المشكلة ، تم حلها عن طريق تصحيح ساعة الكمبيوتر المحمول الخاصة بي. يبدو أنني كنت متأخرًا عن الوقت.

لقد واجهت هذه المشكلة للتو ويبدو أن عميل ntp الخاص بي كان متأخرًا 10 دقائق. فعلت ntpdateوكل شيء تم إصلاحه الآن.

يمكنني أن أؤكد أن إعادة إنشاء مفاتيح الوصول الخاصة بي حتى حصلت على واحدة بدون أحرف خاصة بها ، قد نجحت. يا لها من حشرة سخيفة ، واو.

نظرًا لأن هذه مشكلة طويلة الأمد ، ألن يكون من الذكاء تحديث رسائل الخطأ لمنح المستخدمين رابطًا لإصلاح محتمل ، مثل إعادة بناء مفاتيحك؟ بدلاً من شيء يوضح أن المشكلة أكثر تعقيدًا بكثير من "نعم ، نخطئ عندما تحتوي مفاتيحك على أحرف خاصة ، آسف!".

نفس المشكلة تسمع:

الإصدارات:

aws-cli/1.14.58 Python/2.7.10 Darwin/17.4.0 botocore/1.9.11

يأمر:

aws s3 ls
حصلت على الخطأ التالي:
Unknown Signature Version: s3v3.

لا حل:

قمت بتحديث عباءتي وقمت بإنشاء سر بدون أي شخصية خاصة

التحديث - تم إصلاحه من خلال المتابعة

aws configure set default.s3.signature_version s3v4

نعم ، لا تزال هذه مشكلة - لقد انتهى مفتاحي السري بحرف + ولم أجد أي إصلاح ناجحًا. أعيد إنشاء مفاتيح جديدة بدون + في نهاية المفتاح السري وعمل بشكل جيد.

كيف بحق الأرض لا تزال هذه مشكلة؟

حدث خطأ (SignatureDoesNotMatch) عند استدعاء عملية CreateMultipartUpload: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاحك وطريقة التوقيع.
الرجاء المساعدة.

يبدأ سري بعلامة + ولم أكن أعرف حتى بوجود هذه المشكلة حتى اليوم. أستخدم boto3 python للوصول إلى s3. لا يعمل عندما أقوم بتمرير بيانات الاعتماد كسلاسل أولية ولكنه يعمل بشكل جيد إذا قمت بتحميله من config.ini كمتغير باستخدام configparser.RawConfigParser() . بالطبع ، إنشاء سر جديد بدون علامة + في النهاية أو في البداية سيحل هذه المشكلة أيضًا.

ومع ذلك ، إذا تعذر إصلاح هذا (لسبب ما) ، فربما يتم تغيير رسالة الاستثناء إلى شيء مثل "لا نسمح بالتوقيع + ، قم بإنشاء واحدة جديدة إذا كنت تريد الوصول إليها بالطريقة التي تريدها".

أنا أستخدم aws cli على OSX وكان لدي أيضًا سر يبدو أنه غير صحيح. يحتوي الإصدار الأصلي على + و = بداخله وتلقيت الخطأ SignatureDoesNotMatch عند محاولة إرسال ملفات cp إلى s3. لقد قمت بإعادة إنشاء المفاتيح وأصبح سري الجديد الآن سلسلة أبجدية رقمية. مجرد إضافة تأكيد آخر على أن التجديد يعمل. :مرتاح:

على أمل أن يوفر ذلك نظرة ثاقبة ، فإن هذه المشكلة (عدم التعامل مع + في مفاتيح سرية) تكشف نفسها مع هذا الإصدار على RHEL5

aws-cli/1.15.25 Python/3.4.7 Linux/3.2.45-0.6.wd.865.49.315.metal1.x86_64 botocore/1.10.25

لكن لا يحدث مع هذا الإصدار على Ubuntu

aws-cli/1.11.13 Python/3.5.2 Linux/4.4.0-121-generic botocore/1.4.70

بدأت في يناير 2014 والآن يونيو 2018 ، أكثر من 4 سنوات وواجهت نفس المشكلة مع خطأ SignatureDoesNotMatch . كان الحل بالنسبة لي هو نفسه مثل جميع حلول الأغلبية هنا ، احصل على مفتاح سري جديد بدون أي حرف خاص بالنسبة لمفتاحي السابق الذي يحتوي على نقطتين : ، جرب مزامنة الوقت ، لكن لا يعمل من أجلي. أنا أستخدم WSL.

aws-cli/1.15.27 Python/3.6.5 Linux/4.4.0-17134-Microsoft botocore/1.10.27

مجرد تحديث ما قاله gchiu في أبريل 2017: لا يزال الحال في يونيو 2018 هو أن الأسرار التي تحتوي على حرف

لقد شعرت بالحيرة من هذا لمدة 30 دقيقة.

اتبعت هذه المشكلة وفحص التوقيت المحلي ، وما إلى ذلك - كان كل شيء جيدًا.

في حالة اليأس ، تم تفجير الملف ~/.aws/credentials وتسجيل الدخول مرة أخرى (بشكل أساسي إعادة إنشاء الملف) وفويلا ، تعمل فقط.

أتساءل لماذا يلقي هذا الخطأ على الإطلاق!

تعديل:
لا يبدو أنه مرتبط بالمفتاح السري في حالتي ؛ كانوا جميعًا سلاسل بسيطة في الغالب.

+1 في هذه المشكلة ، بدأ مفتاحي بـ = . تم إعادة إنشاء مفتاح لم يكن به سوى / وكان كل شيء على ما يرام. حاولت تغليف المفتاح بعلامات " ، لكن دون جدوى.

ليس شيئًا أتوقع رؤيته من AWS CLI.

إضافة إلى نفس المشكلة هنا ، لا أستطيع أن أصدق أن / في مفتاحي قد تسبب في ذلك. شكرا على الوقت الضائع!

كانت لدي هذه المشكلة. أعتقد أنه كان نتيجة التثبيت المبدئي لـ aws cli كمستخدم أساسي. يبدو أن الدقة تقوم بإلغاء تثبيت aws cli ، وحذف كل من مجلد .aws في المجلد الرئيسي للمستخدم الحالي وكذلك في المجلد الجذر ، ثم تشغيل "aws config" مرة أخرى كمستخدم حالي.

لقد واجهت هذه المشكلة عند تشغيل برنامج نصي bash باستخدام مؤقت systemd على Ubuntu. عند تشغيل البرنامج النصي يدويًا مع المستخدم الخاص بي ، كان كل شيء يعمل بشكل جيد. ومع ذلك ، سيستمر الموقت في إلقاء الخطأ (SignatureDoesNotMatch). لاحظت بعد ذلك أنه تم إنتاج (SignatureDoesNotMatch) لأي أمر aws يعمل كجذر وأن "aws config" لم يحفظ القيم الجديدة المقدمة.

لحل المشكلة ، قمت بتسجيل الدخول بصفتي جذر 'su -i' ، وتغيرت إلى 'cd ~ / .aws /' وأزلت التكوين باستخدام 'sudo rm -r documentsentials' ، وقمت بتشغيل 'aws config' مرة أخرى وهذه المرة القيم الجديدة تم حفظه. من هناك كل شيء يعمل مرة أخرى كما هو متوقع!

يمكن تأكيد أن هذه المشكلة لا تزال موجودة في aws-cli / 1.15.4 Python / 2.7.15rc1 Linux / 4.15.0-42-generic botocore / 1.12.8.

An error occurred (SignatureDoesNotMatch) when calling the <whatever> operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

واتضح أنه كان هناك + في سري. لقد تجددت وكل شيء على ما يرام الآن. متى نتوقع إصلاحًا لهذاjamesls؟ أو هل هناك أي شيء يمكنني القيام به للمساعدة؟

واجهت نفس الشيء على aws cli لأن المفتاح السري كان يحتوي على + ... (كما هو موضح أعلاه) بعد إعادة إنشاء مفتاح جديد .. (كما رأيت من تعليق delmartechdude أعلاه) .... المشكلة تم حلها.

سنتى. لقد كان يعطيني هذا الخطأ لأنني كنت أحاول تحميل المحتوى إلى s3 مع عمليات النقل المتسارعة بهذه الطريقة (كان يعمل في الماضي): --endpoint-url http://imaat.s3-accelerate.amazonaws.com ( --endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com ) كما هو محدد في خصائص نقطة نهاية التسريع :

اتباع التعليمات في المستندات الرسمية: https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html لقد استبدلت الجزء الأخير بـ: --endpoint-url http://s3-accelerate.amazonaws.com وقم بتشغيل الأمر aws configure set s3.addressing_style virtual لبناء اسم المضيف ديناميكيًا. تحقق: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing -style

لا أعرف لماذا ، لكنه يعمل الآن. لا يحتوي اسم المستودع الخاص بي ("imaat") على أي طابع خاص قد يؤدي إلى فشل DNS ، ولكنه فشل لسبب ما مع آخر تحديثات cli.

إضافة ملف تعريف عن طريق تحرير النص وحصلت على هذا الفشل. تحديث معرف الوصول إلى الملف الشخصي والسرية عبر مجموعة تكوين aws وعملت. هذا من أجل سر بداخله "+" و

@ dave-miles أنت في طريقك إلى شيء ما ، شكرًا لك على التعليق! أنا أتوسع في اكتشافك أدناه:

واجهت هذه المشكلة مع بعض صور عامل ميناء. في الأصل كنت أستخدم إضافة في ملف عامل التحميل لإضافة ملف ~ / .aws / أوراق الاعتماد في الحاوية.

إذا فعلنا ذلك ، فسنواجه خطأ SignatureDoesNotMatch عند محاولة التنزيل من s3.

لقد أزلت خط ADD في ملف dockerfile ، وأعدت بناء حاوية جديدة لرسو السفن وأطلقتها. في هذه الحاوية الجديدة ، قمت بتشغيل aws configure set aws_access_key_id <access key id goes here> و aws configure set aws_secret_access_key <secret access key goes here> يدويًا. كانت هذه هي المرة الأولى التي أدخل فيها معلومات بيانات الاعتماد في هذه الحاوية (على سبيل المثال ، كانت الحاوية عبارة عن صورة centos "حديثة").

بعد استخدام أوامر aws configure set ، تمكنت من التنزيل بنجاح من s3.

بالنسبة لأي شخص يستخدم هذا مع ملف dockerfile ، يمكنك استخدام عبارات RUN في ملف dockerfile لتشغيل الأمرين أو يمكنك استخدام عبارة ADD لدفع برنامج نصي إلى حاوية عامل الإرساء:

#! / بن / ش

تعيين aws تكوين aws_access_key_id _access-key-id-go-here_
تعيين aws تكوين aws_secret_access_key _secret-access-key-go-here_

واجهت نفس مشكلة villasenor - قد + في المفتاح السري في حدوث الخطأ عند تكوين awscli باستخدام env vars في docker. تدوير المفاتيح حل المشكلة.

كما سبق هنا ، ولكن لا توجد أحرف خاصة في مفتاح الوصول أو المفتاح السري.
تم إعادة إنشاء مجموعة جديدة لنفس مستخدم IAM ، ويمكن للمستخدمين الجدد سرد المجموعات ، أما القديمة فلا يمكنها ذلك.

حدث هذا مع مكالمات AWS cli و Java SDK. الإيحاء بأن الخطأ ليس في العملاء ...

كلا المجموعتين لا تزال حية. إذا أراد أي شخص في أمازون مزيدًا من التفاصيل ، فيرجى الاتصال به.

واجه زميلي في العمل هذا أيضًا. حاولت تصحيح الأخطاء عن طريق إنشاء مفتاح وصول إلى أن حصلت على واحد بعلامة + أو / في البداية. لم يكن قادرا على التوبيخ رغم ذلك.

كان لدي زميل في العمل تجربة هذا. لقد قررنا أن هذا يحدث على وجه التحديد Ubuntu 18.04 مع + أو / في المفتاح السري.

حصلت على نفس الخطأ اليوم ، باستخدام Windows 10. ومع ذلك ، عندما أستخدم نفس مفتاح الوصول على كمبيوتر محمول آخر (Mac) ، فإنه يعمل بشكل جيد بالنسبة لي. ثم جربت مفتاح الوصول داخل WSL ، وهو أمر جيد أيضًا. لست متأكدًا من السبب ، ولا يوجد حرف خاص في مفتاح aws.

أواجه هذا الخطأ مع مجموعة واحدة من مفاتيح الوصول وليس الأخرى.
كما هو مذكور في العديد من الوظائف الأخرى هنا ، المفتاح الخاص بي كـ "/" فيه. بالنسبة لي ، تبدو هذه المشكلة وكأنها مشكلة بسيطة تتعلق إما بالخادم أو العملاء بتشفير / فك التشفير باستخدام معيار ترميز RFC URI والآخر لا يستخدمه.
أخطط لتشغيل نصوص الاختبار المذكورة ومحاولة إعادة إنتاج الأخطاء.

لأشخاص آخرين هنا ، واجهت الخطأ ، لكن كان لدي بيانات اعتماد غير صحيحة مخزنة مؤقتًا في مجلد ~ / .aws. يبدو هناك أولاً وإلى متغيرات البيئة ثانيًا.

أواجه هذا على Windows 10 باستخدام Git Bash. إنه يعمل بشكل جيد مع Powershell. استدعاء بايثون مختلف ، لكنه نفس وحدة بايثون وبايثون. لدي أيضًا + و / في مفتاحي.

لقد واجهت هذه المشكلة للتو وبالنسبة لي ، كان الإصلاح هو إزالة المسافات. مثال.
بدلاً من الافتراضي:
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
لقد غيرتها إلى:
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

لاحظ عدم وجود مسافات حول =. هذا تم إصلاحه بالنسبة لي ولدي + و / في مفتاحي أيضًا.

الكل ، هناك بعض النصائح الرائعة حول استكشاف الأخطاء وإصلاحها هنا. سأقوم بتحويلها إلى صفحة في قسم استكشاف الأخطاء وإصلاحها في دليل مستخدمي CLI. شكرا على المساهمات!

أهلا بكم،

أستطيع أن أرى أن هناك الكثير من الإجابات هنا ، ولكن بالنسبة لي كانت تلك هي الأحرف الخاصة في مفتاح الوصول السري لـ AWS. لقد بدأت بـ "= +" ، ولكن عندما أنشأت واحدة جديدة بدون أحرف خاصة من وحدة تحكم الويب ، بدأت تعمل على الفور.

أنا أقوم بتشغيل awscli في قذيفة Zsh على Ubuntu على Windows:

jonathan<strong i="8">@SurfaceBook</strong>  ~  aws --version aws-cli/1.16.216 Python/2.7.12 Linux/4.4.0-17134-Microsoft botocore/1.12.206

آمل أن يكون هذا مفيدًا للآخرين.

شكرا
جوناثان

غرق للتو 4 ساعات من التصحيح في هذا حتى وجدت هذا الموضوع. يمكنني استخدام s3 cli محليًا دون أي مشاكل ، ولكن عند تشغيلها في circleci حصلت على هذا الخطأ: SignatureDoesNotMatch ..

كما اقترح آخرون ، احتوى مفتاح الوصول السري الخاص بي على حرف + ، وبعد إنشاء مفتاح جديد ، بدأ كل شيء في العمل.

يكاد يكون من المستحيل تصحيح الأخطاء بدون هذا الموضوع

شكرا blbradley . كانت بالضبط المشكلة التي لدي.

نفس المشكلة - كان الحل هو حذف متغيرات بيئة Windows ببيانات اعتماد AWS قديمة

واجهت مشكلة أيضًا في Python3 boto3.
يبدأ المنجم بـ =/

أنا في جهاز افتراضي يجعل الوقت والمنطقة المضيفة مشابهًا لوقت الضيف والمنطقة يحل المشكلة.

أردت فقط أن أتحدث عن هذا الأمر الذي أصابني اليوم أيضًا على مفتاح تم إنشاؤه حديثًا - وبعد الكثير من الإحباط ، هبطت هنا ورأيت إشارة إلى / في المفتاح. من المؤكد أن هذه كانت المشكلة - المفتاح الجديد بدونه يعمل. ماهذا الهراء؟!

لا أستطيع أن أصدق أن هذه المشكلة قد تم فتحها في عام 2014 وما زلت لا يوجد حل لها ، أجبرني هذا الخطأ على إنشاء مجموعة جديدة من بيانات اعتماد AWS لنفسي ، حتى أنني حاولت ترميز '/' لكنها لم تنجح:

إزالة بيانات الاعتماد مع "/" إصلاح المشكلة بالنسبة لي. شكرا للجميع على الإشارة إلى هذا.

فقط اضغط على هذا في عام 2020 الآن. يحتوي المفتاح السري على علامة "+".

aws-cli - تم تطويره بواسطة مشروع aws - فشل مع مفاتيح aws صالحة ... لمدة 6 سنوات؟

نفس المشكلة في 2020 يناير. المفتاح السري له حرف "/" مائل.

لقد قمت بإنشاء مجموعة بيانات اعتماد جديدة ، باستخدام وحدة تحكم AWS IAM ، وتأكدت من أن المفتاح السري كله أبجدي رقمي ، لا "/" لا "+" وما إلى ذلك. لقد استبدلت مفتاحي السري القديم بالمفتاح السري الجديد ، في ملف بيانات الاعتماد ~ / .aws / ، ثم أعدت المحاولة.

هذا حلها.

نفس المشكلة هنا في 2020. لكن لا يمكنني إزالة أي أحرف أبجدية رقمية لأنها جزء من بيانات الاعتماد الخاصة بي ، ولست متحكمًا في ذلك

ما عليك سوى إعادة إنشاء بيانات الاعتماد حتى تتخلص من الشخصيات. وعادة ما يستغرق الأمر محاولة واحدة أو اثنتين فقط.

موريس

من: columb1a [email protected]
تاريخ الإرسال: الثلاثاء ، 21 يناير 2020 ، الساعة 1:47 مساءً
إلى: aws / aws- cli [email protected]
نسخة إلى: Maurice Bizzarri [email protected] ؛ التعليق [email protected]
الموضوع: Re: [aws / aws-cli] خطأ SignatureDoesNotMatch (# 602)

نفس المشكلة هنا في 2020. لكن لا يمكنني إزالة أي أحرف أبجدية رقمية لأنها جزء من بيانات الاعتماد الخاصة بي ، ولست متحكمًا في ذلك

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً ، وقم بعرضه على GitHub https://nam04.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Faws٪2Faws-cli٪2Fissues٪2F602٪3Femail_source٪3Dnotifications ٪ 26email_token٪ 3DAAAXXM3CF63PVTWMVHJN2FTQ65UMRA5CNFSM4ALOPGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRMFFA٪ 23issuecomment-576897684 والبيانات = 02٪ 7C01٪ 7Cmaurice٪ 40bizzarrisoftware.com٪ 7Cf6f2e8a571954134b76b08d79ebb6bee٪ 7C9aa15552370449f5ac56c2850c165d32٪ 7C1٪ 7C0٪ 7C637152400117352225 وsdata = 2Z6PQRSvKD0P8Eu0yrs15Ypi6GgtFvaDi7qewAq5yH4٪ 3D & محفوظة = 0 ، أو إلغاء الاشتراك https://nam04.safelinks.protection.outlook.com /؟url=https٪3A٪2F٪2Fgithub.com٪2Fnotifications٪2Funsubscribe-auth٪2FAAAXXM34MIXB32H3RMQL2FTQ65UMRANCNFSM4ALOPGLQ&data=02٪7C01٪7Cmaurice٪40bizzarrisoftware.com٪7Cf6f2e8a571954134b76b08d79ebb6bee٪7C9aa15552370449f5ac56c2850c165d32٪7C1٪7C0٪7C637152400117362212&sdata=53٪2F78BXqn3FRxlkfzXYHnJPEEbs7Ta1XmJhW٪2BZdBjXo٪3D&reserved= 0 .

واجهت مشكلات انتهاء المهلة أولاً وبعد تحديث واجهت أوسكلي هذه المشكلة. كنت تعتقد أن 6 سنوات كافية لإنجاحها ...

لدي أيضًا تطبيق Vue.js للنشر من خلال gitlab إلى حاوية AWS S3 ، هل يمكن لشخص ما أن يخبرني بما يجب فعله
msg: خطأ

لم يكن لدي أي أحرف غير أبجدية رقمية ، لكن العمل مع ملف التعريف لم ينجح ، لملف تعريف واحد. لقد قمت بإعادة إنشاء بيانات الاعتماد باستخدام وحدة التحكم وعملت الجديدة للتو.

الحصول على مثل هذه الأخطاء اليوم أيضًا ، وإعادة إنشاء بيانات الاعتماد بدون أحرف خاصة ("+" أو "/") يعمل بالنسبة لي.

ما زلت أعاني من نفس المشكلة ، لكنها تحدث فجأة ، فأنا أعمل مع عمليات Get and Put وأحدهما يعمل والآخر لا يعمل. ونعم ، لا يحتوي مفتاحي السري على أي أحرف خاصة. أي مساعدة؟ اتصل أولاً بـ getIntent (واجهة برمجة تطبيقات amazon lex Models) لاسترداد المجموع الاختباري لل intents ، ثم اتصل بـ putIntent لتحديث تلك النية. تعمل طريقة Get (ليس طوال الوقت) ولكن طريقة put تظهر نفس مشكلة التوقيع ، بينما إذا قمت بإزالة Get method API من الكود ، فإن طريقة Put تعمل مرتين من أصل ثلاث مرات.

واجهت هذه المشكلة ، أقترح عليك إنشاء مفاتيح جديدة
وإعادة تكوين ملف تعريف AWS الخاص بك

تكوين AWS

معرف مفتاح الوصول إلى AWS [ * * * * QD5E]: AWS_ACCESS_KEY_ID
مفتاح الوصول السري لـ AWS [ * * * * ANjA]: AWS_SECRET_ACCESS_KEY
اسم المنطقة الافتراضي [eu-west-3]: AWS_REGION
تنسيق الإخراج الافتراضي [json]: OUTPUT_FORMAT

مرحبا !

أواجه هذه المشكلة نفسها عند استخدام عنوان URL موقّع مسبقًا يتم إرجاعه إلى موكلي
يتم إنشاء عنوان URL في الخادم (لفترة محدودة). الخادم هو python ولا أرى أي خطأ هناك ، لكن العميل هو JS - يحصل فقط على عنوان URL ويفتحه. يتم إنشاء بيانات اعتماد لهذا المورد جزء من عنوان URL)

الخطأ قيد التشغيل والإيقاف ، لذلك أعتقد أنه مرتبط بما يقال هنا حول المفاتيح الخاصة في بيانات الاعتماد ، ولكن نظرًا لأنني أستخدم بيانات الاعتماد التي تم إنشاؤها في الخادم - لا يمكنني تغييرها!

أي طريقة لرعاية هذا في الكود؟ تحليل المفاتيح الخاصة بطريقة أو بأخرى؟

مرحبا !

أواجه هذه المشكلة نفسها عند استخدام عنوان URL موقّع مسبقًا يتم إرجاعه إلى موكلي
يتم إنشاء عنوان URL في الخادم (لفترة محدودة). الخادم هو python ولا أرى أي خطأ هناك ، لكن العميل هو JS - يحصل فقط على عنوان URL ويفتحه. يتم إنشاء بيانات اعتماد لهذا المورد جزء من عنوان URL)

الخطأ قيد التشغيل والإيقاف ، لذلك أعتقد أنه مرتبط بما يقال هنا حول المفاتيح الخاصة في بيانات الاعتماد ، ولكن نظرًا لأنني أستخدم بيانات الاعتماد التي تم إنشاؤها في الخادم - لا يمكنني تغييرها!

أي طريقة لرعاية هذا في الكود؟ تحليل المفاتيح الخاصة بطريقة أو بأخرى؟

@ maya-harel ، يمكنك تغيير بيانات الاعتماد من IAM -> يختار المستخدمون المستخدم الذي قمت بإنشائه وإعادة إنشاء علامة تبويب بيانات اعتماد أمان المفتاح السري.

كما أن التوقيت في الكود أمر فادح حقًا ، فبالنسبة لكل طلب تقدمه في النهاية الخلفية ، احصل على الوقت الحالي لاستخدامه في العنوان لإنشاء التوقيع.

جانبا ، كان هناك الكثير من اقتراحات "تجديد بيانات اعتماد IAM" العمياء للمستخدمين الذين قالوا صراحةً إنه ليس خيارًا لهم.

هذا ليس مفيدًا للمستخدمين ، ويصرف الانتباه عن حقيقة أن هذا خطأ معروف يستمر في التأثير على مستخدمي aws-cli الذين يحاولون استخدام بيانات اعتماد IAM صالحة.

يجري في هذا أيضا.
$ aws - الإصدار
aws-cli / 1.16.300 Python / 2.7.16 Linux / 4.14.152-127.182.amzn2.x86_64 botocore / 1.13.36

مفاتيحي هي أبجدية رقمية بالكامل ، ولا توجد أحرف خاصة.

تعمل المفاتيح من الغلاف ، ولكن عند استخدامها عبر Jenkins في هدف Makefile ، يحدث هذا الخطأ. لست متأكدا مما يحدث هنا.

مفتاحي السري يحتوي على كل من / و + بداخله. واجهت هذه المشكلة وحاولت:

• Trough aws-cli > aws iam get-user (باستخدام ملف ~/.aws/credentials )
• boto3 (من خلال python 3.6.8)
  
  
  
  • مفاتيح مشفرة
  
  
  • متغير البيئة
  
  
  • الوسيطة boto3.Session(profile_name=PROFILE) (التي تسحب من ~ / .aws / أوراق الاعتماد)
  
  

كل هذه النتائج تؤدي إلى الخطأ SignatureDoesNotMatch .

لا يمكنني حاليًا إعادة إنشاء المفتاح.

ما لا أفهمه هو أنه يمكنني استخدام بروتوكول S3 في Cyberduck (https://cyberduck.io/) ويعمل كما هو متوقع. كيف يمكن لذلك ان يحدث؟

يجب أن يكون هذا أحد أكثر الأخطاء المحبطة التي واجهتها ولم يتم إصلاحها. الحصول على رصيد بدون علامة "+" كان مفيدًا بالنسبة لي في CircleCI.

هل ما زالت تتحطم؟ أواجه نفس المشكلة ، واو لا يمكنني أن أكون ممكناً ...

نعم ، إنه محبط. مفتاحي السري الذي كان يحتوي على + لم يعمل في خط أنابيب Jenkins ، لكن عندما أنشأت مفتاحًا جديدًا ، والذي كان يحتوي على القليل من / ، كان يعمل بشكل جيد.

واجهت هذه المشكلة في إصدار الحزمة المثبت من awscli على Ubuntu 16.04. لقد أصلحته عن طريق تثبيت awscli كحزمة بيثون بيب.
للحصول على التعليمات ، اتبع هذا الرابط الموجود أسفل قسم تثبيت AWS CLI باستخدام Python PIP

_ تمت مواجهة المشكلة _

1) تمت مواجهة خطأ InvalidSignatureException بعد إعادة إنشاء مفتاح الوصول
2) سجل الخطأ الجزئي كما هو موضح أدناه.

بيثون $
Traceback (آخر مكالمة أخيرة):
ملف "SetupAWS.py" ، السطر 222 ، بتنسيق
list_things ()
ملف "SetupAWS.py" ، السطر 182 ، في list_things
الأشياء = client.list_things () ['Things']
ملف "c: Program Files (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py" ، السطر 316 ، في _api_call
إرجاع self._make_api_call (اسم_عملية ، kwargs)
ملف "c: Program Files (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py" ، السطر 626 ، في _make_api_call
رفع error_class (parsed_response، operation_name)
botocore.exceptions.ClientError: حدث خطأ (InvalidSignatureException) عند استدعاء عملية ListThings: توقيع الطلب الذي حسبناه لا يتطابق مع التوقيع الذي قدمته. تحقق من مفتاح AWS Secret Access وطريقة التوقيع. راجع وثائق الخدمة للحصول على التفاصيل.

_ تحليل السبب الجذري _

1) كما اقترح الكثيرون في تعليقاتهم أعلاه ، أدى وجود "+" في مفتاح الوصول السري الخاص بي إلى الخطأ أعلاه.

_ القرار _

1) إنشاء مفتاح وصول جديد كمستخدم IAM والتحقق من أن مفتاح الوصول السري الجديد لا يحتوي على علامة "+" داخل السلسلة.
2) شغّل أمر
3) شغّل أمر

بيثون $
[{'thingName': 'myThingName'، 'thingArn': 'myThingArn'، 'attributes': {}، 'version': 1}]

هذا العدد مفتوح منذ ست سنوات ، وأشكركم على صبركم ومثابرتكم والمعلومات التي قدمتموها. تم تحديد بعض الأسباب الأساسية من خلال تعليقاتك (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) وتم تجميعها في فصل استكشاف الأخطاء وإصلاحها بدليل مستخدم سطر الأوامر. تتضمن هذه الأسباب انحراف الساعة وإساءة استخدام بعض أنظمة التشغيل للمفاتيح ذات الأحرف الخاصة.

حاولت إعادة إنتاج هذا باستخدام عدد من البيئات المختلفة. لقد استخدمت Ubuntu 16.04 و Ubuntu 18.04 و Amazon Linux 2 مع Python 3.6.8 و 3.8.3. بينما استخدم العديد من المعلقين Python 2 ، لم أحاول إعادة الإنتاج لأنه لم يعد مدعومًا. لقد استخدمت الإصدار الأحدث v1 aws-cli (1.18.80 وقت كتابة هذا التقرير) بالإضافة إلى إصدار أقدم (1.11.78) مُشار إليه في هذه المشكلة. لقد استخدمت البرنامج النصي المقدم (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) بواسطة jamesls الذي ينشئ أزواج اعتماد جديدة حتى يواجه واحدًا بأحرف خاصة ويسمح لهم بالعمل لمدة تصل إلى ساعة لكل منهما. لم يكن لدي أي تكرار لخطأ SignatureDoesNotMatch . تلقيت أحيانًا أخطاء AuthFailure في أمر وصف المثيلات ، ولكن نجحت إعادة محاولة الأمر بنفس بيانات الاعتماد.

العدد الكبير من التعليقات يجعل من الصعب على المستخدمين الجدد الذين يتعاملون مع هذه المشكلة العثور على طلبات من فريق المطورين لدينا لاقتراحات استكشاف الأخطاء وإصلاحها. لمساعدة فريقنا والمجتمع في تحديد سبب هذا الخطأ ، أقوم بإغلاق هذه المشكلة وإنشاء نموذج معين لمشكلة GitHub يتضمن متطلبات التوجيه والتعليق للمستخدمين الذين يواجهون هذا الخطأ.

إذا واجهت هذا الخطأ ، يرجى التوجه إلى علامة التبويب "المشكلات" ، والنقر فوق الزر "مشكلة جديدة" ، واستخدام النموذج لتقرير الخطأ SignatureDoesNotMatch (أو استخدم الرابط أدناه).

نظرًا لاختلاف بيئات المستخدم حيث يحدث هذا الخطأ ، يرجى تقديم مشكلة منفصلة بدلاً من التعليق على مشكلة موجودة.

انقر هنا لتقديم تقرير خطأ SignatureDoesNotMatch