SSHを介してWindowsシステムからLinuxシステムにファイルをコピーするために自動的に実行される単純なバックアップスクリプトを設定しようとしています。
多くの簡単なオンラインチュートリアルでわかるように、pscp
生成された秘密鍵を使用し、そのputtygen
公開鍵(パテ自体によってコピー/貼り付け形式で表示)をauthorized_keys
Linux上のファイルに配置しました。同じ構成を持つ2つの異なるWindowsシステムと異なるLinuxシステムで実行されていることを考慮すると、非常に簡単に見えます。
Linuxボックスにrootとしてログインできることを考慮すると、AFAICSには接続の問題はなく、SSHも同様です。プロファイル(sshd_config
)AuthorizedKeysFile
がに設定されました~/.sshd/authorized_keys
。
いくらでも「サーバーがキーを拒否しました」というエラーが表示され続けます...ログに認証の問題は表示されません...
もう少しテストしてみて値を orlogLevel
に設定する予定ですが、問題の緊急性と実際のマシンでテストするには多くの困難を経験しなければならないという点を考慮すると、機械状態です。私が働いている場所とは遠すぎます...VERBOSE
DEBUG2
3
質問
- 誰でもどんなアイデアがありますか?
- こんな状況に遭った人はいますか?
これは実際にはsshのバージョンや同様の問題に関連する問題のようです。
また、ルートフォルダに公開鍵を配置することに加えて、authorized_keys
ユーザーディレクトリ内のファイルに公開鍵を挿入する必要がある可能性も考慮しました(値の値のため意味がありません)。.ssh
/user/.ssh/
AuthorizedKeysFile
sshd_config
SSHサーバーにoを設定してLogLevel
いくつかのテストを実行しましたが、VERBOSE
情報(責任の問題)を取得できないため、ここに同じエラーが表示されているように見える別のソースの出力/デバッグログがあります。
Connection from 192.168.0.101 port 4288
debug1: Client protocol version 2.0; client software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: permanently_set_uid: 22/22
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user dcowsill service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "dcowsill"
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM: setting PAM_RHOST to "192.168.0.101"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 2 failures 2
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
Connection closed by 192.168.0.101
プログラムが所有者の権限でファイルを開こうとするようですが、authorized_keys
問題の原因に関する情報はもうありません。最後に、ファイルとフォルダの権限を確認して再確認しましたが、すべて問題ありません。
ベストアンサー1
私が知っている可能性のある理由のいくつかはファイル権限に関連しており、ほとんどはあまりにも広範囲です。特に2つの理由を思い出すことができます。
- 所有者以外の人に/ home / userディレクトリを公開します。
.ssh
および/またはAuthorized_keysファイル権限(この値を超える場合はそれぞれ700/600に設定)
サーバーへのルートアクセス権がある場合は、デバッグオプションとビデーモンオプションを使用して別のポートで追加のsshdサーバーを起動して、キーが拒否される理由を正確に特定できます。
sudo `which sshd` -p 2020 -Dd
サーバー上
実行状態を終了した後、sshを実行します。
ssh -p 2020 -i /path/to/refusedkey
サーバー出力で拒否理由を通知します。