Сохранение и отзыв последних расположений (Push-Location и Pop-Location)
При изменении расположения полезно отслеживать свое предыдущее расположение и иметь возможность вернуться к нему. Командлет Push-Location в Windows PowerShell создает упорядоченный журнал («стек») путей к каталогам, которые вы открывали, чтобы можно было вернуться по нему на шаг назад, используя дополнительный командлет Pop-Location.
Например, Windows PowerShell обычно запускается в корневом каталоге пользователя.
PS> Get-Location Path ---- C:\Documents and Settings\PowerUser
Чтобы передать текущее расположение в стек, а затем переместить его в папку локальных параметров, введите:
Push-Location -Path "Local Settings"
После этого можно передать расположение локальных параметров в стек и переместить его в папку Temp, введя следующее:
Push-Location -Path Temp
Чтобы убедиться, что каталоги изменены, введите команду Get-Location.
PS> Get-Location Path ---- C:\Documents and Settings\PowerUser\Local Settings\Temp
После этого можно перейти в последний открытый каталог, введя команду Pop-Location, и проверить изменение, введя команду Get-Location.
PS> Pop-Location PS> Get-Location Path ---- C:\Documents and Settings\me\Local Settings
Как и в случае с командлетом Set-Location, можно включить параметр -PassThru при вводе командлета Pop-Location, чтобы открыть указанный каталог.
PS> Pop-Location -PassThru Path ---- C:\Documents and Settings\PowerUser
Кроме того, можно использовать командлеты расположения с сетевыми путями. Если у вас есть сервер FS01 с общей папкой Public, можно изменить расположение, введя
Set-Location \\FS01\Public
или диспетчер конфигурации служб
Push-Location \\FS01\Public
Чтобы изменить расположение на любой доступный диск, можно использовать команды Push-Location и Set-Location. Например, если у вас есть локальный дисковод компакт-дисков с буквой диска D, содержащий компакт-диск с данными, вы можете изменить расположение на него, введя команду Set-Location D: .
Если дисковод пуст, вы получите следующее сообщение об ошибке:
PS> Set-Location D: Set-Location : Cannot find path 'D:\' because it does not exist.
Методы подписания скриптов
Вы можете подписывать скрипты, которые вы пишете, и скрипты, получаемые из других источников. Перед тем как подписать любой сценарий, проверьте каждую команду, чтобы убедиться в том, что он является надежным для выполнения.
Рекомендации по подписывания кода см. в статье рекомендации по подписываниякода.
Дополнительные сведения о том, как подписать файл скрипта, см. в разделе Set-AuthenticodeSignature.
Командлет, представленный в модуле PKI в PowerShell 3,0, создает самозаверяющий сертификат, подходящий для тестирования. Дополнительные сведения см. в разделе справки по командлету New-SelfSignedCertificate.
Чтобы добавить цифровую подпись в скрипт, необходимо подписать его с помощью сертификата подписи кода. Для подписи файла скрипта подходят два типа сертификатов:
-
Сертификаты, созданные центром сертификации. для платной платы общедоступный центр сертификации проверяет ваше удостоверение и предоставляет сертификат подписи кода. при приобретении сертификата от известного центра сертификации можно предоставить общий доступ к сценарию пользователям на других компьютерах, на которых выполняется Windows, так как эти компьютеры доверяют центру сертификации.
-
Создаваемые сертификаты: можно создать самозаверяющий сертификат, для которого компьютер является центром сертификации, который создает сертификат. Этот сертификат предоставляется бесплатно и позволяет писать, подписывать и выполнять сценарии на компьютере. Однако сценарий, подписанный самозаверяющим сертификатом, не будет выполняться на других компьютерах.
Как правило, самозаверяющий сертификат используется только для подписывания сценариев, написанных для собственного использования, и для подписывания сценариев, получаемых из других источников, которые были проверены как надежные. Он не подходит для сценариев, которые будут совместно использоваться даже в рамках предприятия.
При создании самозаверяющего сертификата обязательно включите усиленную защиту закрытого ключа в сертификате. Это не позволит вредоносным программам подписывать сценарии от вашего имени. Инструкции включены в конце этого раздела.
Deleting Certificates and Private Keys
The cmdlet will remove certificates that you specify. The
dynamic parameter deletes the private key.
Delete a Certificate from the CA store
This command deletes a certificate from the CA certificate store, but leaves
the associated private key intact.
In the drive, the cmdlet supports only the DeleteKey,
Path, WhatIf, and Confirm parameters. All other parameters are
ignored.
Delete a Certificate using a wildcards in the DNS name
This command deletes all certificates that have a DNS name that contains
«Fabrikam». It uses the DNSName parameter of the cmdlet to
get the certificates and the cmdlet to delete them.
Delete private keys from a remote computer
This series of commands enables delegation and then deletes the certificate and
associated private key on a remote computer. To delete a private key on a
remote computer, you must use delegated credentials.
Use the cmdlet to enable Credential Security Service
Provider (CredSSP) authentication on a client on the S1 remote computer.
CredSSP permits delegated authentication.
Use the cmdlet to connect the S1 computer to the WinRM service on
the local computer. When this command completes, the S1 computer appears in the
local drive in PowerShell.
Now, you can use the Set-Item cmdlet in the WSMan: drive to enable the CredSSP
attribute for the WinRM service.
Start a remote session on the s1 computer using the cmdlet, and
specify CredSSP authentication. Saves the session in the variable.
Finally, use the cmdlet to run a command in the
session in the variable. The command uses the DeleteKey
parameter to remove the private key along with the specified certificate.
Delete expired Certificates
This command uses the ExpiringInDays parameter of the
cmdlet with a value of 0 to get certificates in the WebHosting store that have
expired.
The variable containing the returned certificates is piped to the
cmdlet, which deletes them. The command uses the DeleteKey
parameter to delete the private key along with the certificate.
Obtaining a Code Signing Certificate
Before starting to sign PowerShell scripts, you need to obtain a code signing certificate first. In the Microsoft world, code signing certificates are also known as Authenticode certificates.
A code signing certificate is one type of digital certificate whose purpose for signing files. Signing a file or code with a code signing certificate adds proof that the file came from the publisher who signed it.
Where you get a code signing certificate depends on where you intend to deploy or distribute your signed scripts. And as always, the cost is a big factor, too.
- Global / Public – You’ll need a certificate whose issuer is a globally trusted Certificate Authority (CA). Examples of such CAs are GeoTrust and DigiCert. These certificates are not free. For example, a DigiCert Authenticode certificate will set you back $474/year as of this writing.
- Internal / Local Intranet – If you have an internal certificate authority (CA) server, you can request and download a signing certificate from your internal CA server.
- Personal / Development – For personal testing or development use, a self-signed certificate should be fine. This type of signing certificate is what you’ll use in this article.
Динамические параметры
Динамические параметры — это параметры командлета, которые добавляются поставщиком PowerShell и доступны только при использовании командлета на диске с поддержкой поставщика. Эти параметры действительны во всех подкаталогах поставщика сертификатов, но действуют только для сертификатов.
Примечание
Параметры, выполняющие фильтрацию по свойству, также возвращают элементы с пустым значением свойства.
Сертификаты с пустым EnhancedKeyUsageList можно использовать для всех целей.
В PowerShell 6,0 были удалены следующие параметры поставщика сертификата.
- DNSName
- документенкриптионцерт
- EKU
- ExpiringInDays
- SSLServerAuthentication
CodeSigningCert <System.Management.Automation.SwitchParameter>
Этот параметр возвращает сертификаты с подписыванием кода в значении свойства EnhancedKeyUsageList .
DeleteKey <System.Management.Automation.SwitchParameter>
Remove-Item
Этот параметр удаляет связанный закрытый ключ при удалении сертификата.
Важно!
Чтобы удалить закрытый ключ, связанный с сертификатом пользователя в хранилище на удаленном компьютере, необходимо использовать делегированные учетные данные. Командлет поддерживает делегирование учетных данных с помощью параметра CredSSP . Перед использованием с делегированием учетных данных следует учитывать все риски безопасности.
Этот параметр появился в PowerShell 3,0.
ItemType <String>
Этот параметр позволяет указать тип элемента, созданного .
В диске допустимы следующие значения:
- Поставщик Certificate
- Сертификат
- Хранение
- StoreLocation
Отображение содержимого диска Cert:
Эта команда использует командлет для вывода хранилищ сертификатов в расположении хранилища сертификатов CurrentUser.
Если вы не используете диск, используйте абсолютный путь.
Отображение свойств сертификата на диске CERT:
Этот пример получает сертификат с и сохраняет его в переменной.
В примере показаны новые свойства сценария сертификата (DnsNameList, EnhancedKeyUsageList, SendAsTrustedIssuer) с помощью .
Найти все сертификаты соразработки
Эта команда использует CodeSigningCert и Рекурсивные параметры командлета, чтобы получить все сертификаты на компьютере с центром подписывания кода.
Поиск сертификатов с истекшим сроком действия
Эта команда использует параметр ExpiringInDays командлета для получения сертификатов, срок действия которых истекает в течение следующих 30 дней.
Поиск SSL-сертификатов сервера
Эта команда использует параметр SSLServerAuthentication командлета для получения всех SSL-сертификатов сервера в хранилищах My и WebHost.
Поиск сертификатов с истекшим сроком действия на удаленных компьютерах
Эта команда использует командлет для выполнения команды на компьютерах SRV01 и Srv02. Нулевое значение (0) в параметре ExpiringInDays возвращает сертификаты на компьютерах SRV01 и Srv02, срок действия которых истек.
Объединение фильтров для поиска определенного набора сертификатов
Эта команда возвращает все сертификаты в расположении хранилища LocalMachine, которые имеют следующие атрибуты:
- «Fabrikam» в своем DNS-имени
- «Проверка подлинности клиента» в EKU
- значение для свойства SendAsTrustedIssuer
- срок действия не истекает в течение следующих 30 дней.
Свойство NotAfter хранит дату окончания срока действия сертификата.
Creating a Self-Signed Certificate for Code Signing
You’ve read in the previous section that to sign a PowerShell script, you first need a code signing certificate. Since you’ll only be doing personal testing in this tutorial, a self-signed certificate would suffice. But where do you get it?
As the name implies, self-signed means that your local computer will issue a code signing certificate to itself. To generate a self-signed certificate, follow these steps.
1. Open PowerShell as administrator on your computer.
2. Copy the command below and run it in PowerShell. This command uses the cmdlet to create a new code signing certificate. The certificate’s name is ATA Authenticode inside the local computer’s Personal certificate store.
The command also stores the certificate object to the variable for use in the next step.
3. Next, to make your computer trust the new certificate you’ve created, add the self-signed certificate to the computer’s Trusted Root Certification Authority and Trusted Publishers certificate store. To do so, copy the code below and run it in PowerShell.
There are three primary reasons to install the self-signed certificates in three different certificate stores.
- The certificate you created in the Personal certificate store is what you’ll use as the code signing certificate.
- Copying the same certificate to the Trusted Publishers store ensures that your local computer will trust the publisher who signed the script. PowerShell checks for the certificate in this store to validate a script’s signature.
- Finally, adding the self-signed certificate to the Trusted Root Certification Authorities ensures that your local computer trusts the certificates in the Personal and Trusted Publishers stores.
4. To confirm that the certificate with the subject ATA Authenticode is in the Personal, Root, and Trusted Publisher certificate stores, run the commands below in PowerShell.
Confirming the creation of the new self-signed certificate
5. To view the certificate in a GUI instead, open the Certificates Snap-in and look for the certificate you’ve created under the Certificates folder inside the Personal, Trusted Root Certification Authorities, and Trusted Publishers certificate stores.
Viewing certificates in the Microsoft Management Console (MMC)
Moving Certificates
Move all SSL Server authentication certs to the WebHosting store
This command uses the cmdlet to move a certificate from the My
store to the WebHosting store.
will not move certificate stores and it will not move certificates
to a different store location, such as moving a certificate from LocalMachine
to CurrentUser. The cmdlet moves certificates, but it does not move
private keys.
This command uses the SSLServerAuthentication parameter of the
cmdlet to get SSL server authentication certificates in the MY
certificate store.
The returned certificates are piped to the cmdlet, which moves
the certificates to the WebHosting store.
Включение усиленной защиты закрытого ключа для сертификата
При наличии частного сертификата на компьютере вредоносные программы могут подписывать сценарии от вашего имени, что позволяет PowerShell выполнять их.
Чтобы предотвратить автоматический вход от вашего имени, используйте диспетчер сертификатов для экспорта сертификата подписи в файл. диспетчер сертификатов входит в состав пакета SDK для Microsoft .NET, Microsoft Windows SDK и в internet Explorer.
Чтобы экспортировать сертификат, выполните следующие действия.
- Запустите диспетчер сертификатов.
- Выберите сертификат, выданный корневым каталогом локального сертификата PowerShell.
- Нажмите кнопку Экспорт, чтобы запустить мастер экспорта сертификатов.
- Выберите «Да, экспортировать закрытый ключ» и нажмите кнопку «Далее».
- Выберите «включить усиленную защиту».
- Введите пароль и введите его еще раз для подтверждения.
- Введите имя файла с расширением имени PFX-файла.
- Нажмите кнопку «Готово».
Чтобы повторно импортировать сертификат, выполните следующие действия.
- Запустите диспетчер сертификатов.
- Нажмите кнопку Импорт, чтобы запустить мастер импорта сертификатов.
- Откройте файл. pfx, созданный в процессе экспорта.
- На странице Пароль выберите «включить усиленную защиту закрытого ключа», а затем введите пароль, назначенный в процессе экспорта.
- Выберите хранилище личных сертификатов.
- Нажмите кнопку «Готово».
Выбор подходящей кодировки
Различные системы и приложения могут использовать различные кодировки:
- В .NET Standard, в Интернете и в среде Linux теперь в основном используется кодировка UTF-8.
- Во многих приложениях .NET Framework используется UTF-16. По историческим причинам ее иногда называют «Юникод»; сейчас этот термин относится к более широкому стандарту, охватывающему UTF-8 и UTF-16.
- В Windows многие приложения, которые были созданы еще до распространения Юникода, по-прежнему могут по умолчанию использовать Windows-1252.
Кодировки Юникода также используют понятие метки порядка следования байтов (BOM). BOM ставится в начале текста, чтобы декодер мог определить, какая кодировка используется в тексте. Для многобайтовых кодировок BOM также указывает порядок следования байтов кодировки. BOM представляются байтами, которые редко встречаются в тексте в Юникоде. Это позволяет сделать обоснованное предположение, что текст записан в Юникоде, если присутствует метка BOM.
BOM не являются обязательными; в мире Linux они не так популярны, поскольку во всех прочих местах используется надежное соглашение UTF-8. Большинство приложений Linux предполагают, что текстовый ввод кодируется в UTF-8. Хотя многие приложения Linux могут распознавать и правильно обрабатывать BOM, некоторые этого не делают, что приводит к появлению артефактов в тексте, открываемом с помощью этих приложений.
Таким образом:
- Если вы работаете в основном с приложениями Windows и Windows PowerShell, следует предпочтительно использовать такие кодировки, как UTF-8 с BOM или UTF-16.
- Если вы работаете на разных платформах, следует отдавать предпочтение UTF-8 с BOM.
- Если вы работаете главным образом в контексте Linux, следует отдавать предпочтение UTF-8 без BOM.
- Windows-1252 и latin-1 — устаревшие кодировки, которых по возможности следует избегать.
Тем не менее некоторые приложения предыдущих версий в Windows зависят от их. - Также стоит отметить, что подписывание скриптов зависит от кодировки, то есть изменение кодировки в подписанном скрипте потребует повторного подписывания.
Обучение тому, как правильно чему-то научиться в PowerShell
Get-Help # хотя вы можеше использовать алиас на неё, под названием help
get-help New-Item -Examples
get-help files
PS C:\> get-help Files Name Category Synopsis ---- -------- -------- FileSystem Provider Provides access to files and dire... about_profiles HelpFile Describes how to create and use a...
get-help Registry
Маленькие, но очень полезные фишки, которые должны быть в жизни
И так, для тех, кто никогда не был в командной строке
- Нажатие кнопкок вверх и вниз позволяет вам прокручивать историю команд, и выбирать ранее набранные команды.
- Нажатие кнопки вправо, в конце строки, будет посимвольно перенабирать предыдущую команду.
Для тех, кто уже бывал в командных строках
- Ctrl+Home — удаляет всё, начиная с текущей позиции курсора до начала строки
- Ctrl+End — удаляет с курсора и до конца строки
- F7 — показывает окно со списком набранных команд, и позволяет выбрать одну из них.
- Для того, чтобы скопировать что-то в буфер, выделите это мышью и нажмите Enter.
- Для того, чтобы вставить строку из буфера — просто нажмите правую кнопку мыши.
Профили
У каждого пользователя Powershell есть свой профиль. Профиль выглядит как обычный файл со скриптом формата ps1. Открывая консоль Powershell вы автоматически запускаете этот файл и все значения, перечисленные в файле профиля, становятся видимыми для вас. Кроме этого профиль не ограничивается одним пользователем и может использоваться для всех.
Создание
Каждый профиль пользователя хранится в файле «.ps1» и путь до него можно посмотреть используя встроенную переменную:
Вы можете открыть этот файл и вписать в него любую команду. Я использую команду, которая проверит соединение с DNS сервером Google:
Теперь, каждый запуск консоли будет выводить следующее, дополнительное, сообщение:
Отмечу, что это не самый удачный пример т.к. эта команда занимает существенное время на выполнение. Вы вряд ли захотите ждать 4-5 секунд для запуска консоли.
Вам может не будет требоваться отображать подобный результат при каждом запуске. Вы можете поместить эти данные в переменную и затем вызывать ее по мере работы в консоли:
Самый быстрый вариант, при котором вам не нужно будет дожидаться загрузки, это создание функции совмещающей все ваши базовые задачи. Она будет вызываться только при обращении к ней:
Типы профилей
Если посмотреть содержание переменной $Profile более детально, то мы увидим 4 типа профилей:
В выведенной информации можно увидеть понятие ‘host’. Под «хостом» подразумевается программа, которая хостит Powershell. Это может быть стандартная консоль, редактор ISE, VisualStudio и т.д.
Мы так же увидим следующие профили:
- AllUsersAllHosts — профиль для всех пользователей и для всех хостов;
- AllUsersCurrentHost — профиль для всех пользователей и только для текущего хоста;
- CurrentUserAllHosts — профиль для текущего пользователя и для всех хостов;
- CurrentUserCurrentHost — профиль для текущего пользователя и только для этого хоста.
Указанный путь — это место, где уже есть или может быть создан файл. При каждом запуске Powershell проверяет эти пути и читает данные.
Наиболее просто будет понять разницу работы профилей на примере. В каждый файл профиля я поместил команду соответствующую его названию:
Запуск средства разработки Powershell ISE и обычной консоли был следующий:
Как видно, в ISE, отображаются не все профили. Связано это с тем, что консоль Powershell и редактор ISE — это разные хосты. Мы можем увидеть немного отличающиеся профили если запустить эту команду в ISE:
Так же вы можете увидеть дополнительные профили если используете Powershell Core 6/7, VisualStudio и т.д..
Профиль при удаленном подключении
Прямых способов использования профилей при удаленном подключении нет. Есть косвенный способ, который заключается в возможности использования файлов со скриптами в команде «Invoke-Command». Следующий пример демонстрирует такую возможность:
На самом деле эта команда выглядит следующим образом:
Вам так же будет интересно:
Получение одной записи реестра
Если необходимо получить конкретную запись в разделе реестра, можно использовать один из нескольких возможных подходов. Этот пример получает значение DevicePath в .
Вместе с используйте параметр Path, чтобы указать имя раздела и параметр Name, а также имя записи DevicePath.
Get-ItemProperty -Path HKLM:\Software\Microsoft\Windows\CurrentVersion -Name DevicePath
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\
Microsoft\Windows\CurrentVersion
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\
Microsoft\Windows
PSChildName : CurrentVersion
PSDrive : HKLM
PSProvider : Microsoft.PowerShell.Core\Registry
DevicePath : C:\WINDOWS\inf
Эта команда возвращает стандартные свойства Windows PowerShell, а также свойство DevicePath.
Примечание
Хотя содержит параметры Filter, Include и Exclude, их нельзя использовать для фильтрации по имени свойства. Эти параметры относятся к разделам реестра (путям элементов), а не записям реестра. Записи реестра — это свойства элементов.
Другой вариант — использовать средство командной строки Reg.exe. Для получения справки по reg.exe введите в командной строке. Чтобы найти запись DevicePath, используйте reg.exe, как показано в следующей команде:
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v DevicePath
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
DevicePath REG_EXPAND_SZ %SystemRoot%\inf
Также можно использовать объект WshShell COM, чтобы найти некоторые записи реестра, хотя этот метод не работает с большими двоичными данными или именами записей реестра, содержащими такие символы, как \. Добавьте имя свойства с разделителем «\» в путь элемента:
(New-Object -ComObject WScript.Shell).RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath")
%SystemRoot%\inf
