Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update OpenSSH key management #4788

Closed
wants to merge 8 commits into from
Closed

update OpenSSH key management #4788

wants to merge 8 commits into from

Conversation

konstruktoid
Copy link
Contributor

Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very useful and properly updated to me.
Split diff view: https://github.com/MicrosoftDocs/windowsserverdocs/pull/4788/files?diff=split&w=1

@ghost
Copy link

ghost commented Sep 4, 2020

#sign-off

@ghost
Copy link

ghost commented Sep 4, 2020

(Also looking forward to getting all those similar and related tickets closed.)

@therealkenc
Copy link

The proposed changes will result in hundreds of thousands of developers who have Admin accounts and are trying to ssh from their VM to windows to waste at least an hour (and perhaps more) of their lives (which they will never get back) finding out how to get their remote authorized_keys working.

@ghost
Copy link

ghost commented Sep 5, 2020

@therealkenc : Forgive me for not understanding the issue the way you see it, but are you saying that the proposed change is not useful in this context? If so, do you have a suggestion for what the proposed change should look like to make it useful?

@konstruktoid
Copy link
Contributor Author

Thank you for the the comment @therealkenc, but is there any incorrect information in the PR? Feel free to point them out so I can fix them.

If you read https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_overview in order, you'll come across https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse#initial-use-of-ssh which describes how to connect with a username and password, and you'll finish on "OpenSSH key management"
which states: "Most authentication in Windows environments is done with a username-password pair. This works well for systems that share a common domain. When working across domains, such as between on-premise and cloud-hosted systems, it becomes more difficult." and then proceeds describing User key generation.

@therealkenc
Copy link

The documentation (as modified with the PR) has:

# Appropriately ACL the authorized_keys file on your server
ssh --% user1@domain1@contoso.com powershell -c $ConfirmPreference = 'None'; Repair-AuthorizedKeyPermission C:\Users\user1\.ssh\authorized_keys

This is despite the PR removing lines including:

- * The OpenSSHUtils PowerShell module has been created to set the key ACLs properly, and should be installed on the server

Repair-AuthorizedKeyPermission will cause an error, because OpenSSHUtils is no longer a thing.

image

In any case, the Deploying the public key section does not work for users in the Administrator group, because %userprofile%\.ssh\authorized_keys is not read.

I followed some non-authoritative instructions found here. Which are:

$acl = Get-Acl C:\ProgramData\ssh\administrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$administratorsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Administrators","FullControl","Allow")
$systemRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($administratorsRule)
$acl.SetAccessRule($systemRule)
$acl | Set-Acl

Whether those instructions are appropriate or not I couldn't tell you. They did work here.

The instructions as presented before or after this pull request do not.

Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
@konstruktoid
Copy link
Contributor Author

Thanks for catching this @therealkenc, I've removed the OpenSSHUtils reference in the document.

Regarding users in the Administrator group, I can´t really say if that's the "official" way of doing it, since I don't actually work with Windows systems.

Probably need a verification.

@therealkenc
Copy link

therealkenc commented Sep 7, 2020

Appreciated, thanks. But the proposed changes will result in hundreds of thousands of developers who have Admin accounts and are trying to ssh from their VM to Windows to waste at least an hour (and perhaps more) of their lives (which they will never get back) finding out how to get their remote authorized_keys working.

To be clear, that's the common (not exceptional) case. Most every developer using Docker or WSL or Hyper-V to ssh into Windows is going to give themselves Admin privs.

Since I am here, the statement at the top of the page doesn't make sense:

Most authentication in Windows environments is done with a username-password pair.

I don't know how that got in there, but there is no basis for the premise that Windows users, for reasons unexplained, prefer to enter a password every time they type ssh versus Linux users or MacOS users.

Co-authored-by: Trond B. Krokli <38162891+illfated@users.noreply.github.com>
@konstruktoid
Copy link
Contributor Author

Most authentication in Windows environments is done with a username-password pair. in this context you're right, but I assume (I'm no the original author obviously), that it meant to cover standard Windows logins as well.

Is there a way to switch User -> Administrator (e.g sudo) on the Windows command line? Perhaps that should be the recommended way, if possible.

To move the contents of your public key (~\.ssh\id_ed25519.pub) into a text file called authorized_keys in ~\.ssh\ on your server/host.

This example uses the Repair-AuthorizedKeyPermissions function in the OpenSSHUtils module which was previously installed on the host in the instructions above.
To move the contents of your public key (~\.ssh\id_ed25519.pub) into a text file called authorized_keys in ~\.ssh\ on your server.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is ssh-copy-id still not part of the Win32 port of OpenSSH?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not on my Windows 10 installation at least.

