クラスタ間 SSH 相互信頼によるパスワード不要のログイン失敗の処理

1. 問題の説明

GreePlum クラスターのパスワードなしの構成プロセス中に、一般ユーザーを使用して ssh パスワードなしのログインを実装する必要があります。以前のフィードバックでは、root ユーザーはパスワードなしのログインを完了できますが、一般ユーザーの同じ構成では完了できません。パスワードの入力を求めるプロンプトが表示されます。
ここに画像の説明を挿入
サイト環境:
ここに画像の説明を挿入

2. 問題の分析と対処

2.1. オープンデバッグモード/詳細情報モードのデバッグ

ここに画像の説明を挿入
上の図に示されているように、ssh クライアントが秘密キーを送信した後、サーバーが秘密キーを受け入れなかったため、秘密キーを信頼できず、エラーが報告されました。パケットを送信しませんでした。メソッドを無効にしました。新しい認証通信にはパスワード モードが使用されました。

2.2. sshd サービスのオープンデバッグモード

サービスはデバッグ モード プロセスを開始します。/usr/sbin/sshd -d -p 2222

クライアントは 2222 への接続を再開始し、サービス側の情報を監視します。

ここに画像の説明を挿入
ここに画像の説明を挿入
上の図に示すように、クライアント側のユーザーの公開キー ファイルの権限に問題があることが示されています。通常の出力は次のとおりです: 関連情報をクエリします。次のことを試してみてください
ここに画像の説明を挿入
:ホーム ディレクトリ、.ssh ディレクトリ、および authorized_keys ファイル: ssh サーバーが「StrictModes on」で実行されている場合、~/.ssh/authorized_keys ファイル内の公開キーの使用を拒否します。ホーム ディレクトリは、次のユーザーのみが書き込み可能である必要があります。 ~/.ssh は 700 、authorized_keys は 600 である必要があります。

ホーム ディレクトリの秘密キー ディレクトリのアクセス許可を確認します。

~/.ssh/authorized_keys のデフォルトのパーミッションは 664 で、その他のパーミッションは正常であることがわかり、authorized_keys パーミッションを 600 に変更して再試行すると、パスワードなしで ssh が通過します。
ここに画像の説明を挿入

次のように確認します。
ここに画像の説明を挿入
ここに画像の説明を挿入

3. 付録

3.1 SSH 公開鍵認証の問題分析のアイデア

ssh クライアントとの接続時に詳細なデバッグ情報を取得する: ssh コマンドに「-v」オプションを追加します (例: ssh chuyeow@remotehost -v -v -v)。より詳細なデバッグを行うには、「-v」をさらに追加します (「-v -v -v」まで実行できると思います)。
sshd をデバッグ モードで実行してリモート ホストでデバッグする: リモート ホストで '/usr/sbin/sshd -d -p 2222' を実行し、接続します。ここの「2222」は、リモート ホスト上で開始した sshd プロセスのポート番号です。
認証ログの末尾: リモートホストで「tail -f /var/log/auth.log」を実行します。キーを使用して SSH 経由で接続しようとすると、ログを確認できます。
SSH キー エージェントが実行されていることを確認します。「ps aux|grep ssh-agent」を実行します。キーエージェントが実行されていることを確認してください。ssh-agent (私は Gentoo のキーチェーン、または Mac OS X の SSHKeyChain が好きです) を使用していない場合は、キーチェーンが実行されていることを確認するために必要なことは何でも行ってください。
秘密キーが ssh キー エージェントに追加されていることを確認します。「ssh-add -l」を実行して、ssh-agent にキーがあることを確認します。同様に、他のものを使用している場合は、キーチェーン アプリケーションに秘密キーがあることを確認してください。
ホーム ディレクトリ、.ssh ディレクトリ、およびauthorized_keys ファイルの権限を確認してください。ssh サーバーが「StrictModes on」で実行されている場合、~/.ssh/authorized_keys ファイル内の公開キーの使用を拒否します。ホーム ディレクトリはあなただけが書き込み可能である必要があり、~/.ssh は 700、authorized_keys は 600 である必要があります。

3.2 ssh 暗号化および復号化プロセス

ここに画像の説明を挿入

1. クライアントとサーバーは SSH 接続を確立し、Diffie-Helman キー交換アルゴリズムを使用して対称キーをネゴシエートします。 2. クライアントは、ネゴシエートされた対称キーを使用して送信するデータを暗号化し、それをサーバーに送信します
。サーバー;
3. サーバーは暗号化されたデータを受信し、ネゴシエートされた対称キーで復号し、対応する処理を実行します;
4. サーバーは、送信するデータをネゴシエートされた対称キーで暗号化し、クライアントに送信します。
5. クライアントは暗号化されたデータを受信し、ネゴシエートされた対称キーを使用してそれを復号化し、対応する処理を実行します。

データ暗号化アルゴリズムは一般に、対称暗号化、非対称暗号化、一方向暗号化の 3 つのカテゴリに分類できます。

対称アルゴリズム: いわゆる対称暗号化アルゴリズムは、暗号化と復号化に同じキーを使用します。基本的なアルゴリズムには DES、3DES、AES などが含まれます。特徴: 暗号化と復号化に同じ鍵を使用し、元のデータを固定サイズのブロックに分割し、1 つずつ暗号化します。欠陥: キーが多すぎる、キーの配布。

非対称アルゴリズム: キーはペアで表示されます。実装アルゴリズムには、RSA、DSA、ELGama などが含まれます。公開鍵 (pubkey) : 誰でも公開、秘密鍵 (秘密鍵) : 自分専用に保管し、プライバシーを確​​保する必要があります。特徴: 公開キーで暗号化されたデータは、それとペアになっている秘密キーでのみ復号化でき、その逆も同様です。その主なアプリケーション シナリオは次のとおりです。

デジタル署名:主に受信者が送信者の身元を確認できるようにするため;

鍵交換:送信者は対称鍵を相手の公開鍵で暗号化して相手に送信する;

データ暗号化:通信速度が遅いためデータの暗号化には使用されませんが、通常はデータの暗号化には使用されません。

一方向: 基本アルゴリズムは次のとおりです: MD5、SHA1 など。特徴: 復号化のみ可能ですが、復号化はできません; データ フィンガープリントの抽出に使用できます; 固定長出力、アバランシェ効果 (つまり、データ内容のわずかな変更が出力結果に大きな変化を引き起こす可能性があります)。これは通常、ファイルの機能コードを抽出するために使用され、ファイル データの小さな変更が雪崩効果を引き起こします。

#加密
openssl enc -des3 -a -salt -in a.txt -out txt.file
#解密
openssl enc -d -des3 -a -salt -in txt.file -out a2.txt

ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/ximenjianxue/article/details/131113588