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

Кажется, не хватает CoreCLR.

Talked @ KrishnaV-MSFT Это не требуется для демонстрации Azure. Вывод из Alpha.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 Cert: / LocalMachine /
• ~ ~ ~ ~ ~ ~ ~~~
  
  
  
  • CategoryInfo: NotSpecified: (:) [Get-ChildItem], DllNotFoundException
  
  
  • FullyQualifiedErrorId: System.DllNotFoundException, Microsoft.PowerShell.Commands.GetChildItemCommand
  
  

@ 35359595 хорошая находка! Ошибка определенно должна быть дружелюбнее. В Linux и macOS поставщику Cert:/ нужно немного переосмыслить. Способы хранения сертификатов в этих двух системах полностью отличаются друг от друга и от окон.

Fyi, 16.04.1 с PowerShell v6 alpha 14 все еще имеет ту же проблему

Это удерживает меня от переноса модулей в Linux. Я хотел бы иметь возможность безопасно хранить ключи веб-API во всех ОС, а не только в Windows.

Это то, что мы сможем включить только с API .NET Standard 2.0, которые возвращают SecureString:

• Проблема с CoreFX: dotnet / corefx # 13062
• CoreFX 2.0 PR: dotnet / corefx # 13362

ConvertFrom-SecureString и ConvertTo-SecureString зависят от System.Security.Cryptography.ProtectedData , который по-прежнему недоступен в netstandard2.0 .
Поэтому эти 2 командлета необходимо переработать на платформах 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 нужно переписать для Unix. Мы постараемся получить некоторые рекомендации от команды .NET Core о том, как выполнять те же задачи в Unix. / cc @joeyaiello

Скорее всего, подойдут ли [System.Runtime.InteropServices.Marshal] :: SecureStringToBSTR и [System.Runtime.InteropServices.Marshal] :: PtrToStringAuto?

Это все еще наблюдается в 6.0.0-beta3 на Mac и Linux при использовании командлетов SecureString.

ConvertFrom-SecureString: невозможно загрузить DLL 'CRYPT32.dll': указанный
модуль или одна из его зависимостей не найдены.
(Исключение из HRESULT: 0x8007007E)

то же самое здесь с convertfrom-securestring и convertto-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/, но потом выяснил:
файлы .dll linux:
"Исполняемый файл 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-MSFT @psmulovics Похоже, что команда CoreFX вообще не отслеживает закрытые проблемы - я считаю, что нам следует открыть там новый выпуск, если мы хотим какого-либо прогресса.

Создан новый выпуск https://github.com/dotnet/corefx/issues/22510

Это сработало! 😄 Теперь у нас есть ответ:

Мы не планируем этого делать. Для этого требуются функции ОС, доступные только в Windows.
..
То, что у нас есть в .NET Core, ясно. В Windows он делает то же, что и DPAPI. В отличие от Windows он делает то, что Windows DPAPI делает на этих платформах: не существует.

Отсюда следует вывод:

1. Используйте пакет System.Security.Cryptography.ProtectedData в Windows и заблокируйте эту функцию на других формах плана.
2. Создайте обходной путь для других форм плана. - Если это так, я считаю, что нам следует открыть новый выпуск для отслеживания.

Спасибо, что изучили это.

@iSazonov будет ли вариант 2 также

@iSazonov Я полагаю, по крайней мере, у нас есть ясность в том, почему это не будет сделано вместо того, чтобы просто закрыть проблему. Поскольку это не мелкая работа, я думаю, мы рассмотрим ее для версии 6.1.0.

@ SteveL-MSFT Я считаю, что для обратной совместимости с Windows PowerShell сегодня полезно использовать System.Security.Cryptography.ProtectedData.

@ngetchell Обходной путь, описанный в проблеме CoreFX, требует слишком много специфической работы, поэтому мы подождем CoreFX. Возможный обходной путь для систем Unix может заключаться в использовании удаленного подключения к системам Windows.

@iSazonov репро работает для меня с beta.4 в Windows, я считаю, что проблема только в не-Windows в настоящее время

@ SteveL-MSFT Извините за неточность, в разделе System.Security.Cryptography.ProtectedData я имел в виду _CoreFX package_. В настоящее время мы используем внутреннюю реализацию. Вопрос в том, следует ли нам удалить внутренний код и перейти на пакет? Следует ли нам удалить командлеты * -SecureString из Unix?

@iSazonov Я считаю, что нам следует перейти на официальный пакет. Что касается Unix, кажется, что правильнее всего их удалить. cc @joeyaiello

