SSH login has full admin rights and there's no way to not grand them

[realnc]

Please answer the following

"OpenSSH for Windows" version
7.7.2.2

Server OperatingSystem
Windows 10 Pro

Client OperatingSystem
Linux

What is failing
SSH login has admin rights.

When I log in through SSH to Windows 10, the log in has full admin rights. For example I write to C:\Windows. There should be a way to prevent this, but there doesn't seem to be one. If one of my tools/scripts/etc does something stupid, I could wipe out my system. There should be a way to get a login that is the same as when double-clicking on "cmd.exe", which gives you a non-admin command line.

The documentation says that to disable admin login, I should use DenyGroups Administrators. That is a non-solution, as then I can't log in and I get an permission denied ssh error.

[bagajjal]

For admin users, ssh connection is an elevated session. Given you are an admin and has elevated session, you can write to c:\windows.

This is by design.

[realnc]

@bagajjal Is it possible to prevent this and not get an elevated session? Or run OpenSSH without admin rights so that the sessions it creates are not elevated?

[bagajjal]

You can choose to go with non-admin user.
Admin users requires elevated session to perform admin operations..

[oocx]

In a regular Windows session, for example when I work locally with cmd.exe / powershell / bash, I can work with non-admin privileges even though my user is an administrator. I explicetely need to grant an application elevated privileges in an UAC prompt. With ssh, I'm always elevated by default. It should be possible to use ssh with an admin user in an unelevated session.

I understand that this is currently not supported. So please consider this a feature request that would make working with ssh on Windows more secure by default :).

[jborean93]

The biggest issue when you were to use the limited token after an SSH logon is that you cannot then get your elevated token. On an interactive logon you can right click and say Run as administrator and confirm through the UAC prompt but on a network logon like SSH there is no way for UAC to prompt you. So if this was a functionality you will never be able to swap from the limited to full token of your admin account.

[shoaniki]

The current design also causes problems, though. For example, I cannot SSH to my Windows 10 box and access mapped drives without jumping through hoops, because mapped drives are not accessible in elevated command prompts.

Please just provide the option.

[jborean93]

@shoaniki the mapped drive problem is unrelated to being an admin. They just aren’t mapped on a network logon session. You will find even if you set the registry key to share mapped drives between the limited and admin session you will not see them when logging on through ssh.

[shoaniki]

oh right! thanks for the explanation and sorry for the noise then.

[jborean93]

No worries, it’s a common problem but the reasoning behind it is complex so you’re not alone :)

[t-m-w]

The biggest issue when you were to use the limited token after an SSH logon is that you cannot then get your elevated token.

Perhaps this could be managed by authenticating with a different key? (This would require an option to be present to adjust this behavior.) However, I think some of us would be fine with being unable to perform admin functions over ssh on certain accounts that are in the Administrators group, and create a new admin account for that situation.

You can choose to go with non-admin user.
Admin users requires elevated session to perform admin operations..

This perspective runs counter to the existence of UAC in Windows at all. Yes, one can create a non-admin user, but it requires entire workflow changes.

Please add an option to disable the forced elevation of users in the Administrators group.

Alternatively, is there a method/command to de-elevate? I've tried runas /trustlevel:0x20000 and it doesn't work in an ssh session (usually pops up a new window).

[weichensw]

This also makes docker for windows not useable over SSH because docker login doesn't work in elevated shell.

[rmyorston]

FYI, the latest release of BusyBox for Windows includes an applet to drop privileges.

To use it standalone download the latest binary, either the 64-bit (busybox64.exe) or 32-bit (busybox.exe) version, as appropriate. Put it somewhere it can be executed, renamed as drop.exe, cdrop.exe or pdrop.exe. When run without arguments:

• drop starts an interactive BusyBox shell without elevated privileges
• cdrop does the same for cmd.exe
• pdrop does likewise for PowerShell

Each variant also supports the -c option to allow a single command to be run without elevated privileges.

An SSH session invoking pdrop:

See also:

• The release notes for more details regarding drop.
• My BusyBox for Windows page for general busybox-w32 information.