Powershell: برنامج ConvertFrom-SecureString معطل في Linux

تم إنشاؤها على ٥ أغسطس ٢٠١٦  ·  62تعليقات  ·  مصدر: PowerShell/PowerShell

خطوات التكاثر

  1. قم بتثبيت PowerShell على Ubuntu 14.04
  2. قم بتشغيل PowerShell
  3. قم بتشغيل ما يلي:
   $password = Convertto-Securestring -String "PowerShellRocks!" -AsPlainText -Force
   ConvertFrom-SecureString $password  

سلوك متوقع

لا خطأ

السلوك الفعلي

تم طرح الخطأ التالي

PS /home/chythu/temp> ConvertFrom-SecureString $password                        ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified
module could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:1
- ConvertFrom-SecureString $password
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  - CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], Dl
    lNotFoundException
  - FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell
    .Commands.ConvertFromSecureStringCommand

بيانات البيئة

Name                           Value
---
PSVersion                      5.1.10032.0
PSEdition                      PowerShellCore
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.7
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

تحديثات بواسطة @ travisez13 في 2016-04-10

بيانات البيئة

> $PSVersionTable
Name                           Value                                           
----                           -----                                           
PSVersion                      6.0.2                                           
PSEdition                      Core                                            
GitCommitId                    v6.0.2                                          
OS                             Darwin 17.5.0 Darwin Kernel Version 17.5.0: M...
Platform                       Unix                                            
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                         
PSRemotingProtocolVersion      2.3                                             
SerializationVersion           1.1.0.1                                         
WSManStackVersion              3.0                                             


الحل

الأعمال التالية
`` بوويرشيل

يجب عليك إنشاء مفتاحك الخاص

المفتاح $ = (3،4،2،3،56،34،254،222،1،1،2،23،42،54،33،233،1،34،2،7،6،5،35،43)
$ s | ConvertFrom-SecureString -Key $ Key
""

Area-Cmdlets Issue-Bug OS-Linux OS-macOS Resolution-Fixed

التعليق الأكثر فائدة

خلاصة القول هي أن .NET framework (و PowerShell) يحتاجان إلى مكتبة حماية البيانات عبر الأنظمة الأساسية ، لأن dev / ops بحاجة إلى تخزين الأسرار لم تختف فجأة عندما أضفنا أنظمة تشغيل جديدة إلى المزيج ، وهي ليست عملية دائمًا للاعتماد على خدمات الويب مثل Azure KeyVault أو RED Identity management أو Thycotic Secret Server. 😕

يبدو أن فريق .NET لا يميل إلى أن يكون مفيدًا بشكل خاص هنا.

أعلم أن ASP.NET كتب عناصر حماية البيانات الخاصة بهم ، لكنه غريب إلى حد ما ويوصون بقصر استخدامه على سيناريوهات محددة ...

ما نحتاج إلى معرفته هو:

هل يخطط فريق PowerShell لإنشاء تنفيذ عبر الأنظمة الأساسية لتسلسل SecureString؟

إذا لم يكن الأمر كذلك ، فالرجاء إزالة أوامر cmdlets التي لا تعمل على الإطلاق ، وتقديم رسالة خطأ أفضل لـ CliXML من الرسالة الحالية ، "يا رتق ، إذا كان هناك خطأ Crypto dll متاح فقط".

ال 62 كومينتر

Talked @ KrishnaV-MSFT هذا ليس ضروريًا لعرض Azure. إخراجها من ألفا 10

صادف نفس الخطأ على MacOS 10.12 Beta (16A270f)

كان مجرد العبث هنا:

PS> $User="Jared"
PS> $PWord = ConvertTo-SecureString –String "TestString" –AsPlainText -Force   
PS> $Cred = New-Object -TypeName "System.Management.Automation.PSCredential" –ArgumentList $User, $PWord
PS> ConvertFrom-SecureString -SecureString ($Cred.Password)

نتيجة:

ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:1
+ ConvertFrom-SecureString -SecureString ($Cred.Password)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringComman

مرحبا،

نفس خطأ المكتبة عند محاولة استخدام الشهادة المعينة: psdrive:

