この問題のバリエーションに関するほとんどすべてのGoogleリンクを読みましたが、それらのどれも適用されていないようで、混乱しています。
多くのLinuxシステムに加えて、インストールファイルを介してWindowsアップデートとCygwinアップデートで完全にアップデートされるCygwinがインストールされたWindows 10ノートブックがあります。これには、管理ユーザー（厳密にメンテナンス用）と日常業務のためにユーザーグループ（他のグループのメンバーではない）に割り当てられている2つの非管理ユーザーアカウントがあります。 3つのアカウントはすべて長年にわたって完全に機能しており、Cygwinはそれぞれのcygwin端末を起動したり、SSHを介してlocalhostにログインしたりできました。今月は未知の理由で、User1アカウントはCygwin端末を起動できません。代わりに、常に管理パスワードの入力を求められます。 「いいえ」を選択した場合、Cygwin端末は開かれません。 「はい」をクリックして管理者パスワードを入力すると、実際にはUser1としてログインしません。これは、User1が管理者である必要がなく、プッシュ/プッシュのために自分のgitファイル、リポジトリなどにアクセスする必要があるために問題になります。アップデートを取得します。
管理者が「ssh User1@localhost」を実行すると、パスワードの確認に合格しますが、次の種類のメッセージですぐに追い出されます。
Last login: Sat Apr 1 21:57:31 2017 from ::1
Connection to localhost closed.
最後のログインは成功したログインを確認しますが、常にすぐにログアウトされます。 User2と同じコマンドを実行すると、sshdが正しく機能していることを確認するのに問題はありません。
管理者アカウントを介してcygwin端末で「login User1」を実行すると、User1のパスワードを入力するように求められます。
Password:
Switching to user User1 failed!
User2は、これらのタスクを実行するのに全く問題はありません。 User1は、先月と過去数年間でこれらすべての作業を実行できました。
sshdを再インストールし（Cygwinインストーラを介してアップグレードすることもできます）、ssh-host-configを再実行しましたが、何も役に立たないようです。 （sshはAdminとUser2で動作します。）私が確認したものは次のとおりです。
- User1は/ etcのブラックリストにありません。報告されたファイルを確認して確認しました。
find /etc -type f -exec grep -il User1 {} \;
- パスワードとグループファイルを何度も再作成しました。
mkpasswd -l > /etc/passwd
mkgroup -l > /etc/group
- User1のシェルは/bin/bashです（/bin/falseまたは他のバリエーションではありません）。
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はWindowsに正常にログインできます。 （compmgmt.msc>ユーザーは無効にされず、パスワードは期限切れになりません。）
/etc/passwdと/etc/groupをそのまま削除しました。現在、Cygwinではもう必要ありません。。
ローカルユーザーとグループで、User1の説明が空であることを確認しました（これは許可されており、/ etc / passwdが存在しないときにCygwinが/ etc / passwdフィールドを見つけるための代替場所です）。
"Cygwin Terminal.lnk"ショートカットは、User2が使用するショートカットと問題なく同じです。これは /cygdrive/c/Users/Public/Desktop にあります。 （「管理者として実行」チェックボックスを選択しません。ただし、User1には管理者パスワードの入力を求められます。）
User1 の .bashrc または .bash_profile に終了を引き起こす内容はありません。 （次の箇条書きを参照してください。）
User1の/home/User1権限は、User2の権限と同じです。実際、/home/User1を別の名前に移動し、何も含まない新しい/home/User1を作成し（同じ結果）、/ etc / skelをコピーして権限をchownに変更しようとしました。 - R User1: None（同じ）結果）。
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
- compmgmt.msc>ユーザーとグループに管理者ではなく新しいUser3を作成し、パスワードを設定してから、User2のようにsshを正常に使用できます。 Cygwinは/etc/skel.confからUser3のホームを自動的に作成します。 User1の/home/User1ディレクトリを削除すると、SSHを介してログインしたときに自動的に再生成されず、もちろん管理者シェルに戻ります。
これがssh -vvv User1@localhostがUser2の外観です。違いを確認できるように、検証が成功した後にのみその部分を含めました。
ユーザー1：
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 [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] 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 [email protected] 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 ~
$
ユーザー2：
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 [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] 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 ~
$
- 更新：最近のログ記録が有効になっているSSHDの再インストールからUser1でSSHを試みると、次の特定のメッセージが表示されます。
setreuid 197609: Operation not permitted
setresuid 197609: Operation not permitted
だからそこにあります。私は完全に混乱しています。注目すべき点の1つは、WindowsでUser1を削除して再生成することは、長年にわたって構成設定を指定してきたことです。 User1はCygwinアカウントにアクセスできなくなりました。
私はそれらを削除しているので、何をさらにチェックする必要があるかについてのアイデアがあります。
PSこの記事を読んでくれてありがとう。
ベストアンサー1
さらなる調査後（ここそしてここ）問題はCygwinではなく、Windows 10にあると思う傾向があります。昨日、User2のWindowsアカウントを使用し、UACプロンプトなしでタスクマネージャを起動できることがわかったとき、頭の中に何かがクリックされました。 User1が常にWindows 8からWindows 10にアップグレードするように求められたことがわかりました（アップグレードには約1年かかりましたが）。以前はWin 10プロモーションへの無料アップグレード中）。私はこれがWindows 10の問題だと思い、それについてあまり考えていませんでした。 User2でこれが起こっていることに気づき、User1の問題を解決するためのソリューションをGoogleで検索したときに、User1のCygwinの問題に対して同じ解決策を使用できることがわかりました。最初にUser1のアカウントがどのように混乱しているのか、実際に正しい方法で修正する方法についてはまだ答えられませんが、これでUser1に対するgitの変更を完了できるので、この回避策に満足しています。
長い話を短く
解決策：
- コマンドライン（CMD.EXE）を開き、この変数を設定してUACポップアップ表示を停止します。
set __compat_layer=runasinvoker
- Cygwinを起動して、同じ端末で環境変数を設定します。
c:\cygwin64\bin\mintty.exe
- そのユーザーを永久に作成し、デスクトップアイコンを再び機能させます。
setx __compat_layer "runasinvoker"
- コンピュータ全体のすべてのユーザーにこの設定を永久に適用するには、管理コマンドラインを開き、次の手順を実行します。
setx /m __compat_layer "runasinvoker"
- 最後に、Cygwinを変更せずにgitにアクセスするには、「Git Bash」をインストールします。
警告する:User1アカウントはまだ技術的に破損しているため、まだsshを使用してログインすることはできませんが、少なくともUser1でローカルのCygwin端末にアクセスすることはできます。さらに、この回避策はsysdm.cpl GUIを介してUser1のWindowsユーザー環境変数を変更する機能を変更しませんが（まだUACプロンプトが表示され、User1の代わりに管理者のENV変数のみが表示されます）、これはWindows固有のStack Exchange Fromです。フォーラムによると、これがCygwinの問題ではなくWindowsアカウントの問題であることがわかっています。 SETXを使用すると、コマンドラインでユーザーとマシンのENV変数を変更できます。