web-dev-qa-db-ja.com

今月は非管理者のCygwinユーザーにログインまたはsshできませんが、先月は可能であり、他の非管理者ユーザーには引き続き可能です

この問題のバリエーションに関するほとんどすべてのGoogleリンクのように感じるものを読みましたが、どれも当てはまらないようで、これは私を困惑させています。

多くのLinuxマシンに加えて、CygwinがインストールされたWindows 10ラップトップがあり、セットアップファイルを介してWindowsUpdateとCygwinの更新を完全に更新しています。管理者ユーザー（厳密にはメンテナンス用）と、日常の操作のためにユーザーグループ（および他のグループのメンバーではない）に割り当てられた2つの非管理者ユーザーアカウントがあります。 3つのアカウントはすべて何年も問題なく機能し、Cygwinはそれぞれのcygwinターミナルを起動したり、SSH経由でローカルホストにログインしたりできました。今月、なんらかの理由で、User1アカウントはCygwinターミナルを起動できなくなりました。代わりに、常に管理者パスワードの入力を求められます。 NOを選択すると、Cygwinターミナルは開きません。 [はい]をクリックして管理者パスワードを入力すると、実際にはUser1としてログインしません。これは、User1が管理者である必要はなく、更新をプッシュ/プルするために独自のgitファイルやリポジトリなどにアクセスする必要があるためです。 。

管理者が「sshUser1 @ localhost」を実行すると、パスワード認証に合格しますが、すぐに次のタイプのメッセージが表示されます。


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

最後のログインはログインが成功したことを確認しますが、常に即時のキックアウトがあることに注意してください。代わりに、User2で同じコマンドを実行しても問題はなく、sshdが正常に機能していることを確認します。

管理者のアカウントを介してcygwinターミナルから「loginUser1」を実行すると、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 {} \;
  • Passwdファイルとgroupファイルを何度も再作成しました。

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 -RUser1へのアクセス許可を変更しようとしました。 ：なし（同じ結果）。


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からUser3のホームを自動作成します。 User1の/ home/User1ディレクトリを削除すると、SSH経由のログイン時に自動再作成されません。もちろん、管理者のシェルに戻されます。

Ssh -vvv User1 @localhostとUser2は次のようになります。両方が正常に認証された後の部分のみを含めているので、違いがわかります。


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 [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 ~
$


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 [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とUser2の両方で他のすべてが通常どおり機能する場合は再作成しないためです。 User1は自分のCygwinアカウントにアクセスできなくなりました。

私はそれらから新鮮なので、他に何をチェックするべきかについてのアイデア。

P.S.ここまで読んでくれてありがとう。

sshloginsshdcygwinlogout
4
Jack Hamilton

さらに調査した後（ ここ および ここ ）問題はCygwinではなく、Windows10にあると思う傾向があります。頭の中で電球がオンになったとき私は昨日User2のWindowsアカウントにいて、UACプロンプトなしでタスクマネージャーを起動できることに気づきました-User1がWindows8からWindows10へのアップグレード後に常にプロンプ​​トが表示されることを知っていました（アップグレードはほぼ1年前の無料アップグレード中に行われましたが10プロモーションに勝つ）。私はそれがWindows10のものだと思い、二度と考えたことはありませんでした。 User2ではプロンプトなしで、User1ではそれを修正するためのグーグルの回避策が発生していることに気付いたとき、User1のCygwinの問題にも同じ回避策を使用できることがわかりました。そもそもUser1のアカウントがどのように台無しになったのか、また実際に正しい方法で修正する方法についてはまだ答えていませんが、User1のgit変更を実行できるようになったので、この回避策には満足しています。

TL; DR

ワークアラウンド：

  • コマンドライン（CMD.EXE）を開き、この変数を設定して、UACポップアッププロンプトの取得を停止します。

set __compat_layer=runasinvoker
  • 同じ端末から環境変数が設定され、Cygwinを起動します。

c:\cygwin64\bin\mintty.exe
  • このユーザーに対してこれを永続的にする（そしてデスクトップアイコンを再び機能させる）

setx __compat_layer "runasinvoker"
  • これをマシン全体のすべてのユーザーに対して永続的にするには、adminコマンドラインを開いてから次の手順を実行します。

setx /m __compat_layer "runasinvoker"
  • そして最後に、Cygwinを修正せずにgitにアクセスするには、「GitBash」をインストールします。

警告：User1アカウントがまだ技術的に壊れているため、sshを使用してログインすることはできませんが、少なくともUser1としてローカルのCygwinターミナルにアクセスできます。また、この回避策は、sysdm.cpl GUIを介してUser1のWindowsユーザー環境変数を変更する機能を修正しません（UACプロンプトを取得し、その後、User1ではなく管理者のENV変数のみを表示します）が、これはWindows関連のStackExchangeフォーラムの問題です。これはWindowsアカウントの問題であり、Cygwinの問題ではないことを私は知っています。また、SETXを使用すると、コマンドラインからユーザーとマシンのENV変数を変更できます。

1
Jack Hamilton