@ghost
Copy link

ghost commented Sep 8, 2020

Most authentication in Windows environments is done with a username-password pair. in this context you're right, but I assume (I'm no the original author obviously), that it meant to cover standard Windows logins as well.

Is there a way to switch User -> Administrator (e.g sudo) on the Windows command line? Perhaps that should be the recommended way, if possible.

Myself, I have only used the GUI method of "Run as administrator", but there are other suggestions found elsewhere:

runas /noprofile /user:Administrator cmd (to start a command shell as an administrator)

@ghost
Copy link

ghost commented Sep 15, 2020

@therealkenc : Sorry about the confusion. The documentation makes it look like RunAs is outdated and/or deprecated: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771525(v=ws.11) -- the command is available in Windows 10, though:

Microsoft Windows [Version 10.0.19041.388]
(c) 2020 Microsoft Corporation. All rights reserved.

C:\Users\illfated>runas
RUNAS USAGE:

RUNAS [ [/noprofile | /profile] [/env] [/savecred | /netonly] ]
        /user:<UserName> program

RUNAS [ [/noprofile | /profile] [/env] [/savecred] ]
        /smartcard [/user:<UserName>] program

RUNAS /trustlevel:<TrustLevel> program

   /noprofile        specifies that the user's profile should not be loaded.
                     This causes the application to load more quickly, but
                     can cause some applications to malfunction.
   /profile          specifies that the user's profile should be loaded.
                     This is the default.
   /env              to use current environment instead of user's.
   /netonly          use if the credentials specified are for remote
                     access only.
   /savecred         to use credentials previously saved by the user.
   /smartcard        use if the credentials are to be supplied from a
                     smartcard.
   /user             <UserName> should be in form USER@DOMAIN or DOMAIN\USER
   /showtrustlevels  displays the trust levels that can be used as arguments
                     to /trustlevel.
   /trustlevel       <Level> should be one of levels enumerated
                     in /showtrustlevels.
   program         command line for EXE.  See below for examples

Examples:
> runas /noprofile /user:mymachine\administrator cmd
> runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"
> runas /env /user:user@domain.microsoft.com "notepad \"my file.txt\""

NOTE:  Enter user's password only when prompted.
NOTE:  /profile is not compatible with /netonly.
NOTE:  /savecred is not compatible with /smartcard.

C:\Users\illfated>_

@therealkenc
Copy link

The confusion stems from the irrelevance of runas, not its usage.

@PRMerger12
Copy link
Contributor

@konstruktoid : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@PRMerger18
Copy link
Contributor

@konstruktoid : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@konstruktoid
Copy link
Contributor Author

@ghost
Copy link

ghost commented Nov 19, 2020

So, does this mean that we are drawing closer to a conclusion? If so, that would be good news for final review & merge. Any remaining issues at the moment?

@therealkenc
Copy link

Any remaining issues at the moment?

Yes; the documentation as presented does not work for any user in the local Administrator group, because %USERPROFILE%/.ssh will not be read. Non-authoritative citation here. Noting that a plurality of developers using VMs with ssh (in both directions) have admin privs.

image

A user with admin privs will make it to the concluding sentence "After this, the user can connect to the sshd host from any client that has the private key" to find their keys do not work.

@ghost
Copy link

ghost commented Nov 21, 2020

Ok, fair enough. Thank you for the feedback.

@konstruktoid : Do you have any thoughts on how to address that issue?

@konstruktoid
Copy link
Contributor Author

Sorry I don't, that´s too much Windows for me.

@ghost
Copy link

ghost commented Nov 21, 2020

Fair enough. We should aim for a conclusion to this PR anyway.

@therealkenc :: Is it fair to say that you are still opposed to the current PR and that you would like to make your own PR for the necessary changes, if you know what should be added to make it work for administrators like you?

@therealkenc
Copy link

if you know what should be added to make it work for administrators like you?

That question was answered in September: "Whether those instructions are appropriate or not I couldn't tell you."

@esc
Copy link

esc commented Dec 1, 2020

I reported https://github.com/MicrosoftDocs/windowsserverdocs/issues/5068 -- and I can confirm that some kind of permission fix is need and the state of the documentation before and after this PR is not functioning. The permissions of the authorized_keys files are broken after adding a key.

@esc
Copy link

esc commented Dec 1, 2020

I can confirm that the options listed in https://www.concurrency.com/blog/may-2019/key-based-authentication-for-openssh-on-windows and by @therealkenc worked for me

@esc
Copy link

esc commented Dec 1, 2020

