Как настроить powershell для открытого ssh вместо cmd

Switch to PSv7:

• Windows Server 2022 with Windows PowerShell 5.1 and PowerShell 7.2
• Windows Server 2019 with Windows PowerShell 5.1 and PowerShell 7.2
• macOS 11 with PowerShell Core 7.2
• Ubuntu 20.04 with PowerShell Core 7.2

One of the challenges of writing PowerShell scripts is how to handle variables configuration, such as settings, paths, credentials, and other values that may vary depending on the environment or context. In this article, we will explore some best practices for managing variables configuration in a PowerShell project.

Queries the installed versions of PowerShell using Common Information Model (CIM) and filters based on the product name:

Retrieves the PowerShell version as part of the operating system information using CIM:

Lists installed versions of PowerShell using (WMI):

"Name like 'Microsoft PowerShell%'"

Retrieves the PowerShell version as part of the operating system information using WMIC:

wmic os get PowerShellVersion

No scripts are allowed to run, offering the highest security level.
Useful for locked-down environments or when testing untrusted code.

Requires all scripts and configuration files, even those written locally, to be signed by a trusted publisher before execution.
Provides strong security but requires additional setup for signing your own scripts.

Permits execution of scripts downloaded from the internet only if they are signed by a trusted publisher.
Offers a balance between security and functionality, allowing some remote script execution.

No restrictions are in place, allowing all scripts to run without warnings or prompts.
Least secure option, use with caution only in trusted environments.

Sets the execution policy to the default for your system, which is:
Restricted for Windows client operating systems.
RemoteSigned for Windows server operating systems.

Subsystem is not meant to change your default shell, quite the opposite – it defines a command that clients have to explicitly request. (It’s literally a server-side alias.)

So the configuration snippet you found wasn’t meant to change what you get from regular ssh; it’s meant to allow a local PowerShell instance to invoke the SSH client and start a remote PowerShell on the server, without having to know its path (all it needs to specify is the subsystem name).

Specifically, the -sshs option indicates that it’s meant for PSRemoting over SSH using the Enter-PSSession or Invoke-Command cmdlets, which can run via SSH in PowerShell 7.

PS> Enter-PSSession -HostName otherpc
[otherpc] PS>

(-HostName option makes it use SSH, whereas -ComputerName makes it use WinRM.)

(This won’t work in PowerShell 5 – its PSRemoting support can only run via WinRM, though if you want PowerShell then WinRM is actually not a bad alternative to SSH.)

