1. Powershell Press Any Key To Continue Delete
2. Powershell Press Any Key To Continue Disable

1. The ReadKey method waits, that is, blocks on the thread issuing the ReadKey method, until a character or function key is pressed. A character or function key can be pressed in combination with one or more Alt, Ctrl, or Shift modifier keys. However, pressing a modifier key.
2. 'Press any key to continue.' GitHub Gist: instantly share code, notes, and snippets.

Powershell Press Any Key To Continue Delete

If you are using a FIDO2 Security Key, such as a YubiKey, you may have run into the issue that you cannot use it to authenticate with your Azure AD account using PowerShell:

As you can see, the needed Sign in with a security key option is missing here.

I've recently created a fork of the WSMan client that PowerShell uses for PSRemoting on non-Windows hosts. For anyone who's tried to use PSRemoting on Linux to target Windows hosts, or even Exchange Online, would probably know the pain of getting it working at all. Another simple solution would be to use: Read-Host -Prompt 'Press any key to continue or CTRL+C to quit' I believe this is a better solution to the currently accepted answer because the requirement of hitting enter on the keyboard. I don't believe hitting enter will accept the UI prompt unless that UI element is in focus.

This is because PowerShell still uses the older Active Directory Authentication Library (ADAL) when prompting for Azure AD credentials. That login prompt is actually rendered using Internet Explorer, and IE will likely never have support for WebAuthN, the protocol that FIDO2 logon requires.

So we have four options:

Wait until PowerShell moves from ADAL to MSAL, and sign in prompts are rendered by a modern browser that supports WebAuthN.

Wait until each PowerShell Module you need starts supporting its own implementation of modern authentication to Azure AD.

Use Cloud Shell, where you can run PowerShell directly in your browser:http://shell.azure.com/powershell

This option works with FIDO2, but a web-based shell has its limitations.

Use Device Authorization Grant Flow to login.

This post explains the last option.

What is Device Authorization Grant Flow

The Device authorization grant flow is usually used when you need to sign in on “input-constrained devices”, such as IoT devices and printers. In this case, we can view PowerShell as a “device”. The sign in flow is initiated on the device, but the user needs to visit a web page (on any device with a browser that hopefully supports WebAuthN) to complete the sign in. Once the user has signed in, the device (or PowerShell window) can get the needed access tokens and refresh tokens.

Initiate the Device Authorization Grant Flow

Run this code in the PowerShell window you want to sign in to Azure AD:

Note: You do not need to register any new app in Azure AD for this to work since we are using the well-known ClientID for Azure AD PowerShell. You do not have to add any custom values for your tenant either, since we use the Common endpoint. This means that you will automatically be redirected to the tenant the user belongs to when signing in.

A code will be shown that you need to enter at the following web page to continue the sign in:

Besides https://microsoft.com/devicelogin, you can also use http://aka.ms/devicelogin. Both will redirect you to https://login.microsoftonline.com/common/oauth2/deviceauth.

Enter the code in the prompt:

Powershell Press Any Key To Continue Disable

As you can see, we are now signing in on a remote device or service.

Be aware that this sign in method can be misused in phishing attempts. Only enter codes you generated yourself!

You can sign in using your regular account name and password, but to sign in using a FIDO2 key, click on Sign-in options:

Now we can use our FIDO2 key to authenticate:

Once authentication is successful, you can close the page in the web browser. The next step (obtaining tokens) will happen in the PowerShell window:

Obtain the tokens

Again, no customization is needed for this script block. We are re-using the device_code from the DeviceCodeRequest we made earlier.

You now have a valid access token in the variable $Token that can be used to authenticate when using Connect-AzureAD. Note that the variable $TokenRequest also contains refresh_token and id_token, if you want to use them.

Connect to Azure AD

When using the Connect-AzureAD cmdlet with an access token, you also need to specify the username you used to authenticate and the TenantId. You can find your TenantID using PowerShell:

or by going to :

Now we are ready to connect to Azure AD:

Now you should be able to run commands from that module, like this one to get the first group:

What if I need to use the Microsoft Graph?

That will also work, but you need to change $Resource variable in the first script block to the Service Endpoint of Microsoft Graph (“https://graph.microsoft.com/”) and repeat the process.

Then you should be able to run queries against the Microsoft Graph, like this one to get the first group:

How about Exchange Online?

For this to work, you need to change both the $Resource and the $ClientID variables in the first script block to:

When you sign in, you will see that you are signing in to Microsoft Exchange Online Remote PowerShell:

After you obtain the token you need to create a new credential object based on your username and the token:

Now you can connect to Exchange Online using these commands:

Thanks

Big thanks to Stefan Schörling (@stefanschorling) for pointing me in the right direction and to Simon Wahlin for his writeup about Device login flow for MS Graph access.