FWIW: I spent 8 hours to debug this

@ghost
Copy link

ghost commented Dec 1, 2020

Thank you very much for the effort and for your feedback. That is both welcome and very worthwhile to us.

@ghost
Copy link

ghost commented Dec 19, 2020

Updated list of related issue tickets:

  • #2747 A better explanation can be found here (Open)
  • #3400 Can't install the "OpenSSHUtils" (Closed)
  • #3456 Misleading title/summary causing search confusion (Open)
  • #3806 OpenSSHUtils is deprecated (Open)
  • #3970 OpenSSH installation (Closed)
  • #4345 OpenSSHUtils Not Needed (Open)
  • #4518 Unable to configure OpenSSH for public key auth following docs (Open)
  • #4598 Instructions provided ends with an error (Open)
  • #4622 Out-of-date - OpenSSHUtils no longer available. (Open)
  • #4634 More documentation required (Open)
  • #4690 OpenSSHUtils install reference no longer valid (Open)
  • #4702 OpenSSHUtils got unlisted from the PowerShell gallery (Open)
  • #4743 Nope. First example errors out. (Open)
  • #4770 Error when following instructions to install OpenSSHUtils (Open)
  • #4787 OpenSSHUtils module does not exist (Open)
  • #5000 Clarification needed (Open)
  • #5138 These instructions do not work on Windows 10 20h2 (Open)

@konstruktoid
Copy link
Contributor Author

Updated list of related issue tickets:

* #2747 **A better explanation can be found here** (Open)

* #3400 **Can't install the "OpenSSHUtils"** (Closed)

* #3456 **Misleading title/summary causing search confusion** (Open)

* #3806 **OpenSSHUtils is deprecated** (Open)

* #3970 **OpenSSH installation** (Closed)

* #4345 **OpenSSHUtils Not Needed** (Open)

* #4518 **Unable to configure OpenSSH for public key auth following docs** (Open)

* #4598 **Instructions provided ends with an error** (Open)

* #4622 **Out-of-date - OpenSSHUtils no longer available.** (Open)

* #4634 **More documentation required** (Open)

* #4690 **OpenSSHUtils install reference no longer valid** (Open)

* #4702 **OpenSSHUtils got unlisted from the PowerShell gallery** (Open)

* #4743 **Nope. First example errors out.** (Open)

* #4770 **Error when following instructions to install OpenSSHUtils** (Open)

* #4787 **OpenSSHUtils module does not exist** (Open)

* #5000 **Clarification needed** (Open)

* #5138 **These instructions do not work on Windows 10 20h2** (Open)

Will those issues be closed as well if this PR is merged?

@ghost
Copy link

ghost commented Dec 20, 2020

If you update your list of "Closes #xxxx" to include all of them, they should normally be closed, yes.

Otherwise, they can be closed manually by commenting #please-close (non-encapsulated, of course), since the bots have been scripted to react to that command string.

edit: The closing comment command feature has only been implemented in this repository (windowsserverdocs) as far as I know.

edit 2: Maybe you know this already, but if you add more issue ticket numbers to your closing list, the text "May be fixed by #4788 " is added to the top of each page.

@konstruktoid
Copy link
Contributor Author

Yeah, I should rephrase that. Are all those issues supposed to get closed by this PR?

1 similar comment
@konstruktoid
Copy link
Contributor Author

Yeah, I should rephrase that. Are all those issues supposed to get closed by this PR?

@ghost
Copy link

ghost commented Dec 21, 2020

Oh. I see. Maybe, maybe not. I guess I was a bit hasty to draw the conclusion that the new ones are directly related. The tickets are from the same MS Docs page.

@Diablo-D3
Copy link

Just to throw this in here, on 202H, the only thing I need to run is icacls.exe "$($env:USERPROFILE)/.ssh/authorized_keys" /inheritance:r /grant "$($env:USERNAME):F" /grant "NT AUTHORITY\SYSTEM:F" in an elevated Powershell to fix my authorized_keys. This seems to be functionally identical to the proposed change in documentation for this step.

@gbraad
Copy link

gbraad commented Mar 8, 2021

The instruction suggest a scp to the authorized_keys file... which will blow away any previous entries. It is common for this file to contain multiple keys, hence the pluralized name.


So far none of the 'proposed' steps have worked for me.

@konstruktoid
Copy link
Contributor Author

The instruction suggest a scp to the authorized_keys file... which will blow away any previous entries. It is common for this file to contain multiple keys, hence the pluralized name.

But the keys in the authorized_keys file should only be yours and yours alone, @gbraad, and the management and responsibility is up to the user.
Otherwise a server configuration management system should be used.

