私の問題は、システムからボード上でRSAキーベースのsshログインを正常に開発したことです。クライアントが初めてログインするときは、秘密鍵とパスフレーズについても質問しますが、これも正常に機能します。 2回目のログインでは、sshはプライベートキーやパスワードを要求せず、ボードに直接ログインします。
クライアント側はUbuntu 16.04を使用し、オンボードではUbuntuをカスタマイズします。
以下のコマンドでの初回ログイン:
ssh -i ~/.ssh/id_rsa user@board_ip
//正常に動作します
2回目:
ssh user@board_ip
//パスワードと公開鍵を要求しない-problem
初回:
ssh user@board_ip
//キーなしではログインできません-正常に動作します
私の理解では、ボード上のsshd_configファイルを間違えました。以下の設定でプレイしましたが、常に失敗しました。
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#PasswordAuthentication yes
PermitEmptyPasswords no
プロジェクトの要件は、主にsshでの安全なログインです。より安全なSSHパスワードベースのログインを実現するために、キーベースのログインに移行しました。上記で説明したように、すべての構成を変更した後。 SSHログインには、秘密鍵とパスワードも必要です。ログアウト後、いつか再度ログインした後、sshはキーまたはパスワードを必要としません。プロジェクトの要件は、キーとパスワードを毎回必要とします。
公開鍵とパスワードまたはパスフレーズの両方を要求するようにssh
を構成するには、2つの方法があります。
パスワードとパスフレーズの違い:
このコンテキストのパスワードは、サーバーコンピューター(ボード)のユーザーに割り当てられたパスワードです。ボードにユーザーアカウントが1つしかない場合、パスワードは1つだけになります。ボードに複数のユーザーアカウントがある場合、一意のパスワードが必要です。
パスフレーズは、リモートサーバー(ボード)コンピューターではなく、クライアント(ローカル)コンピューターの秘密キーにリンクされます。したがって、デバイスの2つの異なるクライアントコンピューターを使用してsshを実行する場合、各ローカルコンピューターに格納されている秘密キーのパスフレーズを作成する必要があります。同様に、2人の異なるユーザーがそれぞれのローカルコンピューターからサーバー(ボード)にsshする必要がある場合、それぞれの秘密キーのロックを解除するには、独自の秘密キーと公開キーのペアとパスフレーズが必要です。
たとえば、あなたと私が自分のラップトップからセーブサーバーコンピューター(ボード)にsshする必要があるとしましょう。独自の秘密鍵とその秘密鍵のパスフレーズがあります。私は自分の秘密鍵とそのパスフレーズを持っています。この配置の結果は、あなたに何も言わずに、またはサーバーコンピューター(ボード)に何かを変更することなく、いつでも秘密鍵のパスフレーズを変更できることです。あなたに言わずに、秘密鍵からパスフレーズを削除することもできます。
もう1つのシナリオは、sshに複数のサーバーがあり、同じ秘密鍵を使用してすべてのサーバーに対して自分を認証する場合、同じパスフレーズを使用して、作業するすべてのサーバーのsshにアクセスする必要があるだけではありませんあなたのボード。
参照: https://help.ubuntu.com/community/SSH/OpenSSH/Keys
ステップ1.各クライアントとユーザーの組み合わせの既存の公開鍵と秘密鍵にパスフレーズを追加します
各クライアントコンピューターまたはデバイスのユーザーごとに、次のコマンドを使用して、既存の公開キーと秘密キーのペアのパスフレーズを生成します。
ssh-keygen -p
ファイルを保存する場所の入力を求められます。 Enterキーを押してデフォルトの場所を受け入れます。
既にパスフレーズを設定している場合は、既存のパスフレーズを入力するよう求められます。その場合、このステップはすでに完了しています。押す Ctrl+C プロセスを停止します。
次に、新しいパスフレーズを入力するように求められます。 Enterを押さないでください!覚えやすいパスフレーズを推測するのが難しくて長く入力します。パスフレーズを再入力するように求められます。
既存の公開鍵と秘密鍵のペアがない場合は、次のコマンドを使用して生成します。パスフレーズが必要な場合は、パスフレーズを追加するよう求められます。
ssh-keygen -t rsa
Sshサーバーにログインしようとするたびに、このパスフレーズの入力を求められます。これは、sshサーバーのユーザーパスワードによって異なる場合があります。各ユーザーは独自のパスフレーズを持つことができます。ユーザーが異なるクライアント(ラップトップ、電話など)からログインする必要がある場合、クライアントごとにこのプロセスを繰り返す必要があります。彼女はクライアントごとに異なるパスフレーズを選択できます。
ステップ2.鍵が新しい場合にのみ公開鍵をサーバーにコピーします
クライアントコンピューターに次を入力します。
ssh-copy-id -i ~/.ssh/id_rsa user@board_ip
リモートサーバーのユーザーのパスワードを要求します。 、これを機能させるには、パスワードベースのログインを有効にする必要があります。
すべてのユーザーとすべてのクライアントデバイスに対して繰り返します。
ステップ3.動作するかどうかをテストします
次を入力して、サーバーへのログインを試行します。
ssh user@board_ip
すべてうまくいけば、ステップ2で作成したパスフレーズを入力するように求められます。これは、ステップ3で尋ねたユーザーパスワードではありません。
ユーザーパスワードの入力を求めるプロンプトが表示された場合は、何かが正しくありません。 これが機能するまで、次のステップに進まないでください。
ステップ4.パスワードベースのログインを無効にします
各ユーザーとそれぞれのクライアントデバイスが独自の公開鍵と秘密鍵のペアと選択したそれぞれのパスフレーズを取得したら、パスワードベースのログインは不要になります。このメソッドを無効にすることをお勧めします。有効にすると、公開鍵と秘密鍵のペアを持たない人がuser @ board-ipのパスワードを推測できるようになります。
Sshサーバーのボードで、ファイル/etc/ssh/sshd_config
を編集して変更します。
#PasswordAuthentication yes
読むために:
PasswordAuthentication no
2行目に#
がなく、yes
がno
になっていることに注意してください。
次の方法でサーバーのsshサービスを再起動します。
Sudo service ssh restart
これが機能しない場合は、ボードを再起動します。
されております。ユーザーがローカルコンピューターからログアウトするまで、パスフレーズはおそらくGnome-Keyringによってクライアントにキャッシュされます。したがって、phass-phraseはセッションごとに1回だけ要求されます。
次に来るのは別の選択肢です。 1または2のいずれかを行う必要があります。
ステップ1.クライアントとユーザーの組み合わせごとに、秘密鍵が存在する場合はパスフレーズを削除します
各クライアントコンピューターまたはデバイスのユーザーごとに、次のコマンドを使用して公開キーと秘密キーのペアを生成します。
ssh-keygen -p
ファイルを保存する場所の入力を求められます。 Enterキーを押してデフォルトの場所を受け入れます。
既存のパスフレーズがある場合は、入力するよう求められます。既存のパスフレーズの入力を求められない場合は、完了です。押す Ctrl+C プロセスを停止します。
それ以外の場合は、既存のパスフレーズを入力して続行します。
次に、パスフレーズの入力を求められます。 ヒット Enter2回、既存のパスフレーズを秘密鍵から削除します。
既存の公開鍵と秘密鍵のペアがない場合は、次のコマンドを使用して生成します。パスフレーズが必要な場合は、パスフレーズを追加するよう求められます。
ssh-keygen -t rsa
ユーザーが異なるクライアント(ラップトップ、電話など)からログインする必要がある場合、クライアントごとにこのプロセスを繰り返す必要があります。
ステップ2.鍵が新しい場合にのみ公開鍵をサーバーにコピーします
クライアントコンピューターに次を入力します。
ssh-copy-id -i ~/.ssh/id_rsa user@board_ip
リモートサーバーのユーザーのパスワードを要求します。 、これを機能させるには、パスワードベースのログインを有効にする必要があります。
すべてのユーザーとすべてのクライアントデバイスに対して繰り返します。
ステップ3.公開鍵が使用されているかどうかをテストする
次を入力して、サーバーへのログインを試行します。
ssh user@board_ip
すべてうまくいけば、パスワードやパスフレーズの入力を求められません。これは正常です。これは、公開鍵がsshサーバー(ボード)に適切にインストールされ、機能していることを示しています。次のステップで再度パスワードを要求するように設定を変更します。
ステップ4.公開鍵とパスワードの両方のセットアップ
Sshサーバー(ボード)にログインし、/etc/ssh/sshd_config
ファイルを編集します。ファイルに次の行を追加します。
AuthenticationMethods publickey,password
警告:PasswordAuthentication
が次のようになっていることを確認してください。
#PasswordAuthentication yes
これがデフォルトの動作です。最初に#
を保持するか削除するかを選択できます。ただし、追加した行とともにこの設定がno
に設定されている場合、ssh
を使用してサーバーにログインすることはできません。ロックアウトされた場合は、リモートサーバーに物理的にアクセスし、キーボード、モニターなどに接続してローカルにログインし、このファイルを編集して問題を修正する必要があります。
警告終了
次の方法でサーバーのsshサービスを再起動します。
Sudo service ssh restart
これが機能しない場合は、ボードを再起動します。
ステップ5.侵入テスト
新しいユーザー名、たとえばuser2を使用して、新しいコンピューターを見つけるか、クライアントコンピューターにログインします。このユーザーは、/home/$USER/.ssh/
フォルダーに公開鍵と秘密鍵のペアを持ってはいけません。 user2は、user @ board_ipのパスワードを何らかの方法で見つけたハッカーであり、そのシステムにsshしようとするふりをします。
クライアントコンピューターからuser2として入力します。
ssh user@board_ip
パスワードだけでログインできる場合、機能しませんでした。パスワードを持っているか、推測できる人は誰でもボードにログインできます。キーは必要ありません。
permission denied
を取得してログインに失敗した場合、公開鍵とパスワードの二重認証が機能します。
お役に立てれば
問題は、~/.ssh/id_rsa
がUbuntuのSSH公開キーのデフォルトのホームであるということです。したがって、-i ~/.ssh/id_rsa
鍵ペアを使用するために、鍵の交換が行われた後にSSHコマンドにid_rsa
を含める必要はありません。
この動作を回避するには、異なる名前でSSHキーペアを作成し、-i
オプションで指定した場合にのみ使用されます。
例:
ユーザーのホームディレクトリにuser_ssh_rsa
という名前のキーを作成する場合:
ssh-keygen -t rsa -f ~/.ssh/user_ssh_rsa
次に、リモートサーバーとキーを交換し、プロンプトが表示されたらリモートシステム上のユーザーのパスワードを入力します。
ssh-copy-id -i ~/.ssh/user_ssh_rsa user@board_ip
でログインする:
ssh -i ~/.ssh/user_ssh_rsa user@board_ip
新しく作成されたキーを使用しているため、パスワードを要求せずにログインします。
を使用して:
ssh -user@board_ip
キーペアが自動的に検出されないため、パスワードを要求します。
これは、~/.ssh/id_rsa
で既に共有されているキーを削除したことに依存します