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

Parece que falta o CoreCLR.

Talked @ KrishnaV-MSFT Não é necessário para a demonstração do Azure. Movendo-o para fora do Alpha.

Encontrei o mesmo erro no MacOS 10.12 Beta (16A270f)

Estava só brincando, consegui isso:

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)

Resultado:

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

Oi,

mesmo erro de biblioteca ao tentar usar cert mapeado: psdrive:

Get-ChildItem Cert:/LocalMachine/

Erro:

get-childitem: Impossível carregar DLL 'crypt32.dll': O módulo especificado não foi encontrado.
(Exceção de HRESULT: 0x8007007E)
Na linha: 1 caractere: 1

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

@ 35359595 bom achado! O erro definitivamente deveria ser mais amigável. No Linux e no macOS, o provedor Cert:/ precisa ser repensado. A forma como esses dois sistemas abordam o armazenamento de certificados é completamente diferente um do outro e do Windows.

Fyi, 16.04.1 com PowerShell v6 alfa 14 ainda tem o mesmo problema

Isso está me impedindo de trazer meus módulos para o Linux. Gostaria de poder armazenar chaves de API da Web com segurança em todos os sistemas operacionais, não apenas no Windows.

Isso é algo que só seremos capazes de habilitar com as APIs .NET Standard 2.0 que trazem de volta SecureString:

• Problema CoreFX: dotnet / corefx # 13062
• CoreFX 2.0 PR: dotnet / corefx # 13362

ConvertFrom-SecureString e ConvertTo-SecureString dependem de System.Security.Cryptography.ProtectedData , que ainda não está disponível em netstandard2.0 .
Portanto, esses 2 cmdlets precisam ser retrabalhados em plataformas Unix.

Eu realmente apreciaria se essa funcionalidade vier para .Net Core
Contamos com WinRM e usamos PSCredential para autenticação. Executar nossos scripts no Linux ou MacOS não é possível no momento e está nos atrasando um pouco.

Erro que vemos:
ConvertTo-SecureString: Impossível carregar DLL 'CRYPT32.dll': O módulo especificado não foi encontrado.
(Exceção de HRESULT: 0x8007007E)

@ reddwarf666 O pacote System.Security.Cryptography.ProtectedData está disponível no nuget.org e é uma reclamação do netstandard2.0. No entanto, ele não tem implementação para plataformas Unix - ele lançará 'PlatformNotSupportedException' em plataformas Unix. Portanto, ConvertFrom/ConvertTo-SecureString precisa ser reescrito para Unix. Tentaremos obter alguma orientação da equipe do .NET Core sobre como fazer as mesmas tarefas no Unix. / cc @joeyaiello

Será que [System.Runtime.InteropServices.Marshal] :: SecureStringToBSTR e [System.Runtime.InteropServices.Marshal] :: PtrToStringAuto provavelmente viriam para o passeio?

Ainda vejo isso em 6.0.0-beta3 no Mac e Linux ao usar cmdlets SecureString.

ConvertFrom-SecureString: Não é possível carregar DLL 'CRYPT32.dll': O especificado
módulo ou uma de suas dependências não foi encontrado.
(Exceção de HRESULT: 0x8007007E)

o mesmo aqui com convertfrom-securestring e convertto-securestring (v6.0.0-beta.3) no 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

copiar para /opt/microsoft/powershell/6.0.0-beta.3/ e também quando especificado o caminho absoluto, dá o mesmo erro acima.

existe uma solução alternativa possível / conhecida ou temos que esperar até que isso seja corrigido?

@vchrizz Windows e Unix não são binários compatíveis e não podemos usar dll do Windows em Unix. Portanto, devemos esperar CoreFX.

@iSazonov estou ciente disso, estava me perguntando por causa daqueles arquivos .dll em /opt/microsoft/powershell/6.0.0-beta.3/, mas depois descobri:
arquivos .dll do linux:
"PE32 executável (DLL) (console) Intel 80386 Mono / .Net assembly, para MS Windows"
"PE32 + executável (DLL) (console) Conjunto Mono / .Net, para MS Windows"
arquivo CRYPT32.dll do Windows:
"PE32 executável (DLL) (GUI) Intel 80386, para MS Windows"

