https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/security/SecureStringHelper.cs#L449

Scheint CoreCLR zu sein, das fehlt.

Talked @ KrishnaV-MSFT Dies wird für die Azure-Demo nicht benötigt. Verschieben aus Alpha.10

Kam auf den gleichen Fehler unter MacOS 10.12 Beta (16A270f)

Habe nur rumgespielt habe folgendes bekommen:

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)

Ergebnis:

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

Hallo,

Gleicher Bibliotheksfehler beim Versuch, zugeordnetes Zertifikat zu verwenden: psdrive:

Get-ChildItem Cert:/LocalMachine/

Error:

get-childitem: DLL 'crypt32.dll' kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
(Ausnahme von HRESULT: 0x8007007E)
In Zeile: 1 Zeichen: 1

• get-childitem Cert: / LocalMachine /
• ~ ~ ~ ~ ~ ~ ~~~
  
  
  
  • CategoryInfo: NotSpecified: (:) [Get-ChildItem], DllNotFoundException
  
  
  • FullyQualifiedErrorId: System.DllNotFoundException, Microsoft.PowerShell.Commands.GetChildItemCommand
  
  

@ 35359595 gute Entdeckung! Der Fehler sollte auf jeden Fall freundlicher sein. Unter Linux und MacOS muss der Anbieter Cert:/ überdenken. Die Art und Weise, wie diese beiden Systeme beim Speichern von Zertifikaten vorgehen, unterscheidet sich grundlegend voneinander und von Fenstern.

Fyi, 16.04.1 mit PowerShell v6 alpha 14 hat immer noch das gleiche Problem

Dies hält mich davon ab, meine Module auf Linux umzustellen. Ich möchte in der Lage sein, Web-API-Schlüssel sicher auf allen Betriebssystemen zu speichern, nicht nur auf Windows.

Dies können wir nur mit den .NET Standard 2.0-APIs aktivieren, die SecureString zurückbringen:

• CoreFX-Problem: dotnet / corefx # 13062
• CoreFX 2.0 PR: dotnet / corefx # 13362

ConvertFrom-SecureString und ConvertTo-SecureString hängen von System.Security.Cryptography.ProtectedData , das in netstandard2.0 immer noch nicht verfügbar ist.
Daher müssen diese 2 Cmdlets auf Unix-Plattformen überarbeitet werden.

Ich würde es wirklich begrüßen, wenn diese Funktionalität zu .Net Core kommt
Wir verlassen uns auf WinRM und verwenden PSCredential zur Authentifizierung. Das Ausführen unserer Skripte unter Linux oder MacOS ist derzeit nicht möglich und hält uns ein wenig zurück.

Fehler sehen wir:
ConvertTo-SecureString: DLL 'CRYPT32.dll' kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
(Ausnahme von HRESULT: 0x8007007E)

@ reddwarf666 Das Paket System.Security.Cryptography.ProtectedData ist auf nuget.org verfügbar und stellt eine netstandard2.0-Beschwerde dar. Es ist jedoch nicht für Unix-Plattformen implementiert - es wird 'PlatformNotSupportedException' auf Unix-Plattformen auslösen. Daher muss ConvertFrom/ConvertTo-SecureString für Unix neu geschrieben werden. Wir werden versuchen, vom .NET Core-Team eine Anleitung zu erhalten, wie dieselben Aufgaben unter Unix ausgeführt werden können. / cc @joeyaiello

Würden [System.Runtime.InteropServices.Marshal] :: SecureStringToBSTR und [System.Runtime.InteropServices.Marshal] :: PtrToStringAuto wahrscheinlich mitfahren?

Dies wird immer noch unter 6.0.0-beta3 unter Mac und Linux angezeigt, wenn SecureString-Cmdlets verwendet werden.

ConvertFrom-SecureString: DLL 'CRYPT32.dll' kann nicht geladen werden: Die angegebene
Modul oder eine seiner Abhängigkeiten konnte nicht gefunden werden.
(Ausnahme von HRESULT: 0x8007007E)

Gleiches hier mit convertfrom-securestring und convertto-securestring (v6.0.0-beta.3) unter 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

Das Kopieren nach /opt/microsoft/powershell/6.0.0-beta.3/ und auch bei Angabe des absoluten Pfads führt zu demselben Fehler wie oben.

Ist eine Problemumgehung möglich / bekannt oder müssen wir warten, bis dies behoben ist?