Actually changing the default shell in Windows OpenSSH (the official Microsoft builds) is done completely differently – it’s documented on this page:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" `
                 -Name DefaultShell `
                 -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" `
                 -PropertyType String `
                 -Force

Jordan had spent his life wondering why tasks he didn’t like to do had no options to complete themselves. Eventually he had to make that happen on his own. It turned out that he enjoyed making tasks complete themselves, and PDQ thought that is something he should talk about on the internet.

If you run the same commands every time you launch the PowerShell console, then it’s probably time to customize your PowerShell profile for a smoother scripting experience.

When you develop a profile in PowerShell, you define your settings as a PowerShell script to make the process easier. In this article, learn about the PowerShell profile, how to edit your profile for any PowerShell console — the newer cross-platform PowerShell 7, Windows PowerShell 5.1, Visual Studio (VS) Code and PowerShell Integrated Script Environment (ISE) — and several handy additions for your profile.

How to access your PowerShell profile

The easiest way to retrieve the PowerShell profile is through PowerShell itself. You don’t need to remember the profile paths because they are stored in the variable.

$Profile | Get-Member -MemberType NoteProperty

$Profile.AllUsersAllHosts

$Profile.CurrentUserCurrentHost

code $Profile.CurrentUserCurrentHost

Function Prompt {
    $endChar = '>'
    # check if running as admin
    If
(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
        $endChar = '#'
    }
    @"
$PWD
PS$endChar
"@
}

Connect-Graph

$graphUserProps = @(
    'BusinessPhones',
    'DisplayName',
    'GivenName',
    'Id',
    'Mail',
    'PreferredLanguage',
    'Surname',
    'UserPrincipalName'
)

Get-MgUser -UserId <upn> -Select ($graphUserProps + 'AccountEnabled','UsageLocation')

New-Alias -Name gmu -Value Get-MgUser

New-Alias -Name k -Value kubectl

. C:\path\to\Function.ps1

Use Parameters

A third way to manage variables configuration is to use parameters. Parameters are arguments that are passed to a PowerShell script or function when it is invoked. Parameters allow you to specify input values for your script or function without hard-coding them in the code. You can define parameters for your script or function using the param keyword at the beginning of the script or function body. For example:

# Use the parameters

Then, you can pass values to the parameters when you call the script or function. You can do this using various methods, such as:

• Using named parameters. For example:

• Using positional parameters. For example:

• Using splatting. Splatting is a way of passing a collection of parameter values to a script or function using a single variable. The variable can be an array, a hash table, or a custom object. For example:

# Define a hash table with parameter names and values

Using parameters has some advantages:

• It allows you to pass different configuration values to your script or function without modifying the code.
• It enables you to validate the parameter values using attributes such as [ValidateSet], [ValidatePattern], [ValidateRange], etc.
• It supports default values, mandatory values, dynamic values, and other features that make your script or function more flexible and robust.

However, using parameters also has some drawbacks:

• It may not be convenient or feasible to pass parameters for every configuration value you need.
• It may expose the configuration values in plain text on the command line, which may pose a security risk if they contain sensitive information such as passwords or keys.
• It may require you to write additional code to handle parameter binding, parsing, error handling, etc.

PowerShell Execution Policy

Queries the registry for the execution policy setting:

Retrieves the execution policy setting from the registry:

Generates an HTML report containing the Group Policy settings, including the PowerShell execution policy, and opens it in the default web browser:

h result.html && start result.html

Example scripts

You can also open the examples from the Command Palette ( (Windows, Linux )) with
the PowerShell: Open Examples Folder command.

Use Environment Variables

Another way to manage variables configuration is to use environment variables. Environment variables are variables that are defined by the operating system or by other applications and are available to all processes running on the system. PowerShell can access environment variables using the env: drive, which is a special provider that exposes environment variables as a hierarchical namespace. For example, you can access the PATH environment variable using $env:PATH.

To use environment variables for your configuration values, you need to define them before running your PowerShell script. You can do this using various methods, such as:

• Using the Set-Item cmdlet on the env: drive. For example:

• Using the setx command-line tool. For example:

• Using the graphical user interface of your operating system. For example, on Windows 10, you can go to Settings > System > About > Advanced system settings > Environment Variables.

Using environment variables has some advantages:

• It avoids storing the configuration values in plain text files, which may improve security.
• It allows you to change the configuration values without modifying your PowerShell script or other scripts that use them.
• It enables you to have different configuration values for different users or sessions on the same system.

However, using environment variables also has some drawbacks:

• It may not be convenient or feasible to define environment variables for every configuration value you need.
• It may cause conflicts or errors if different scripts use environment variables with the same name but different meanings.
• It may not be portable across different systems or platforms that have different environment variables or naming conventions.

My favorite approach

For my project I would like to use a typical config file with a key-value-pair for each line.
Something like this:

tenantID=this is my tenant
clientID=client id
clientSecret=my secrets
tenantName=Contoso.com

There isn’t an official way to do that in PowerShell directly.
So, you have to create a small portion of code to load the config file content and set the variable names and values.

I created a function for a better approach and maintenance of the code.
In this foreach, the code set a variable with the same name of the config key and the value with everything in the row after the = character.
In order to use the variables in all the scripts in your project and modules, the script sets the scope as global.

Using the variables is very easy, you just need to add the dollar symbol on a variable with the same name of the config key.
From the previous example you can have:
$tenantID, $clientID and so on.

You can call the function Load-Config at the beginning of your script. In this case you can be sure that all the script and functions have access to the variables.

Additional resources

There are more detailed articles in the PowerShell documentation. Start with Using VS Code.

Check out the troubleshooting guide for answers to common questions.

Use a Configuration File

One of the simplest and most common ways to manage variables configuration is to use a configuration file. A configuration file is a PowerShell script that defines global variables that can be used by other scripts in the project. For example, you can create a file named Config.ps1 and put all your configuration variables in it, such as:

# Dot-source the configuration file# Use the configuration variables

Using a configuration file has some advantages:

• It separates the configuration from the logic, making the code more readable and maintainable.
• It allows you to change the configuration values without modifying the main script or other scripts that use them.
• It enables you to have different configuration files for different environments or scenarios, such as development, testing, production, etc.

However, using a configuration file also has some drawbacks:

• It exposes the configuration values in plain text, which may pose a security risk if they contain sensitive information such as passwords or keys.
• It requires you to manually copy or deploy the configuration file along with your main script or other scripts that use it.
• It may cause conflicts or errors if different scripts use different configuration files or define variables with the same name.

Installing the PowerShell extension

The PowerShell extension can be installed from the Visual Studio Code Marketplace by clicking the
Install Button. You can also install the PowerShell extension from within VS Code by opening
the Extensions view with keyboard shortcut (Windows, Linux ), typing PowerShell,
and selecting the PowerShell extension:

PowerShell extension settings

You can customize VS Code settings from the File > Preferences > Settings menu item.

You can also select the gear icon located in the lower left corner of the Activity Bar.

Types.ps1xml and Format.ps1xml files

• Syntax error reporting
• Schema validation
• Tag and attribute completion
• Autoclose tags
• Symbol highlighting
• Document folding
• Document symbols and outline
• Renaming support
• Document formatting

Major features

• Syntax highlighting
• Advanced built-in code snippets
• IntelliSense for cmdlets and more
• Problems reported by PowerShell Script Analyzer
• Go to Definition of cmdlets, variables, classes and more
• Find References of cmdlets, variables, classes and more
• Document and Workspace Symbol Navigation
• Symbol-based Outline View
• Run selected PowerShell code in current terminal using
• Launch online help for the symbol under the cursor using Ctrl + F1
• PowerShell Debugger integration
• An Extension Terminal that can interact with the debugger (try Set-PSBreakpoint!)
• PowerShell ISE theme findable in the theme picker
• Also try ISE mode using (Windows, Linux ) then search for “Enable ISE Mode”

Debugging

Multi-version support

Or run the PowerShell: Show Session Menu command from the Command Palette
( (Windows, Linux )).

CodeLens support

CodeLenses are a VS Code feature to provide actionable, contextual information that’s displayed
within the source code.

CodeLens features include:

• Pester Run tests and Debug tests.

  

• Pester symbol support

  

• Function, variable, class, and other symbol references

  CodeLens reference support shows the number of times a symbol is referenced within your
  code and allows you to jump to specific references.

  

PSScriptAnalyzer integration

The PowerShell extension includes PSScriptAnalyzer by default, and automatically performs
analysis on PowerShell script files you edit in VS Code.

PSScriptAnalyzer comes with a collection of built-in rules that check various aspects of
PowerShell source code such as presence of uninitialized variables, usage of PSCredential type,
usage of Invoke-Expression, and others. The module also allows you to include or exclude specific
rules.

To disable PSScriptAnalyzer, open your settings ( (Windows, Linux )), browse
Extensions, select the PowerShell extension, and deselect the checkbox for Script
Analysis: Enable (powershell.scriptAnalysis.enable).

PSScriptAnalyzer also provides code formatting. You can invoke automatic document formatting
with the Format Document command or the ( (Windows , Linux )) keyboard shortcut.

Pester integration

Plaster integration

Plaster is a template-based file and project generator written in PowerShell. Its purpose is
to streamline the creation of PowerShell module projects, Pester tests, DSC Configurations and more.

The PowerShell extension allows the creation of new Plaster projects using the PowerShell: Create
New Project from Plaster Template command from the Command Palette
( (Windows, Linux )).

Testing new features and providing feedback

If you find a bug, open an issue and revert to the stable version while we fix it.

Conclusion

• Use descriptive and specific names for your configuration variables.
• Use Pascal case for your configuration variable names.
• Use standard parameter names or aliases for your script or function parameters.
• Use splatting to pass multiple parameter values to your script or function.
• Store sensitive information such as passwords or keys in secure locations such as Windows Credential Manager or Azure Key Vault.

Похожее:

Управление VirtualBox из командной строки | Информационный портал К2® Руководство по команде setblock — Официальная Minecraft Wiki Batch-file Comments in Batch Files Точки останова и пошаговые сценарии отладки в power shell