01.相互信頼の原則の紹介
SSHとは何ですか?
簡単に言えば、SSHはコンピューター間の暗号化されたログインに使用されるネットワークプロトコルです。たとえば、ユーザーはSSHプロトコルを使用して、ローカルコンピューターから別のリモートコンピューターにログインします。
初期のインターネット通信はすべて平文通信でしたが、傍受されるとコンテンツが公開されていました。1995年、フィンランドの学者Tatu Ylonenは、すべてのログイン情報を暗号化し、インターネットセキュリティの基本ソリューションとなるSSHプロトコルを設計しました。これは世界中で急速に普及し、現在はLinuxシステムの標準構成になっています。
SSHの基本的な使用法
SSHのデフォルトポートは22です。これは、ログイン要求がリモートホストのポート22に送信されることを意味します。このポートを変更するには、pパラメーターを使用します。
ssh -p 2222 user@hostname
或
ssh -p 2222 user@ip
# 先扩展变量$1,再执行远程命令
ssh user@123.456.789.0 "cd testdir;./test.sh \"$1\""
[その他の使用法]
http://www.ruanyifeng.com/blog/2011/12/ssh_port_forwarding.html
中間者攻撃
SSHがセキュリティを保証できる理由は、SSHが公開鍵暗号化を使用しているためです。
- リモートホストはユーザーのログイン要求を受信し、その公開鍵をユーザーに送信します。
- ユーザーはこの公開鍵を使用してログインパスワードを暗号化し、送り返します。
- リモートホストは、独自の秘密鍵を使用してログインパスワードを復号化します。パスワードが正しければ、ユーザーはログインできます。
プロセス自体は安全ですが、実装にはリスクがあります。誰かがログイン要求を傍受し、リモートホストになりすまして、偽造された公開鍵をユーザーに送信すると、ユーザーが信頼性を区別することが困難になります。httpsプロトコルとは異なり、SSHプロトコルの公開鍵は認証局(CA)によって公証されません。つまり、すべて自分で発行されます。
攻撃者がユーザーとリモートホストの間に(たとえば、パブリックWi-Fiエリアに)挿入された場合、偽造された公開鍵を使用してユーザーのログインパスワードを取得することが考えられます。次に、このパスワードを使用してリモートホストにログインすると、SSHセキュリティメカニズムがなくなります。
パスワードログイン
相手のホストに初めてログインする場合は、次のプロンプトが表示されます。
$ ssh user@host
The authenticity of host 'host (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?
このパッセージの意味は、ホストの信頼性を確認できず、公開鍵の指紋しかわからないということです。接続を続行しますか?
いわゆる「公開鍵フィンガープリント」とは、比較が難しい公開鍵の長さ(ここではRSAアルゴリズムを使用、最大1024ビット)を指します。そのため、MD5計算を実行して公開鍵を128ビットの指紋。上記の例では、98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4dであり、比較がはるかに簡単です。
当然の質問は、リモートホストの公開鍵指紋がどうあるべきかをユーザーがどのようにして知るかということです。答えは、良い方法はないということです。リモートホストは、ユーザーが自分で確認できるように、公開鍵のフィンガープリントをWebサイトに投稿する必要があります。
リスク測定後、ユーザーはこのリモートホストの公開鍵を受け入れることを決定したと想定されます。
Are you sure you want to continue connecting (yes/no)? yes
ホストが承認されたことを示すプロンプトが表示されます。
Warning: Permanently added 'host,12.18.429.21' (RSA) to the list of known hosts.
次に、パスワードの入力を求められます。
Password: (enter password)
パスワードが正しければ、ログインできます。
リモートホストの公開鍵が受け入れられると、ファイル$ HOME / .ssh / known_hostsに保存されます。次回このホストに接続すると、システムはその公開鍵がローカルに保存されていることを認識し、警告部分をスキップしてパスワードの入力を直接求めます。
各SSHユーザーには独自のknown_hostsファイルがあります。さらに、システムにはそのようなファイル(通常は/ etc / ssh / ssh_known_hosts)もあり、すべてのユーザーが信頼するリモートホストの公開鍵を保存します。
公開鍵ログイン
パスワードを使用してログインします。毎回パスワードを入力する必要があり、非常に面倒です。幸い、SSHは公開鍵ログインも提供しているため、パスワードを入力する手間が省けます。
いわゆる「公開鍵ログイン」の原則は非常に単純です。つまり、ユーザーは自分の公開鍵をリモートホストに保存します。ログインすると、リモートホストはランダムな文字列をユーザーに送信します。この文字列は、ユーザーが秘密鍵で暗号化した後に返送されます。リモートホストは、事前に保存された公開鍵を使用して復号化し、成功した場合、ユーザーが信頼できることを証明し、パスワードを必要とせずにログインシェルを直接許可します。
この方法では、ユーザーが独自の公開鍵を提供する必要があります。既製のものがない場合は、ssh-keygenを直接使用して生成できます。
$ ssh-keygen
上記のコマンドを実行すると、一連のプロンプトが表示され、Enterキーを最後まで押すことができます。質問の1つは、秘密鍵のパスフレーズを設定するかどうかです。秘密鍵のセキュリティが心配な場合は、ここで設定できます。
操作が終了すると、$ HOME / .ssh /ディレクトリにid_rsa.pubとid_rsaの2つの新しいファイルが生成されます。前者は公開鍵であり、後者は秘密鍵です。
次に、次のコマンドを入力して、公開鍵をリモートホストホストに転送します。
$ ssh-copy-id user@host
さて、再度ログインするので、パスワードを入力する必要はありません。
それでも機能しない場合は、リモートホストのファイル/ etc / ssh / sshd_configを開き、次の行の前にある「#」コメントが削除されているかどうかを確認します。
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
次に、リモートホストのsshサービスを再起動します
service ssh restart
authorized_keysファイルを認証します
リモートホストは、ログイン後にユーザーの公開鍵をユーザーのホームディレクトリの$ HOME / .ssh / authorized_keysファイルに保存します。公開鍵は単なる文字列であり、authorized_keysファイルの最後に追加するだけです。
上記のssh-copy-idコマンドを使用する代わりに、次のコマンドを使用して、公開鍵の保存プロセスを説明します。
$ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
このコマンドは、1つずつ分解された複数のステートメントで構成されています。
- 「$ sshuser @ host」は、リモートホストにログインすることを意味します。
- 一重引用符で囲まれたmkdir.ssh && cat >> .ssh / authorized_keysは、ログイン後にリモートシェルで実行されるコマンドを示します。
- 「$ mkdir -p .ssh」の機能は、ユーザーのホームディレクトリに.sshディレクトリが存在しない場合に作成することです。
- 'cat >> .ssh / authorized_keys' <〜/ .ssh / id_rsa.pubは、ローカル公開鍵ファイル〜/ .ssh /id_rsa.pubをリモートファイルauthorized_keysの末尾にリダイレクトします。
authorized_keysファイルを書き込むと、公開鍵のログイン設定が完了します。
02.2台のマシン間の相互信頼を確立する
通常、sshコマンドを使用して別のマシンにアクセスする場合、またはscpコマンドを使用して別のマシンからデータとファイルをコピーする場合は、対応するアカウントのパスワードを入力する必要があります。2台のマシン間に信頼関係を確立するために、パスワードを入力するプロセスを省略できます。
機械操作
現在のuser.sshフォルダーにid_rsaファイルとid_rsa.pubファイルがあるかどうかを確認します
ls ~/.ssh
これらの2つのファイルを以前に生成したことがない場合は、以下を実行する必要があります。
ssh-keygen -t rsa
id_rsa.pubコンテンツを表示する
cat ~/.ssh/id_rsa.pub
B機械操作
公開鍵id_rsa.pubを別のマシンのauthorized_keysファイルに追加します
vim authorized_keys
このようにして、AからBへの公開鍵ログイン方式、つまりパスワードなしのログインが確立されます。同様に、BからAへの公開鍵ログイン方式を確立します。
sshdには厳格なアクセス許可要件があるため、パスワードを入力する必要がある場合は、ホストBに移動して、.sshフォルダーとauthorized_keysファイルのアクセス許可を確認できます。.sshフォルダーのアクセス許可は755で、authorized_keysファイルのアクセス許可は600である必要があります。これは、chmodコマンドを使用して変更できます。
chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
03.クラスター間の相互信頼の確立
相互信頼は手動で確立できますが、マシンが多すぎると面倒です。スクリプトを渡す方がはるかに便利です。スクリプトの原則は次のとおりです。
- 最初のステップは、各ホストでキーを生成することです。
- 2番目のステップは、各ホストの公開鍵を、コマンドを実行するホストのauthorized_keysにコピーすることです。
- 3番目のステップは、authorized_keysを他のホストに配布することです。
- 4番目のステップは、authorized_keysのアクセス許可を600に変更することです。
- 検証相互信頼(スクリプトに検証相互信頼操作なし)
#!/bin/sh
## 1 delete .ssh directory
UserName="mongodb"
rm -rf ~/.ssh
ssh-keygen -t rsa
ssh-keygen -t dsa
startnode=7
endnode=7
for ((i=${
startnode}; i<=${
endnode}; i++));
do
ssh $UserName@node$i 'rm -rf ~/.ssh; ssh-keygen -t rsa -f ~/.ssh/id_rsa -P "";exit '
ssh $UserName Node$i 'rm -rf ~/.ssh;ssh-keygen -t rsa -f ~/.ssh/id_rsa -P "";exit'
done;
# 2 copy public keys to one file
#ssh $UserName@node1
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
for ((i=${
startnode}; i<=${
endnode}; i++));
do
ssh $UserName@node$i cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh $UserName@node$i cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
done;
# 3 Dispath authorized_keys to other machines and change file property
chmod 600 ~/.ssh/authorized_keys
for ((i=${
startnode};i<=${
endnode};i++));
do
scp ~/.ssh/authorized_keys $UserName@node$i:~/.ssh/
ssh $UserName@node$i 'chmod 600 ~/.ssh/authorized_keys'
done;
スクリプトパラメータの説明:
- UserNameはホスト名に対応します。
- ssh-keygen -trsaとssh-keygen-t dsaは2つの暗号化キーを生成します。もちろん、使用できるのはそのうちの1つだけです。
- startnodeとendnodeは、192.168.2.150から192.168.2.159、startnode = 1、endnode = 9などのノードIPの範囲を示し、192.168.2.150ホストでスクリプトを実行するだけで済みます。
- ssh username @ hostname cmdリモートホストにログインしてcmdコマンドを実行します。複数のコマンドを実行する必要がある場合は、「cmd; cmd; cmd」と記述する必要があります。
- このスクリプトの現在の機能はまだ比較的弱いです。たとえば、IP範囲は連続的で、ホスト名のプレフィックスは同じである必要がありますが、小さなクラスターを構築するには、ホスト間の相互信頼を構成するだけで基本的に十分です。
04.その他の問題
定義されたマスターサーバーと192.168.50.131は同じものですが、2つの方法の効果は異なります。
ssh-copy-id -i id_rsa.pub root@192.168.50.131
ssh-copy-id -i id_rsa.pub root@masterserver
公開鍵がIP経由で送信される場合、IP経由でのみアクセスでき、ホスト名経由のアクセスにはパスワードが必要です。2番目の方法は必要ありません。
know_hostsファイルを観察すると、2番目のメソッドの前に最初のメソッドよりも多くのホスト名があることがわかりました。テスト後、最初のメソッドのknow_hostsファイルにホスト名を手動で追加した場合、効果は2番目のメソッドと同じです。