@vchrizz Windows und Unix sind nicht binär kompatibel und wir können Windows DLL unter Unix nicht verwenden. Also sollten wir CoreFX warten.

@iSazonov Ich bin mir dessen bewusst, habe mich wegen dieser DLL-Dateien in /opt/microsoft/powershell/6.0.0-beta.3/ gefragt, aber dann herausgefunden:
Linux .dll Dateien:
"PE32-ausführbare Datei (DLL) (Konsole) Intel 80386 Mono / .Net-Assembly für MS Windows"
"Mono / .Net-Assembly mit ausführbarer PE32 + -Datei (DLL) (Konsole) für MS Windows"
Windows CRYPT32.dll-Datei:
"PE32-ausführbare Datei (DLL) (GUI) Intel 80386 für MS Windows"

Ich suche jetzt nach einer Problemumgehung und habe das gleiche Problem mit Export-Clixml gefunden:

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 Derzeit legt .Net CLI alle Assemblys in Unix-Paketen ab. # 3961 Verfolgen Sie die Unix-Verpackung.

@ daxian-dbw Wir könnten OpenSSH verwenden , um Daten zu schützen / aufzuheben.

Ich möchte lieber, dass wir keine benutzerdefinierte Sache für Nicht-Windows machen. Es sieht so aus, als würde das Nuget-Team auch danach fragen.

@ SteveL-MSFT, kann bestätigen, dass das Nuget-Team es benötigt (NuGet / Home # 1851), da ich derjenige war, der sie als fehlende Funktionalität erwähnt hat

@ SteveL-MSFT @psmulovics Es scheint, dass das CoreFX-Team geschlossene Probleme überhaupt nicht verfolgt - ich glaube, wir sollten dort eine neue Ausgabe eröffnen, wenn wir Fortschritte erzielen wollen.

Neue Ausgabe https://github.com/dotnet/corefx/issues/22510 erstellt

Es funktionierte! 😄 Jetzt haben wir eine Antwort:

Wir haben nicht vor, dies zu tun. Es erfordert Betriebssystemfunktionen, die nur unter Windows verfügbar sind.
..
Was wir in .NET Core haben, ist klar. Unter Windows funktioniert alles, was DPAPI tut. Unter Nicht-Windows funktioniert es wie Windows DPAPI auf diesen Plattformen: nicht vorhanden.

Also sollten wir folgern:

1. Verwenden Sie das Paket System.Security.Cryptography.ProtectedData unter Windows und blockieren Sie die Funktion auf anderen Planformen.
2. Erstellen Sie eine Problemumgehung für andere Planformen. - Wenn ja, sollten wir meiner Meinung nach eine neue Ausgabe zur Nachverfolgung eröffnen.

Vielen Dank, dass Sie sich damit befasst haben.

@iSazonov würde Option 2 auch System.Runtime.InteropServices.Marshal einbringen?

@iSazonov Ich nehme an, wir haben zumindest Klarheit darüber, warum dies nicht getan wird, anstatt nur das Problem zu schließen. Da dies kein kleines Arbeitselement ist, werden wir es wahrscheinlich für 6.1.0 untersuchen

@ SteveL-MSFT Aus Gründen der Abwärtskompatibilität mit Windows PowerShell ist es meiner Meinung nach gut, System.Security.Cryptography.ProtectedData heute zu verwenden.

@ngetchell Die in der CoreFX-Ausgabe beschriebene Problemumgehung erfordert zu viel spezifische Arbeit, sodass wir auf CoreFX warten müssen. Mögliche Problemumgehung für Unix-Systeme ist möglicherweise die Verwendung einer Remoteverbindung zu Windows-Systemen.

@iSazonov der Repro funktioniert für mich mit Beta.4 unter Windows, ich glaube, das Problem ist derzeit nur unter Nicht-Windows

@ SteveL-MSFT Entschuldigung für die Ungenauigkeit unter System.Security.Cryptography.ProtectedData Ich meinte _CoreFX package_. Derzeit verwenden wir die interne Implementierung. Die Frage ist - sollten wir den internen Code entfernen und auf das Paket migrieren? Sollten wir * -SecureString-Cmdlets von Unix entfernen?

@iSazonov Ich glaube, wir sollten zum offiziellen Paket @joeyaiello

Ich möchte diese Geschichte nur noch einmal anpingen .
Ist es immer noch geplant, die Cmdlets ConvertTo / ConvertFrom SecureString zu entfernen?
Was ist mit dem Umgang mit Anmeldeinformationen und SecureStrings in Import / Export CliXml?

All dies wirft immer noch die sehr unfreundliche DllNotFoundException von HRESULT ...

Ich habe das gleiche Problem mit dem Fehler CRYPT32.dll unter Linux bei Verwendung des Cmdlets Export-Clixml. PS Version 6.0.0

Hier gilt das gleiche. Da wir über die Portabilität einiger Skripte diskutieren, wäre es wunderbar zu wissen, ob wir das Problem umgehen müssen oder ob etwas auf der Seite pwsh oder CoreFX (the) getan wird Letzteres scheint nicht).

@cenit Vielleicht verwenden wir Windows Compatibility Pack

@iSazonov Ich verstehe, dass SecureString von der spezifischen Betriebssystemunterstützung abhängt, die unter Nicht-Windows nicht verfügbar ist und nicht Teil des Windows-Kompatibilitätspakets ist.

Wir sollten eine bessere Fehlermeldung bereitstellen, auch wenn dies nicht funktioniert.

Gibt es eine mögliche Alternative zu den Cmdlets * -SecureString unter Unix, wenn sie entfernt werden?
Entschuldigung, wenn ich es verpasst habe, gib mir einen Hinweis, warum es unter Unix nicht möglich ist. Was ist der fehlende "os-spezifische" Teil, der unter Unix benötigt wird?
Wie sonst könnte man mit Anmeldeinformationen umgehen, um sie in das richtige Format zu bringen und sie weiter zu verwenden?

Ich denke, dieses Problem unter CoreFX fasst es perfekt zusammen: https://github.com/dotnet/corefx/issues/22510
Es scheint auch, dass leider keine Fortschritte erzielt werden.

danke, das erklärt es sehr gut.

@ SteveL-MSFT Bei Verwendung von WCP wird davon ausgegangen, dass das allgemeine Muster if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { ... }
Wenn in WCP eine API fehlt, können wir im WCP-Repo Feedback geben. Aber auch ohne können wir das übliche Muster in Kombination mit #if !UNIX .

@iSazonov für dieses spezielle Problem Ich glaube nicht, dass WCP dies lösen wird, da der SecureString-Typ unter Nicht-Windows wirklich eine leere Implementierung ist.

Ich mag es trotzdem. 😄

Ok, ich bearbeite das, um sicherzugehen, dass ich es richtig verstanden habe ...

1. Es gab keine SecureString-Implementierung außer unter Windows.
2. Das PowerShell-Team hat sich darüber lustig gemacht, um zu vermeiden, dass alle APIs geändert werden, die dies erfordern.
3. Dann implementierte das .NET-Team es aber nur den kurzfristigen In-Memory-Schutz
4. So versuchen , eine (in) Secure serialisiert stürzt außer auf Windows, weil die ganze Funktion von Windows ist jetzt nur, sondern ist überall ausgesetzt ...

Trotz der Frühwarnung vor 18 Monaten

Trotz der extrem klaren Botschaft des .Net Framework-Teams vor 6 Monaten.

🙄

Unter dem Strich benötigt das .NET Framework (und PowerShell) eine plattformübergreifende Datenschutzbibliothek, da Entwickler, die Geheimnisse speichern müssen, nicht plötzlich verschwunden sind, als wir dem Mix neue Betriebssysteme hinzugefügt haben, und dies nicht immer praktisch ist um sich auf Webdienste wie Azure KeyVault, RED Identity Management oder Thycotic Secret Server zu verlassen. 😕

Das .NET-Team ist offenbar nicht geneigt, hier besonders hilfreich zu sein.

Ich weiß, dass ASP.NET ihre eigenen DataProtection-Inhalte geschrieben hat , aber es ist ziemlich seltsam und sie empfehlen, die Verwendung auf bestimmte Szenarien zu beschränken ...

Was wir wissen müssen ist:

Plant das PowerShell-Team, eine plattformübergreifende Implementierung der SecureString-Serialisierung zu erstellen?

Wenn nicht, entfernen Sie bitte die Cmdlets, die überhaupt nicht funktionieren, und geben Sie eine bessere Fehlermeldung für CliXML als den aktuellen Fehler "Oh verdammt, wenn nur eine Crypto-DLL verfügbar wäre".