Get-ChildItem Cert:/LocalMachine/

خطأ:

get-childitem: تعذر تحميل DLL 'crypt32.dll': تعذر العثور على الوحدة النمطية المحددة.
(استثناء من HRESULT: 0x8007007E)
في السطر: 1 حرف: 1

  • شهادة get-childitem: / LocalMachine /
  • ~ ~ ~ ~ ~ ~ ~~~

    • CategoryInfo: NotSpecified: (:) [Get-ChildItem] ، DllNotFoundException

    • FullyQualifiedErrorId: System.DllNotFoundException ، Microsoft.PowerShell.Commands.GetChildItemCommand

@ 35359595 نتائج جيدة! يجب أن يكون الخطأ بالتأكيد أكثر ودا. في نظامي Linux و macOS ، يحتاج الموفر Cert:/ إلى بعض إعادة التفكير. تختلف الطريقة التي يتبعها هذان النظامان في تخزين الشهادات تمامًا عن بعضها البعض عن النوافذ.

لمعلوماتك ، 16.04.1 مع PowerShell v6 alpha 14 لا يزال لديه نفس المشكلة

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

هذا شيء سنكون قادرين فقط على تمكينه مع .NET Standard 2.0 APIs التي تعيد SecureString:

  • مشكلة CoreFX: dotnet / corefx # 13062
  • CoreFX 2.0 PR: dotnet / corefx # 13362

يعتمد ConvertFrom-SecureString و ConvertTo-SecureString على System.Security.Cryptography.ProtectedData ، والذي لا يزال غير متوفر في netstandard2.0 .
لذلك يجب إعادة عمل أوامر cmdlets هذه على منصات Unix.

سأكون ممتنًا حقًا إذا وصلت هذه الوظيفة إلى .Net Core
نحن نعتمد على WinRM ونستخدم PSCredential للمصادقة. إن تشغيل البرامج النصية الخاصة بنا على Linux أو MacOS غير ممكن في الوقت الحالي وهو يعيقنا قليلاً.

خطأ نراه:
ConvertTo-SecureString: تعذر تحميل DLL 'CRYPT32.dll': تعذر العثور على الوحدة النمطية المحددة.
(استثناء من HRESULT: 0x8007007E)

@ reddwarf666 الحزمة System.Security.Cryptography.ProtectedData متوفرة على nuget.org وهي شكوى netstandard2.0 ، ومع ذلك ، لا يوجد بها تطبيق لمنصات Unix - ستطرح "PlatformNotSupportedException" على منصات Unix. لذا يجب إعادة كتابة ConvertFrom/ConvertTo-SecureString ليونيكس. سنحاول الحصول على بعض التوجيهات من فريق .NET Core حول كيفية القيام بنفس المهام على Unix. / ccjoeyaiello

هل من المحتمل أن تأتي [System.Runtime.InteropServices.Marshal] :: SecureStringToBSTR و [System.Runtime.InteropServices.Marshal] :: PtrToStringAuto في الرحلة؟

لا تزال ترى هذا على 6.0.0-beta3 على نظامي التشغيل Mac و Linux عند استخدام أوامر cmdlets لـ SecureString

ConvertFrom-SecureString: تعذر تحميل DLL 'CRYPT32.dll': الملف المحدد
لا يمكن العثور على الوحدة النمطية أو إحدى تبعياتها.
(استثناء من HRESULT: 0x8007007E)

نفس الشيء هنا مع convertfrom-securestring و convert to-securestring (v6.0.0-beta.3) على linux debian (jessie 64bit):

PS /> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
GitCommitId                    v6.0.0-beta.3
OS                             Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS />

PS /> read-host -assecurestring | convertfrom-securestring | out-file securestring.txt
********
convertfrom-securestring : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:29
+ read-host -assecurestring | convertfrom-securestring | out-file secur ...
+                             ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand



md5-0a78a142751a1081c46c48e10b6cba93



PS /> $pass = cat securestring.txt | convertto-securestring
convertto-securestring : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:32
+ $pass = cat securestring.txt | convertto-securestring
+                                ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertTo-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertToSecureStringCommand



md5-25ce90db07e4f9f61b58abd5cf739027



PS /> [Reflection.Assembly]::LoadFrom("CRYPT32.dll")
Exception calling "LoadFrom" with "1" argument(s): "Bad IL format."
At line:1 char:1
+ [Reflection.Assembly]::LoadFrom("CRYPT32.dll")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : BadImageFormatException



md5-0a78a142751a1081c46c48e10b6cba93



PS /> Add-Type -Path 'CRYPT32.dll'
Add-Type : Bad IL format.
At line:1 char:1
+ Add-Type -Path 'CRYPT32.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-Type], BadImageFormatException
    + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.AddTypeCommand

النسخ إلى /opt/microsoft/powershell/6.0.0-beta.3/ وأيضًا عند تحديد المسار المطلق ، يعطي نفس الخطأ المذكور أعلاه.

هل هناك حل بديل ممكن / معروف أم علينا الانتظار حتى يتم إصلاح ذلك؟

vchrizz Windows و Unix غير متوافقين مع النظام الثنائي ولا يمكننا استخدام Windows dll على نظام Unix. لذلك يجب أن ننتظر CoreFX.

iSazonov أنا على علم بهذا ، كنت أتساءل بسبب ملفات dll هذه الموجودة في /opt/microsoft/powershell/6.0.0-beta.3/ ولكن بعد ذلك اكتشفت:
ملفات linux .dll:
"PE32 القابل للتنفيذ (DLL) (وحدة التحكم) Intel 80386 Mono / .Net التجمع ، لـ MS Windows"
"PE32 + قابل للتنفيذ (DLL) (وحدة التحكم) Mono / .Net التجمع ، لنظام التشغيل MS Windows"
ملف windows CRYPT32.dll:
"PE32 القابل للتنفيذ (DLL) (GUI) Intel 80386 ، لـ MS Windows"

الآن تبحث عن حل ووجدت نفس المشكلة مع Export-Clixml:

PS /> $cred=Get-Credential –credential "myuser" | Export-Clixml SecureCredentials.xml

Windows PowerShell credential request
Enter your credentials.
Password for user myuser: **********

Export-Clixml : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:45
+ ... Credential –credential "myuser" | Export-Clixml SecureCredentials.xml
+                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Export-Clixml], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ExportClixmlCommand

vchrizz حاليًا يضع .Net CLI جميع التجميعات في حزم Unix. # 3961 تتبع عبوات Unix.

@ daxian-dbw يمكننا استخدام OpenSSH لحماية / إلغاء حماية البيانات.

أفضل ألا نفعل شيئًا مخصصًا لغير Windows. يبدو أن فريق Nuget يطلب هذا أيضًا.