Просто хочу свистеть эту историю снова.
Планируется ли _удаление_ командлетов ConvertTo / ConvertFrom SecureString?
Как насчет обработки учетных данных и SecureStrings в Import / Export CliXml?

Все они по-прежнему вызывают очень недружелюбное исключение DllNotFoundException от HRESULT ...

У меня такая же проблема с ошибкой CRYPT32.dll в Linux при использовании командлета Export-Clixml. PS Версия 6.0.0

Тоже самое. Поскольку мы обсуждаем переносимость некоторых скриптов, было бы замечательно узнать, нужно ли нам обходить проблему или что-то будет сделано на стороне pwsh или CoreFX ( последнее, похоже, нет).

@cenit Возможно, мы воспользуемся Windows Compatibility Pack

@iSazonov , насколько я понимаю, SecureString зависит от поддержки конкретной ОС, которая недоступна в других операционных системах и не входит в пакет совместимости Windows.

Мы должны предоставить более точное сообщение об ошибке, даже если это не сработает.

Есть ли какая-либо альтернатива командлетам * -SecureString в Unix, если они будут удалены?
Извините, если я пропустил это, дайте мне указание, почему это невозможно в unix. Какая недостающая "специфическая для ОС" часть требуется в unix?
Как еще можно было обрабатывать учетные данные, чтобы получить их в правильном формате и в дальнейшем использовать?

Я думаю, что эта проблема на CoreFX прекрасно суммирует: https://github.com/dotnet/corefx/issues/22510
Также кажется, что никакого прогресса, к сожалению, не наблюдается.

спасибо, это очень хорошо объясняет.

@ SteveL-MSFT Использование WCP предполагает использование общего шаблона if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { ... }
Если какой-либо API отсутствует в WCP, мы могли бы оставить отзыв в репозитории WCP. Но даже без него мы можем использовать общий шаблон в сочетании с #if !UNIX .

@iSazonov для этой конкретной проблемы. Я не верю, что WCP решит эту проблему, поскольку тип SecureString на самом деле является пустой реализацией не в Windows.

Все равно мне это нравится. 😄

Хорошо, я редактирую это, чтобы убедиться, что все правильно ...

1. Реализации SecureString не было, кроме Windows.
2. Команда PowerShell высмеяла это, чтобы избежать изменения всех своих API, которые этого требуют.
3. Затем команда .NET реализовала это, но только краткосрочную защиту в памяти.
4. Таким образом, попытка сериализации (не) SecureString дает сбой, за исключением Windows, потому что вся функция теперь работает только в Windows, но доступна везде ...

Несмотря на раннее предупреждение об этом 18 месяцев назад

Несмотря на _ чрезвычайно ясное_ сообщение от команды .Net Framework 6 месяцев назад.

🙄

Суть в том, что .NET framework (и PowerShell) нуждается в кросс-платформенной библиотеке защиты данных, потому что разработчикам / операционным службам необходимо хранить секреты, которые не исчезают внезапно, когда мы добавляем новые операционные системы, и это не всегда практично. полагаться на такие веб-службы, как Azure KeyVault, RED Identity management или Thycotic Secret Server. 😕

Команда .NET явно не склонна быть здесь особенно полезной.

Я знаю, что ASP.NET написал свой собственный материал DataProtection , но это довольно странно, и они рекомендуют ограничить его использование конкретными сценариями ...

Что нам нужно знать:

Планирует ли группа PowerShell создать кросс-платформенную реализацию сериализации SecureString?

Если нет, удалите командлеты, которые вообще не работают, и предоставьте более точное сообщение об ошибке для CliXML, чем текущая ошибка типа «черт возьми, если бы была доступна только Crypto dll».

Проверьте связанные элементы:
NuGet / Главная # 1851
dotnet / corefx # 6746

Мы могли бы использовать ASP.NET DataProtection. Это самое надежное из имеющихся сегодня. Тем более, что нам нужно совсем немного.

Я пытаюсь безопасно прочитать пароль, чтобы перейти в командную строку MySQL. Какая альтернатива рекомендуется, чтобы я не выводил пароли на консоль при их вводе?

Шаги репродукции

$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 Это одно из решений для получения простой текстовой строки из защищенной строки в Linux:

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

Я добавил еще один обходной путь в описании

Обработка секретов в Linux кажется довольно беспорядочной. Есть много попыток внедрения и устаревших проектов.