@konstruktoid
Copy link
Contributor Author

Just out of curiosity.
When and why use multiple keys, each representing a different host or group of users, for the same account?
And if management of users accounts, access policies,authorized_keys etc is getting overly complicated (or just a daily repetition) perhaps is should be (semi-)automated.

@gbraad
Copy link

gbraad commented Mar 8, 2021

That is not what I refer to. The action describes a scp, while normally we add a key. This is also part of the responsibility of something like ssh-copy-id, a helper script on most distros to 'add' to the authorized keys.

This is why overwriting the content with a copy will leave only one user remaining. It lacks explanation what the users should do.

Note: message was prematurely sent. Was in the action of editing (while picking up the kid)

@konstruktoid
Copy link
Contributor Author

konstruktoid commented Mar 8, 2021

Ah, @gbraad, that is true. The issue is I believe is that ssh-copy-id isn't present on Windows 10.

@ghost
Copy link

ghost commented Mar 27, 2021

The following issue tickets (including both open and closed tickets) originate from the same document page as the one targeted by this PR:

  • OpenSSHUtils is deprecated -- #3806 opened on Jan 28, 2020 by FizzBuzz791
  • PubKey Auth not working [solution] -- #3828 opened on Jan 31, 2020 by ackvf
  • Outdated instructions? -- #4023 by RussKeldorph was closed on Sep 2, 2020
  • OpenSSHUtils Not Needed -- #4345 opened on May 14, 2020 by gynnantonix
  • Unable to configure OpenSSH for public key auth following docs -- #4518 opened on Jun 20, 2020 by jaraco
  • Instructions provided ends with an error -- #4598 opened on Jun 28, 2020 by jyavenard
  • Out-of-date - OpenSSHUtils no longer available. -- #4622 opened on Jul 8, 2020 by Jammrock
  • More documentation required -- #4634 opened on Jul 11, 2020 by garylawuk
  • OpenSSHUtils install reference no longer valid -- #4690 opened on Aug 1, 2020 by wrjohnson
  • OpenSSHUtils got unlisted from the PowerShell gallery -- #4702 opened on Aug 5, 2020 by jagraveldinger
  • Does not list possible ssh commands -- #4726 opened on Aug 16, 2020 by morgzz
  • ssh-agent service not installed upon installation of OpenSSH Server or Client -- #4729 by ThatNerdyPikachu was closed on Oct 10, 2020
  • Nope. First example errors out. -- #4743 opened on Aug 22, 2020 by boomalator
  • Error when following instructions to install OpenSSHUtils -- #4770 opened on Aug 31, 2020 by c0f
  • OpenSSHUtils module does not exist -- #4787 opened on Sep 4, 2020 by oliversalzburg
  • Does not explain how to ensure keys get reloaded to agent on boot -- #4858 opened on Sep 30, 2020 by g24swint
  • Private keys from the ssh-agent can be accessed -- #4871 opened on Oct 2, 2020 by stefanfritsch
  • Install-Module OpenSSHUtils failure -- #4893 opened on Oct 8, 2020 by LeeJenkins
  • Does ssh-agent on windows have persistent storage of ssh keys? -- #4946 opened on Oct 27, 2020 by zaaj
  • OpenSSHTools doesn't exist anymore on powershell gallery -- #4948 opened on Oct 28, 2020 by JustinGrote
  • Clarification needed -- #5000 opened on Nov 10, 2020 by conyg
  • OpenSSHUtils has been delisted -- #5068 by esc was closed on Dec 1, 2020
  • Update suggestion of OpenSSHUtils -- #5080 by aamir0 was closed on Dec 4, 2020
  • These instructions do not work on Windows 10 20h2 -- #5138 opened on Dec 19, 2020 by mihai-preda
  • Out of date - Repair-AuthorizedKeyPermission -- #5395 opened 4 days ago by nekdima
  • Error: No match was found for the specified search criteria and module name 'OpenSSHUtils' -- #5408 opened 23 hours ago by JoshSnider

Some of these may be not specific to this PR content, but I thought it would be useful to see how much attention this page has received since January 28, 2020 (more than a year ago).

@dknappettmsft
Copy link
Contributor

dknappettmsft commented Jun 4, 2021

Thanks for this PR and to everyone for the conversation throughout. I have reworked this document to remove or replace parts that are no longer relevant or correct based on this PR and several other issues raised for this page.

The changes have been done through a different PR, so I'm going to close this one. Please file new issues if needed. The changes should be visible in around 6-12 hours.

#please-close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment