5

I've read what feels like almost all the Google links on variation of this issue but none of them seem to apply and this is just baffling me.

In addition to my many Linux machines, I have a Windows 10 laptop with Cygwin installed, completely up to date with Windows updates and Cygwin updates via its setup file. It has an admin user (strictly for maintenance) and two non-admin user accounts assigned to the User group (and member of no other groups) for day-to-day operation. All three accounts worked flawlessly for years with Cygwin being able to launch their respective cygwin terminal and/or login to localhost via SSH. This month for some unknown reason, the User1 account stopped being able to launch the Cygwin terminal. Instead it always gets prompted for an administrative password. If you select NO, Cygwin terminal never opens. If you click YES and provide the admin password, you don't actually get logged in as User1 and this is an issue because User1 needs to NOT be Admin AND needs access to its own git files, repos, etcetera to push/pull its updates.

If Admin runs "ssh User1@localhost", it passes password authentication but then immediately gets kicked out with this type of message:


Last login: Sat Apr  1 21:57:31 2017 from ::1
Connection to localhost closed.

Notice that last login confirms the login is successful, but there is always an immediate kick-out. There is no issue running the same command with User2 instead, confirming sshd is working just fine.

Running "login User1" from cygwin terminal via Admin's account results in being prompted for User1's password and after entering successfully, get kicked out again with this message:


Password:
Switching to user User1 failed!

User2 has absolutely no issues doing any of this stuff. And remember, User1 used to be able to do all of this last month and for the past several years.

I reinstalled sshd (even upgraded it via the Cygwin setup file) and re-ran ssh-host-config but nothing seems to help. (And ssh works for Admin and User2.) Here's what I've ALREADY checked.

  • User1 is not in any blacklist in /etc. I confirmed by checking files reported via 

 find /etc -type f -exec grep -il User1 {} \;
  • I've recreated the passwd and group files many times. 

mkpasswd -l > /etc/passwd
mkgroup -l > /etc/group
  • User1's shell is /bin/bash (and not /bin/false or any variation)

User1:*:197609:197121:U-Jack-VAIO\User1,S-1-5-21-2974605114-333831212-2175464639-1001:/home/User1:/bin/bash
User2:*:197610:197121:U-Jack-VAIO\User2,S-1-5-21-2974605114-333831212-2175464639-1002:/home/User2:/bin/bash

  • User1 can log into Windows just fine. (Not disabled nor password expired in compmgmt.msc > Users.)

  • I've deleted the /etc/passwd and /etc/group since they are no longer necessary in current Cygwin.

  • I've confirmed in "Local Users and Groups" that User1's description is blank (which is acceptable and the alternate place for Cygwin to look for /etc/passwd fields when /etc/passwd doesn't exist).

  • The 'Cygwin Terminal.lnk' shortcut is EXACTLY the same shortcut User2 uses with no issues. It lives in /cygdrive/c/Users/Public/Desktop. (It doesn't have the "Run As Administrator" checkbox checked. Yet, User1 gets prompted for the Admin password.)

  • There is nothing in User1's .bashrc or .bash_profile to make it exit. (See next bullet.)

  • User1's /home/User1 permissions are identical to User2's. As a matter of fact, I've even tried moving /home/User1 to another name, creating a new /home/User1 with NOTHING in it (same result) and then copying /etc/skel and changing permissions to chown -R User1:None (same outcome).


drwxr-xr-x+ 1 Admin   None 0 Apr  1 22:07 Admin
drwxr-xr-x+ 1 User1    None 0 Apr  1 21:52 User1
drwxr-xr-x+ 1 User1    None 0 Apr  1 21:56 User1.001
drwxr-xr-x+ 1 User1    None 0 Apr  1 18:05 User1.old
drwxr-xr-x+ 1 User2    None 0 Oct 21 09:36 User2

drwxr-xr-x+ 1 User1  None    0 Apr  1 21:52 .
drwxrwxrwt+ 1 Admin None    0 Apr  2 06:48 ..
-rw-r--r--  1 User1  None 1494 Jan 16 15:07 .bash_profile
-rw-r--r--  1 User1  None 6054 Jan 16 15:07 .bashrc
-rw-r--r--  1 User1  None 1919 Jan 16 15:07 .inputrc
-rw-r--r--  1 User1  None 1236 Jan 16 15:07 .profile
  • I can create a new non-admin User3 in compmgmt.msc > Users and Groups, set a password and then successfully ssh into it just like User2. Cygwin auto-creates User3's home from /etc/skel. If I remove User1's /home/User1 directory, it is not auto-recreated upon login via SSH and then of course, I'm kicked out back to the Admin's shell.

Here is what ssh -vvv User1@localhost vs User2 looks like. I'm only including the part after both authenticate successfully so you can see the difference.


User1:


debug1: Next authentication method: password
User1@localhost's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Sun Apr  2 06:43:18 2017 from ::1
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug3: send packet: type 1
Connection to localhost closed.
Transferred: sent 2248, received 2868 bytes, in 0.1 seconds
Bytes per second: sent 15979.1, received 20386.1
debug1: Exit status 255

Admin@Jack-VAIO ~
$


User2:


debug1: Next authentication method: password
User2@localhost's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Sat Apr  1 20:56:04 2017 from ::1

User2@Jack-VAIO ~
$
  • UPDATE: In latest reinstalls of SSHD with logging enabled, I'm seeing this specific message when I try to ssh as User1:

setreuid 197609: Operation not permitted
setresuid 197609: Operation not permitted

So there you have it. I'm completely baffled. One thing to note, deleting User1 from Windows and recreating is NOT an option as I have many years of configured settings already set up and am NOT recreating that especially when EVERYTHING ELSE works as normal for both User1 and User2. User1 just cannot access its own Cygwin account anymore.

Any ideas of what else to check because I'm fresh out of them.

P.S. Thanks for reading this far.

Improve this question
2

1 Answer 1

Reset to default
1

After further research (here and here) I'm inclined to think the issue is NOT with Cygwin but rather with Windows 10. A light-bulb turned on in my head when I was in User2's Windows account yesterday and noticed I could launch Task Manager without a UAC prompt--something I knew User1 was always prompted for post Windows 10 upgrade from Windows 8 (despite that upgrade taking place almost a year ago during the free upgrade to Win 10 promotion). I figured it was a Windows 10 thing and never thought twice. When I realized it was happening prompt-free for User2 and googled work-arounds to fix it for User1, I found I could use the same work-around for User1's Cygwin issue. It still doesn't answer how User1's account got messed up in the first place, nor how to actually fix it the correct way, but I'm satisfied with this work-around as I can now get my git changes done for User1.

TL;DR

WORK-AROUND:

  • Open command-line (CMD.EXE) and set this variable to stop getting the UAC pop-up prompt:

set __compat_layer=runasinvoker
  • From the same terminal the environment variable was set, launch Cygwin:

c:\cygwin64\bin\mintty.exe
  • To make this permanent for this user (and make the desktop icon work again)

setx __compat_layer "runasinvoker"
  • To make this permanent for all users machine-wide, open admin command-line, then:

setx /m __compat_layer "runasinvoker"
  • And finally, to access git without fixing Cygwin, install "Git Bash".

Caveat: With the User1 account still technically broken, I still cannot use ssh to login but I can at least get to local Cygwin Terminal as User1. Also this work-around does not fix ability to modify User1's Windows User Environment variables via sysdm.cpl GUI (still get UAC prompt and then after only shows Admin's ENV vars instead of User1's) but that's something for the Windows-related Stack Exchange forum now that I know this is a Windows account problem and not Cygwin's. And SETX allows altering user and machine ENV vars from command-line.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.