Schauen Sie sich verwandte Artikel an:
NuGet / Home # 1851
dotnet / corefx # 6746

Wir könnten ASP.NET DataProtection verwenden. Dies ist das zuverlässigste von dem, was heute verfügbar ist. Zumal wir ziemlich viel brauchen.

Ich versuche, ein Passwort sicher zu lesen, um es in eine MySQL-Befehlszeile zu übertragen. Was ist die empfohlene Alternative, damit ich während der Eingabe keine Passwörter an die Konsole weitergebe?

Repro Schritte

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

Ergebnis

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 Dies ist eine Lösung, um die einfache Textzeichenfolge von einem sicheren Ring unter Linux abzurufen:

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

Ich habe der Beschreibung eine weitere Problemumgehung hinzugefügt

Der Umgang mit Geheimnissen unter Linux scheint ein ziemliches Chaos zu sein. Es gibt viele Implementierungsbemühungen und veraltete Projekte.

Es scheint, dass Gnome die Secret Service API verwendet oder verwendet hat . libsecret scheint eine Bibliothek zu sein, um über den Secret Service-Bus auf Geheimnisse zuzugreifen.

Mac OS X ermöglicht die Interaktion mit dem Schlüsselbund über das Befehlszeilenprogramm security oder programmgesteuert über die Schlüsselbunddienste .

QtKeychain ist ein Ansatz zum Erstellen eines plattformunabhängigen Kennwort- und Geheimmanagers für Linux (unter Verwendung von libsecret), Mac OS X (unter Verwendung der Schlüsselkette) und Windows (unter Verwendung des Windows Credential Store) und entspricht wahrscheinlich den Anforderungen für PowerShell. Könnten wir dies als Ausgangspunkt verwenden?

Bis dies behoben ist, ist hier der Code, um einen Berechtigungsnachweis sicher an einen Hintergrundjob zu übergeben:

$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)

Password = ConvertFrom-SecureString -SecureString $ credential.Password -Key $ credentialKey

Wie soll das funktionieren, wenn dies selbst ein Problem hat?

Wie auch immer, habe dein Skript ausprobiert, aber einen Fehler bekommen:

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 ...
+                                              ~~~~~~~~~~~~~~~~~~~~

Also habe ich versucht, Benutzername und Passwort in einer Variablen zu definieren, aber:

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

Warum gibt es kein separates Problem beim Übergeben einer sicheren Zeichenfolge über psremote? Alle geöffneten Ausgaben wurden als Duplikate davon geschlossen. Meiner Meinung nach ist das Problem anders.
PSRemote hängt während des Schlüsselaustauschs aufgrund fehlender CryptoAPI-Implementierung unter Linux.
Wer sich dafür interessiert, hängt hier https://github.com/PowerShell/PowerShell/blob/5ece96a37fc9bb5cda962b32741b00396ae0f135/src/System.Management.Automation/utils/CryptoUtils.cs#L1117
Übrigens können wir einen Ausnahmebehandler hinzufügen, der die Meldung anzeigt, dass Securestring noch nicht unterstützt wird. Es ist ziemlich schwer zu erkennen, dass es sich um Securestrings handelt, wenn es so hängt.
Ich denke, psremoting kann behoben werden, ohne das Kommando ConvertFrom-SecureString reparieren, da wir keine Schlüssel für die spätere Verwendung auf dem Computer speichern müssen. Wir müssen nur rsa 2048-Schlüsselpaar generieren, Krypta / Entschlüsselung mit rsa, Krypta-Entschlüsselung mit AES CBC-Crossplatform.

Einige gute Nachrichten gibt es plattformübergreifende Problemumgehung.
Problemumgehung für PSRemoting
Verwenden Sie die neue Python-Implementierung von PSRP pypsrp , das Securestrings unterstützt!

@KKomarov Bitte öffnen Sie eine neue Ausgabe mit Repo-Schritten und Ihrem Vorschlag.

@KKomarov Der Hang wurde in PSCore6.2-RC als Teil von https://github.com/PowerShell/PowerShell/issues/8723 bereits behoben. Die Möglichkeit, sichere Zeichenfolgen für Nicht-Windows-Benutzer zu senden, sollte ein separates Problem sein.

DE0001: SecureString sollte nicht verwendet werden
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-sollte nicht verwendet werden

@iSazonov

DE0001: SecureString sollte nicht verwendet werden
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-sollte nicht verwendet werden

Während das in einer perfekten Elfenbeinturm-Welt schön ist, kleben wir in Powershell ständig Dinge zusammen und das erfordert die Authentifizierung in jedem Format, das für die Anwendung erforderlich ist, sei es eine Rest-API, eine Legacy-Anwendung, die nur die Standardauthentifizierung unterstützt usw. Wir können nicht einfach "Windows-Anmeldeinformationen oder -Zertifikate verwenden" für alles, wie in dieser Empfehlung angegeben, ist eine nette Empfehlung für die Entwicklung einer neuen App, aber nicht für das, wofür wir Powershell verwenden.

Es ist nicht so, dass PSCredential irgendwohin geht, wo es sich um eine Implementierung von SecureString handelt. Bis wir also etwas im .net-Kern haben, das ein TPM zum Verschlüsseln von Schlüsseln oder Ähnlichem verwenden kann, benötigen wir eine "gut genug" -Option.

Etwas wie die Verwendung von AES256 und die Verwendung des Verschlüsselungsschlüssels als Datei mit 600 Berechtigungen im Nicht-Windows-Dateisystem ist ein möglicher Start, nicht viel schlimmer als die Verwendung der Crypto-API in Windows

Ich habe den Link nur zur Information hinzugefügt.

Im Wesentlichen:

1. Es ist nicht möglich, SecureString zu portieren, da System.Security.Cryptography.ProtectedData nur für Windows verfügbar ist. Es ist nicht geplant, die API zu portieren. Das Kernteam veraltet die API.
2. Wir können die Abwärtskompatibilität für SecureString unter Windows beibehalten (einschließlich Remoting).
3. PowerShell Core muss flexibel bleiben und die Arbeit mit älteren Anwendungen ermöglichen.
4. Es ist akzeptabel, die Basisauthentifizierung in einer geschützten Umgebung zu verwenden
5. Hauptproblem, wie man eine geschützte Umgebung gegenüber einer öffentlichen Umgebung erkennt und was zu tun ist (grundlegende Authentifizierung verhindern, nur warnen, ...).

Schon früh diskutierte das @ PowerShell / Powershell-Komitee die Einführung eines SensitiveString , um den funktionalen Bedarf von SecureString SensitiveString zu ersetzen, obwohl beide nicht sicher sind (der Typ SecureString wäre weiterhin erforderlich für abwärtskompatibel). Ein Typ (unabhängig davon, ob "Sensitive" oder "Secure" erforderlich ist, um PowerShell anzuzeigen, dass die Eingabeaufforderung ohne Echo der Eingabe angezeigt werden soll, wird nicht nur zum Remoting verwendet. Das ursprüngliche Problem dieses Fehlers wurde behoben (dies ist nicht der Fall) Fehler mehr), denken Sie daran, dass der SecureString intern im Klartext vorliegt.

Danke für das Update, sieht vielversprechend aus!
Dürfen wir nach einem ungefähren Zeitrahmen fragen, wann wir damit rechnen können, dies nutzen zu können (z. B. im Debian-Repository von Microsoft-Debian-Stretch-Prod)?

Das ursprüngliche Problem dieses Fehlers wurde behoben (es wird kein Fehler mehr angezeigt). Beachten Sie jedoch, dass SecureString intern im Klartext vorliegt.

Hat jemand einen Link zum Fix oder weiß, in welcher Release-Version es verfügbar sein wird? Ich bekomme immer noch crypt32.dll-Fehler in Powershell_6.1.3-1.ubuntu.16.04_amd64.deb (dasselbe gilt für das Vorschau-Paket 6.2.0-rc.1).

Ich bin auch gespannt, wie sich dieser Fix auf Import / Export-CliXml auswirkt, wenn die zu serialisierenden Daten SecureString- oder PSCredential-Objekte enthalten.

@rmbolger Könnten Sie bitte mit dem neuesten Build (6.2.0-RC) überprüfen?

Ich sehe das gleiche wie

/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

Die Cmdlets laden direkt die CRYPT32.dll
https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/Microsoft.PowerShell.Security/security/SecureStringCommands.cs#L169

https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/System.Management.Automation/security/SecureStringHelper.cs#L158

https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/System.Management.Automation/security/SecureStringHelper.cs#L449

https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/System.Management.Automation/security/SecureStringHelper.cs#L590