Кажется, что Gnome использует или использовал API секретной службы . libsecret кажется библиотекой для доступа к секретам с помощью шины секретной службы.

Mac OS X позволяет взаимодействовать с связкой ключей с помощью утилиты командной строки security или программно через службы связки ключей .

QtKeychain - это подход к созданию независимого от платформы диспетчера паролей и секретов для Linux (с использованием libsecret), Mac OS X (с использованием Key Chain) и Windows (с использованием хранилища учетных данных Windows), который, вероятно, наиболее близок к тому, что требуется для PowerShell. Можем ли мы использовать это как отправную точку?

Пока это не будет исправлено, вот код для безопасной передачи учетных данных фоновой задаче:

$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 $ credential.Password -Key $ credentialKey

как это должно работать, если проблема сама по себе?

в любом случае, попробовал ваш скрипт, но получил ошибку:

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 еще не поддерживается ^ довольно сложно понять, что это связано с securestrings, если оно так зависает.
Я думаю, что psremoting можно исправить без исправления командлета ConvertFrom-SecureString , потому что нам не нужно хранить ключи на машине для последующего использования. Нам нужно только сгенерировать пару ключей rsa 2048, зашифровать / расшифровать с помощью rsa, расшифровать шифрование с помощью кросс-платформы AES CBC.

Хорошие новости: есть кроссплатформенный обходной путь.
Обходной путь для PSRemoting
Используйте новую реализацию PSRP pypsrp на Python, она поддерживает безопасные строки!

@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

@iSazonov

DE0001: SecureString использовать не следует
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

Хотя это хорошо в идеальном мире башни из слоновой кости, в Powershell мы постоянно склеиваем все вместе, и это требует аутентификации в любом формате, который требует приложение, будь то API для отдыха, устаревшее приложение, которое поддерживает только базовую аутентификацию, и т. Д. Мы не можем просто "использовать учетные данные или сертификаты Windows" для всего, как говорится в этой рекомендации, это хорошая рекомендация для разработки нового приложения, но не то, для чего мы используем PowerShell.

Это не похоже на то, что PSCredential никуда не денется, что является реализацией SecureString, поэтому, пока у нас не будет чего-то в ядре .net, которое может использовать TPM для шифрования ключей или чего-то еще, нам нужен «достаточно хороший» вариант.

Что-то вроде использования AES256 и наличия ключа шифрования в виде файла с разрешением 600 в файловой системе, отличной от Windows, - это возможное начало, не намного хуже, чем использование Crypto API в Windows

Я добавил ссылку только для информации.

По сути:

1. Невозможно перенести SecureString, поскольку System.Security.Cryptography.ProtectedData предназначена только для Windows. Нет планов по переносу API. Основная команда не рекомендует API.
2. Мы можем сохранить обратную совместимость для SecureString в Windows (включая удаленное взаимодействие)
3. PowerShell Core должен оставаться гибким и позволять работать с устаревшими приложениями.
4. Допускается использование базовой аутентификации в защищенной среде.
5. Основная проблема: как определить защищенную среду по сравнению с общедоступной и что делать (предотвратить базовую аутентификацию, только предупредить, ...).

Вначале комитет @ PowerShell / powershell обсуждал введение SensitiveString для замены функциональной потребности SecureString хотя оба они небезопасны (тип SecureString все равно потребуется для обратной совместимости). Тип (требуется ли "Чувствительный" или "Защищенный", чтобы указать PowerShell, что запросить без повторения ввода, чтобы он использовался не только для удаленного взаимодействия. Что касается исходной проблемы этой ошибки, то это было исправлено (вы не получить ошибку больше), просто имейте в виду, что SecureString внутри находится в виде обычного текста.

спасибо за обновление, выглядит многообещающе!
можем ли мы спросить примерные временные рамки, когда можно будет использовать это (например, в репозитории debian microsoft-debian-stretch-prod)?

Что касается исходной проблемы, связанной с этой ошибкой, она была исправлена ​​(вы больше не получаете ошибку), просто имейте в виду, что SecureString внутри находится в виде обычного текста.

Есть ли у кого-нибудь ссылка на исправление или знает, в какой версии релиза оно будет доступно? Я все еще получаю ошибки crypt32.dll в powershell_6.1.3-1.ubuntu.16.04_amd64.deb (то же самое с предварительным пакетом 6.2.0-rc.1).

Мне также любопытно, как это исправление влияет на Import / Export-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

Командлеты загружают непосредственно 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