agora procurando uma solução alternativa e encontrou o mesmo problema com 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 Atualmente .Net CLI coloca todos os assemblies em pacotes Unix. # 3961 rastreia o pacote Unix.

@ daxian-dbw Podemos usar OpenSSH para proteger / desproteger dados.

Prefiro que não façamos algo personalizado para não Windows. Parece que a equipe Nuget também está pedindo isso.

@ SteveL-MSFT, pode confirmar que a equipe nuget precisa dele (NuGet / Home # 1851), já que fui eu quem os trouxe como uma funcionalidade ausente

@ SteveL-MSFT @psmulovics Parece que a equipe CoreFX não rastreia problemas fechados - acredito que devemos abrir um novo problema lá se quisermos algum progresso.

Novo problema criado https://github.com/dotnet/corefx/issues/22510

Funcionou! 😄 Agora temos uma resposta:

Não temos planos de fazer isso. Requer recursos do sistema operacional que estão disponíveis apenas no Windows.
..
O que temos no .NET Core é claro. No Windows, ele faz tudo o que a DPAPI faz. Em não Windows, ele faz o que o Windows DPAPI faz nessas plataformas: não existe.

Portanto, devemos concluir:

1. Use o pacote System.Security.Cryptography.ProtectedData no Windows e bloqueie o recurso em outros planforms.
2. Crie uma solução alternativa para outros planforms. - Nesse caso, acredito que devemos abrir um novo Issue para rastreamento.

Obrigado por investigar isso.

@iSazonov a opção 2 também traria System.Runtime.InteropServices.Marshal?

@iSazonov Suponho que pelo menos temos clareza sobre por que isso não será feito, em vez de apenas resolvermos o problema. Uma vez que este não é um item de trabalho pequeno, acho que vamos examiná-lo para 6.1.0

@ SteveL-MSFT Para compatibilidade com versões anteriores do Windows PowerShell, acredito que seja bom usar System.Security.Cryptography.ProtectedData hoje.

@ngetchell A solução alternativa, conforme descrito no problema do CoreFX, requer muito trabalho específico, por isso devemos esperar o CoreFX. A possível solução para os sistemas Unix pode ser - usar uma conexão remota com os sistemas Windows.

@iSazonov o repro funciona para mim com beta.4 no Windows, acredito que o problema está apenas em não-Windows atualmente

@ SteveL-MSFT Desculpe pela imprecisão, em System.Security.Cryptography.ProtectedData eu quis dizer _PacoteCoreFX_. Atualmente usamos implementação interna. A pergunta é - devemos remover o código interno e migrar para o pacote? Devemos remover os cmdlets * -SecureString do Unix?

@iSazonov Acredito que devemos passar para o pacote oficial. Quanto ao Unix, parece que a coisa certa a fazer é removê-los. cc @joeyaiello

Só quero dar um ping nesta história novamente.
Ainda existe o plano de _remover_ os cmdlets ConvertTo / ConvertFrom SecureString?
E quanto ao tratamento de credenciais e SecureStrings no Import / Export CliXml?

Todos estes ainda estão lançando a muito hostil DllNotFoundException de HRESULT ...

Tenho o mesmo problema com o erro CRYPT32.dll no Linux ao usar o cmdlet Export-Clixml. PS versão 6.0.0

O mesmo aqui. Uma vez que estamos discutindo sobre a portabilidade de alguns scripts, seria maravilhoso saber se temos que contornar o problema ou se algo será feito no lado pwsh ou CoreFX (o este último parece não).

@cenit Talvez usemos o Pacote de Compatibilidade do Windows

@iSazonov , é meu entendimento que SecureString depende de suporte de sistema operacional específico que não está disponível em não-Windows e não faz parte do Pacote de Compatibilidade do Windows.

Devemos fornecer uma mensagem de erro melhor, mesmo que isso não funcione.

Existe alguma alternativa possível para os cmdlets * -SecureString no Unix se eles forem removidos?
Desculpe se eu perdi, me dê uma dica sobre por que não é possível no Unix. Qual é a parte "específica do sistema operacional" que falta no Unix?
De que outra forma alguém poderia lidar com as credenciais para colocá-las no formato correto e usá-las posteriormente?

Acho que este problema no CoreFX resume isso perfeitamente: https://github.com/dotnet/corefx/issues/22510
Também parece que nenhum progresso está sendo feito, infelizmente.

obrigado, isso explica muito bem.

@ SteveL-MSFT Usando o WCP assume o uso do padrão comum if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { ... }
Se alguma API estiver ausente no WCP, poderíamos enviar feedback no repositório do WCP. Mas mesmo sem ele, podemos usar o padrão comum combinado com #if !UNIX .

@iSazonov para este problema específico, não acredito que o WCP vá resolver isso, pois o tipo SecureString é realmente uma implementação vazia em não-Windows.

Eu gosto mesmo assim. 😄

Ok, estou editando isso para ter certeza de que entendi direito ...

1. Não houve implementação de SecureString, exceto no Windows.
2. A equipe do PowerShell fez uma simulação para evitar a alteração de todas as APIs que o exigem.
3. Então, a equipe .NET o implementou, mas apenas a proteção de curto prazo na memória
4. Portanto, tentar serializar uma (in) SecureString trava, exceto no Windows, porque toda a função agora é apenas Windows, mas está exposta em todos

Apesar do aviso prévio de 18 meses atrás

Apesar da mensagem _extremamente clara_ da equipe do .Net Framework 6 meses atrás.

🙄

O resultado final é que a estrutura .NET (e PowerShell) precisa de uma biblioteca de proteção de dados de plataforma cruzada, porque os dev / ops precisam armazenar segredos não desaparecem repentinamente quando adicionamos novos sistemas operacionais à mistura, e nem sempre é prático contar com serviços da web como Azure KeyVault, gerenciamento de identidade RED ou Thycotic Secret Server. 😕

A equipe .NET aparentemente não está inclinada a ser particularmente útil aqui.

Eu sei que o ASP.NET escreveu seu próprio material de DataProtection , mas é bastante estranho e eles recomendam limitar seu uso a cenários específicos ...

O que precisamos saber é:

A equipe do PowerShell planeja criar uma implementação de plataforma cruzada de serialização SecureString?

Caso contrário, remova os cmdlets que não funcionam de forma alguma e forneça uma mensagem de erro melhor para CliXML do que a atual, "oh, droga, se ao menos houvesse um erro Crypto dll disponível".

Confira os itens relacionados:
NuGet / Home # 1851
dotnet / corefx # 6746

Poderíamos usar o ASP.NET DataProtection. Este é o mais confiável do que está disponível hoje. Especialmente porque precisamos de um pouco.

Estou tentando ler uma senha com segurança, para passar para uma linha de comando do MySQL. Qual é a alternativa recomendada, para que eu não repita as senhas para o console enquanto as digito?

Etapas Repro

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

Resultado

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 Esta é uma solução para obter a string de texto simples de uma string de segurança no linux:

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

Eu adicionei outra solução alternativa na descrição

Manipular segredos no Linux parece ser uma bagunça. Existem muitos esforços de implementação e projetos desatualizados.

Parece que o Gnome está ou estava usando a API do serviço secreto . libsecret parece ser uma biblioteca para acessar segredos usando o barramento de serviço secreto.

O Mac OS X permite interagir com as Chaves por meio do utilitário de linha de comando security ou programaticamente por meio dos Serviços das

QtKeychain é uma abordagem para criar uma senha independente de plataforma e um gerenciador de segredos para Linux (usando libsecret), Mac OS X (usando o Key Chain) e Windows (usando o Windows Credential Store) e é provavelmente o mais próximo do que é necessário para PowerShell. Podemos usar isso como ponto de partida?

Até que isso seja corrigido, aqui está o código para passar com segurança uma credencial para um trabalho em segundo plano:

$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

como isso deve funcionar se houver um problema em si?

de qualquer forma, tentei seu script, mas obteve o erro:

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

então tentei definir o nome de usuário e a senha em uma variável, mas:

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

Por que não há problema separado para passar string segura sobre psremote? Todos os problemas abertos foram fechados como duplicatas deste. Na minha opinião o problema é diferente.
O PSRemote trava durante a troca de chaves devido à falta de implementação do CryptoAPI no Linux.
Quem estiver interessado trava aqui https://github.com/PowerShell/PowerShell/blob/5ece96a37fc9bb5cda962b32741b00396ae0f135/src/System.Management.Automation/utils/CryptoUtils.cs#L1117
A propósito, podemos adicionar o manipulador de exceções mostrando a mensagem de que o securestring ainda não é suportado ^ é muito difícil perceber que está relacionado a securestrings se travar assim.
Acho que o psremoting pode ser corrigido sem corrigir ConvertFrom-SecureString commandlet, porque não precisamos armazenar chaves na máquina para uso posterior. Precisamos apenas gerar o par de chaves rsa 2048, criptografar / descriptografar usando rsa, criptografar descriptografar usando AES CBC plataforma cruzada.

Uma boa notícia é a solução alternativa para plataformas cruzadas.
Solução alternativa para PSRemoting
Use a implementação nova do python do PSRP pypsrp que suporta sequências de

@KKomarov Abra um novo problema com etapas de repo e sua sugestão.

@KKomarov o travamento foi corrigido no PSCore6.2-RC como parte de https://github.com/PowerShell/PowerShell/issues/8723 já. A capacidade de realmente enviar strings seguras para não-Windows deve ser um problema separado.

DE0001: SecureString não deve ser usado
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

@iSazonov

DE0001: SecureString não deve ser usado
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

Embora isso seja bom em um mundo de torre de marfim perfeito, no Powershell estamos constantemente colando coisas e isso requer autenticação em qualquer formato que o aplicativo requer, seja API restante, aplicativo legado que suporta apenas autenticação básica, etc. Não podemos simplesmente simplesmente "usar credenciais ou certificados do Windows" para tudo, como afirma esta recomendação, é uma boa recomendação para desenvolver um novo aplicativo, mas não para o que usamos o PowerShell.

Não é como se PSCredential fosse a qualquer lugar que seja uma implementação de SecureString, então até que tenhamos algo no núcleo .net que possa usar um TPM para criptografar chaves ou algo assim, precisamos de uma opção "boa o suficiente".

Algo como usar AES256 e ter a chave de criptografia como um arquivo com permissão 600 no sistema de arquivos não Windows é um começo possível, não muito pior do que usar a API Crypto no Windows

Eu adicionei o link apenas para informação.

Essencialmente:

1. É impossível portar SecureString porque System.Security.Cryptography.ProtectedData é somente para Windows. Não há planos para portar a API. A equipe principal suspende o uso da API.
2. Podemos manter a compatibilidade com versões anteriores para SecureString no Windows (incluindo remoting)
3. O PowerShell Core deve permanecer flexível e permitir o trabalho com aplicativos legados.
4. É aceitável usar autenticação básica em ambiente protegido
5. Principal problema como detectar ambiente protegido vs ambiente público e o que fazer (prevenir autenticação básica, apenas avisar, ...).

No início, o @ PowerShell / powershell-Committee discutiu a introdução de SensitiveString para substituir a necessidade funcional de SecureString , embora ambos não sejam seguros (o tipo SecureString ainda seria necessário para compatibilidade com versões anteriores). Um tipo (seja "Sensível" ou "Seguro" é necessário para indicar ao PowerShell para solicitar sem ecoar a entrada, então ele é usado mais do que apenas para comunicação remota. Quanto ao problema original deste bug, isso foi corrigido (você não obter mais um erro), apenas tenha em mente que SecureString está internamente em texto simples.

obrigado pela atualização, parece promissor!
podemos pedir um período de tempo aproximado para podermos utilizar isso (por exemplo, no repositório debian microsoft-debian-stretch-prod)?

Quanto ao problema original desse bug, ele foi corrigido (você não recebe mais um erro), apenas tenha em mente que o SecureString está internamente em texto simples.

Alguém tem um link para a correção ou sabe em qual versão de lançamento ela estará disponível? Ainda estou recebendo erros crypt32.dll em powershell_6.1.3-1.ubuntu.16.04_amd64.deb (mesmo acordo com o pacote de visualização 6.2.0-rc.1).

Também estou curioso para saber como essa correção afeta Import / Export-CliXml quando os dados a serem serializados contêm objetos SecureString ou PSCredential.

@rmbolger Você poderia verificar a versão mais recente (6.2.0-RC)?

Estou vendo o mesmo que @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

Os cmdlets carregam diretamente o 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