@ SteveL-MSFT ، يمكن أن يؤكد أن فريق nuget يحتاجها (NuGet / Home # 1851) ، لأنني كنت من نشأ معهم كوظيفة مفقودة

@ SteveL- MSFTpsmulovics يبدو أن فريق CoreFX لا يتتبع القضايا المغلقة على الإطلاق - أعتقد أنه يجب علينا فتح إصدار جديد هناك إذا أردنا أي تقدم.

تم إنشاء عدد جديد https://github.com/dotnet/corefx/issues/22510

انها عملت! 😄 الآن لدينا إجابة:

ليس لدينا خطط للقيام بذلك. يتطلب ميزات نظام التشغيل المتوفرة فقط على Windows.
..
ما لدينا في .NET Core واضح. على نظام التشغيل Windows ، يقوم بكل ما يفعله DPAPI. على غير نظام التشغيل Windows ، يقوم بما يفعله Windows DPAPI على تلك الأنظمة الأساسية: غير موجود.

لذلك يجب أن نستنتج:

  1. استخدم الحزمة System.Security.Cryptography.ProtectedData على Windows وحظر الميزة على مخططات أخرى.
  2. إنشاء حل بديل لخطط أخرى. - إذا كان الأمر كذلك ، أعتقد أنه يجب علينا فتح إصدار جديد للتتبع.

شكرا للنظر في هذا.

iSazonov هل

iSazonov أفترض على الأقل أن لدينا وضوحًا بشأن سبب عدم القيام بذلك بدلاً من مجرد إغلاق المشكلة. نظرًا لأن هذا ليس عنصر عمل صغيرًا ، أعتقد أننا سننظر فيه لـ 6.1.0

@ SteveL-MSFT للتوافق مع الإصدارات السابقة مع Windows PowerShell أعتقد أنه من الجيد استخدام System.Security.Cryptography.ProtectedData اليوم.

ngetchell الحل البديل كما هو موضح في قضية CoreFX ، يتطلب الكثير من العمل المحدد لذلك سننتظر CoreFX. قد يكون الحل المحتمل لأنظمة Unix هو - استخدام اتصال بعيد بأنظمة windows.

iSazonov ، يعمل repro بالنسبة لي مع الإصدار التجريبي 4 على نظام Windows ، وأعتقد أن المشكلة موجودة فقط على غير Windows حاليًا

@ SteveL-MSFT آسف لعدم الدقة ، ضمن System.Security.Cryptography.ProtectedData قصدت _CoreFX package_. حاليا نستخدم التنفيذ الداخلي. الأسئلة هي - هل يجب إزالة الكود الداخلي والانتقال إلى الحزمة؟ هل يجب إزالة أوامر cmdlets الخاصة بـ * -SecureString من نظام التشغيل Unix؟

iSazonov أعتقد أننا يجب أن ننتقل إلى الحزمة الرسمية. بالنسبة لـ Unix ، يبدو أن الشيء الصحيح الذي يجب فعله هو إزالتها. cc joeyaiello

فقط أريد أن بينغ هذه القصة مرة أخرى.
هل ما زالت خطة _remove_ أوامر cmdlets الخاصة بـ ConvertTo / ConvertFrom SecureString؟
ماذا عن التعامل مع بيانات الاعتماد و SecureStrings في استيراد / تصدير CliXml؟

كل هؤلاء لا يزالون يرمون DllNotFoundException غير ودية للغاية من HRESULT ...

لدي نفس المشكلة مع خطأ CRYPT32.dll على Linux عند استخدام Export-Clixml cmdlet. إصدار PS 6.0.0

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

cenit ربما سنستخدم حزمة توافق Windows

@ iSazonov ، أفهم أن SecureString يعتمد على دعم نظام تشغيل محدد لا يتوفر على أنظمة تشغيل بخلاف Windows وليس جزءًا من حزمة توافق Windows.

يجب أن نقدم رسالة خطأ أفضل على الرغم من أن هذا لن يعمل.

هل هناك بعض البدائل الممكنة لأوامر cmdlets الخاصة بـ * -SecureString على نظام التشغيل Unix إذا تمت إزالتها؟
آسف إذا فاتني ذلك ، أعطني مؤشرًا عن سبب عدم إمكانية ذلك على يونكس. ما هو الجزء المفقود "الخاص بنظام التشغيل" والمطلوب في نظام التشغيل Unix؟
وإلا كيف يمكن التعامل مع بيانات الاعتماد للحصول عليها بالتنسيق الصحيح واستخدامها بشكل أكبر؟

أعتقد أن هذه المشكلة في CoreFX تلخصها بشكل مثالي: https://github.com/dotnet/corefx/issues/22510
كما يبدو ، للأسف ، أنه لم يتم إحراز أي تقدم.

شكرًا ، هذا يفسر ذلك جيدًا.

@ SteveL-MSFT افترض استخدام WCP استخدام النمط الشائع if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { ... }
إذا كانت بعض واجهات برمجة التطبيقات غير موجودة في WCP ، فيمكننا التعليق في WCP repo. ولكن حتى بدونها يمكننا استخدام النمط المشترك مع #if !UNIX .

iSazonov لهذه المشكلة المحددة ، لا أعتقد أن WCP سوف يحل هذا لأن نوع SecureString هو في الحقيقة تطبيق فارغ على غير Windows.

أنا أحب ذلك على أي حال. 😄

حسنًا ، أنا أقوم بتحرير هذا لأتأكد من صحة الأمر ...

  1. لم يكن هناك تطبيق SecureString إلا على Windows.
  2. سخر فريق PowerShell من ذلك ، حتى يتمكنوا من تجنب تغيير جميع واجهات برمجة التطبيقات التي تتطلب ذلك.
  3. ثم قام فريق .NET بتطبيقه ولكن فقط حماية الذاكرة قصيرة المدى
  4. لذا فإن محاولة إجراء تسلسل لـ (في) تعطل SecureString باستثناء نظام Windows ، لأن الوظيفة بأكملها هي الآن Windows فقط ، ولكنها مكشوفة في كل مكان ...

على الرغم من التحذير المبكر من ذلك منذ 18 شهرًا

على الرغم من الرسالة _ للغاية الواضحة_ من فريق NET Framework. قبل 6 أشهر.

🙄

خلاصة القول هي أن .NET framework (و PowerShell) يحتاجان إلى مكتبة حماية البيانات عبر الأنظمة الأساسية ، لأن dev / ops بحاجة إلى تخزين الأسرار لم تختف فجأة عندما أضفنا أنظمة تشغيل جديدة إلى المزيج ، وهي ليست عملية دائمًا للاعتماد على خدمات الويب مثل Azure KeyVault أو RED Identity management أو Thycotic Secret Server. 😕

يبدو أن فريق .NET لا يميل إلى أن يكون مفيدًا بشكل خاص هنا.

أعلم أن ASP.NET كتب عناصر حماية البيانات الخاصة بهم ، لكنه غريب إلى حد ما ويوصون بقصر استخدامه على سيناريوهات محددة ...

ما نحتاج إلى معرفته هو:

هل يخطط فريق PowerShell لإنشاء تنفيذ عبر الأنظمة الأساسية لتسلسل SecureString؟

إذا لم يكن الأمر كذلك ، فالرجاء إزالة أوامر cmdlets التي لا تعمل على الإطلاق ، وتقديم رسالة خطأ أفضل لـ CliXML من الرسالة الحالية ، "يا رتق ، إذا كان هناك خطأ Crypto dll متاح فقط".

تحقق من العناصر ذات الصلة:
NuGet / المنزل # 1851
دوت نت / corefx # 6746

يمكننا استخدام ASP.NET DataProtection. هذا هو الأكثر موثوقية مما هو متاح اليوم. خاصة أننا بحاجة إلى القليل.

أحاول قراءة كلمة المرور بأمان لتمريرها إلى سطر أوامر MySQL. ما هو البديل الموصى به ، حتى لا أقوم بترديد كلمات المرور لوحدة التحكم أثناء كتابتها؟

خطوات Repro

$str = Read-Host -AsSecureString
ConvertFrom-SecureString -SecureString $str

نتيجة

ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:1
+ ConvertFrom-SecureString -SecureString $str
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand

@ pcgeek86 هذا هو أحد الحلول للحصول على سلسلة نصية عادية من Securestring على لينكس:

$str = Read-Host -AsSecureString
$plaintext = [System.Net.NetworkCredential]::new('',$str).Password

لقد أضفت حلاً آخر في الوصف

يبدو أن التعامل مع الأسرار على نظام Linux يمثل فوضى كبيرة. هناك العديد من جهود التنفيذ والمشاريع التي عفا عليها الزمن.

يبدو أن جنوم يستخدم أو كان يستخدم واجهة برمجة تطبيقات الخدمة السرية . يبدو أن libsecret مكتبة للوصول إلى الأسرار باستخدام حافلة الخدمة السرية.

يسمح Mac OS X بالتفاعل مع Keychain عبر الأداة المساعدة لسطر الأوامر security أو برمجيًا عبر Keychain Services

QtKeychain هي طريقة لإنشاء كلمة مرور مستقلة

حتى يتم إصلاح ذلك ، إليك رمز لتمرير بيانات اعتماد بشكل آمن إلى وظيفة في الخلفية:


$credentialKey = New-Object 'byte[]' (256/8)
$rng = New-Object 'Security.Cryptography.RNGCryptoServiceProvider'
$rng.GetBytes($credentialKey)

$serializableCredential = [pscustomobject]@{ 
                                                UserName = $credential.UserName;
                                                Password = ConvertFrom-SecureString -SecureString $credential.Password -Key $credentialKey
                                            }

$job = Start-Job {
    param(
        [Parameter(Mandatory)]
        [byte[]]
        $Key
    )
    $serializedCredential = $using:serializableCredential

    $password = ConvertTo-SecureString -String $serializedCredential.Password -Key $Key
    $credential = New-Object 'PSCredential' ($serializedCredential.UserName,$password)
    [Array]::Clear($Key,0,$Key.Length)
} -ArgumentList (,$credentialKey) | Wait-Job | Receive-Job

[Array]::Clear($credentialKey,0,$credentialKey.Length)

كلمة المرور = ConvertFrom-SecureString - بيانات اعتماد SecureString $. كلمة المرور - مفتاح اعتماد $

كيف يفترض أن يعمل هذا إذا كان لهذا مشكلة في حد ذاته؟

على أي حال ، جربت البرنامج النصي ولكن حصل خطأ:

ConvertFrom-SecureString : Cannot bind argument to parameter 'SecureString' because it is null.
At /home/myusername/powershell.ps1:7 char:99
+ ... = ConvertFrom-SecureString -SecureString $credential.Password -Key $c ...
+                                              ~~~~~~~~~~~~~~~~~~~~

لذلك حاولت تحديد اسم المستخدم وكلمة المرور في متغير ولكن:

ConvertFrom-SecureString : Cannot bind parameter 'SecureString'. Cannot convert the "testpassword" value of type "System.String" to type "System.Security.SecureString".

لماذا لا توجد مشكلة منفصلة لتمرير سلسلة آمنة عبر psremote؟ تم إغلاق جميع الإصدارات المفتوحة باعتبارها نسخًا مكررة من هذا. في رأيي المشكلة مختلفة.
توقف PSRemote أثناء تبادل المفاتيح بسبب نقص تطبيق CryptoAPI على Linux.
من يهمه الأمر معلق هنا https://github.com/PowerShell/PowerShell/blob/5ece96a37fc9bb5cda962b32741b00396ae0f135/src/System.Management.Automation/utils/CryptoUtils.cs#L1117
راجع للشغل ، يمكننا إضافة معالج استثناء يظهر رسالة مفادها أن Securestring غير مدعوم حتى الآن ^ من الصعب جدًا إدراك أنه مرتبط بأحزمة الأمان إذا توقف على هذا النحو.
أعتقد أنه يمكن إصلاح psremoting دون إصلاح الأمر ConvertFrom-SecureString commandlet ، لأننا لسنا بحاجة إلى تخزين المفاتيح على الجهاز لاستخدامها لاحقًا. نحتاج فقط إلى إنشاء زوج مفاتيح rsa 2048 ، تشفير / فك تشفير باستخدام rsa ، فك تشفير باستخدام AES CBC crossplatform.

بعض الأخبار الجيدة هناك حل بديل عبر النظام الأساسي.
الحل البديل PSRemoting
استخدم تطبيق python الجديد لـ PSRP pypsrp فهو يدعم

KKomarov يرجى فتح مشكلة جديدة بخطوات الريبو

KKomarov تم إصلاح التعليق في PSCore6.2-RC كجزء من https://github.com/PowerShell/PowerShell/issues/8723 بالفعل. يجب أن تكون القدرة على إرسال سلاسل آمنة بالفعل لغير Windows مشكلة منفصلة.

DE0001: لا ينبغي استخدام SecureString
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

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

DE0001: لا ينبغي استخدام SecureString
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

على الرغم من أن هذا أمر رائع في عالم برج عاجي مثالي ، إلا أننا في Powershell نلصق الأشياء معًا باستمرار وهذا يتطلب المصادقة بأي تنسيق يتطلبه التطبيق ، سواء كان ذلك في واجهة برمجة التطبيقات (API) أو التطبيقات القديمة التي تدعم فقط المصادقة الأساسية وما إلى ذلك. "استخدم بيانات اعتماد Windows أو الشهادات" لكل شيء كما تنص هذه التوصية ، هذه توصية جيدة لتطوير تطبيق جديد ، ولكن ليس ما نستخدم بوويرشيل من أجله.

ليس الأمر كما لو أن PSCredential يذهب إلى أي مكان وهو تطبيق لـ SecureString ، لذلك حتى يكون لدينا شيء في .net core يمكنه استخدام TPM لتشفير المفاتيح أو شيء ما ، نحتاج إلى خيار "جيد بما فيه الكفاية".

شيء مثل استخدام AES256 وجعل مفتاح التشفير عبارة عن 600 ملف إذن على نظام ملفات بخلاف Windows هو بداية محتملة ، وليس أسوأ بكثير من استخدام Crypto API في Windows

أضفت الرابط للمعلومات فقط.

بشكل أساسي:

  1. من المستحيل نقل SecureString لأن System.Security.Cryptography.ProtectedData يعمل بنظام Windows فقط. لا توجد خطط لنقل واجهة برمجة التطبيقات. الفريق الأساسي يوقف API.
  2. يمكننا الحفاظ على التوافق مع الإصدارات السابقة لـ SecureString على Windows (بما في ذلك الاتصال عن بُعد)
  3. يجب أن يظل PowerShell Core مرنًا وأن يسمح بالعمل مع التطبيقات القديمة.
  4. من المقبول استخدام المصادقة الأساسية في بيئة محمية
  5. المشكلة الرئيسية هي كيفية اكتشاف البيئة المحمية مقابل البيئة العامة وماذا تفعل (منع المصادقة الأساسية ، فقط تحذير ، ...).

في وقت مبكر ، ناقشت لجنة @ PowerShell / بوويرشيل تقديم SensitiveString لاستبدال الحاجة الوظيفية لـ SecureString على الرغم من أن كلاهما غير آمن (لا تزال هناك حاجة إلى النوع SecureString إلى الوراء متوافق). هناك حاجة إلى نوع (سواء كان "حساسًا" أو "آمنًا" للإشارة إلى PowerShell للمطالبة دون تكرار الإدخال ، لذلك يتم استخدامه أكثر من مجرد الاتصال عن بُعد. أما بالنسبة إلى المشكلة الأصلية لهذا الخطأ ، فقد تم إصلاح هذا (لا يمكنك تحصل على خطأ بعد الآن) ، فقط ضع في اعتبارك أن SecureString داخلي بنص عادي.

شكرا على التحديث ، تبدو واعدة!
هل يمكننا أن نطلب إطارًا زمنيًا تقريبيًا عندما نتوقع أن نتمكن من استخدام هذا (على سبيل المثال في مستودع دبيان microsoft-debian-stretch-prod debian)؟

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

هل لدى أي شخص رابط للإصلاح أو يعرف ما هو إصدار الإصدار الذي سيكون متاحًا فيه؟ ما زلت أتلقى أخطاء crypt32.dll في Powershell_6.1.3-1.ubuntu.16.04_amd64.deb (نفس الصفقة مع حزمة معاينة 6.2.0-rc.1).

لدي فضول أيضًا حول كيفية تأثير هذا الإصلاح على استيراد / تصدير-CliXml عندما تحتوي البيانات المراد تحويلها إلى تسلسل على كائنات SecureString أو PSCredential.

rmbolger هل يمكنك التحقق من أحدث إصدار (6.2.0-RC) من فضلك؟

أرى نفس rmbolger

/home/hillr
03-20 23:44:55 31ms 11> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.2.0-rc.1
PSEdition                      Core
GitCommitId                    6.2.0-rc.1
OS                             Linux 4.4.0-17763-Microsoft #379-Microsoft Wed Mar 06 19:16:00 PST 2019
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

/home/hillr
03-21 00:47:45 35ms 12> ConvertFrom-SecureString -SecureString $ss
ConvertFrom-SecureString : Unable to load shared library 'CRYPT32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libCRYPT32.dll: cannot open shared object file: No such file or directory
At line:1 char:1
+ ConvertFrom-SecureString -SecureString $ss
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand
هل كانت هذه الصفحة مفيدة؟
5 / 5 - 1 التقييمات