This is the mail archive of the
mailing list for the Cygwin project.
Re: admin privileges when logging in by ssh?
- From: Andrew Schulman <schulman dot andrew at epamail dot epa dot gov>
- To: cygwin at cygwin dot com
- Date: Tue, 04 Oct 2011 11:59:18 -0400
- Subject: Re: admin privileges when logging in by ssh?
- References: <email@example.com> <firstname.lastname@example.org> <20111004094440.GB14728@calimero.vinschen.de>
> On Sep 12 10:24, Andrew Schulman wrote:
> > > When a user with administrative privileges logs in to sshd, it seems that the user is only granted
> > > standard user privileges for that session. Is there a way around that? How can I get the admin
> > > privileges for that session?
> > Winding this up:
> > Password authentication to sshd is all that's needed to be granted the account's admin privileges on
> > login. I was mistaken about UAC: unlike at the console, when you log in by ssh, the account's
> > admin privileges are granted at login, without needing any further authentication to UAC.
> I'm quite puzzeled since password authentication should not be needed.
> This should work with pubkey as well. Please see
> http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview for
> a discussion how setuid works in Cygwin.
> In all cases, password auth and passwordless auth, you should get a full
> admin token. In case of password auth and in the passwordless methods
> 2 and 3, the OS returns a restricted token under UAC, but that token
> has a reference to the full admin token attached. Cygwin fetches this
> token and uses that when switching the user context. In the default
> passwordless method 1, Cygwin creates a token from scratch, which also
> has full admin rights. However, this token has a couple of problems as
> described in http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
> Probably that's what you stumble over.
Thanks for writing up that documentation of user context switching (I
assume it was you who wrote it). It's complex.
So IIUC, sshd by default uses method 1, creating a token from scratch. So
when a user logs in with pubkey authentication, they won't have a logon
session, which means their SID name may be misidentified by native Windows
apps; and they won't have access to password-protected network shares. But
they should still have all of the privileges normally granted to their
I'm not able to test it right now, but what I observed before was that when
a user with the SeBackupPrivilege and SeBackupPrivilege privileges logged
in by password authentication, it could use those privileges (with rsync);
but when it logged in by pubkey authentication, it couldn't. So I agree
that this is puzzling since it doesn't seem to square with the description
above. This is on Windows 7 Home Premium.
I'll test this again when I can, to be sure what I observed is correct. If
you can suggest any diagnostic tools to help identify the available
privileges, that would be helpful. I'll also look into implementing
methods 2 or 3, so I can do away with the password authentication.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple