一連の仮想マシンとハードウェアサーバーにアクセスするためにユーザーとルートアカウント用にSSHを構成している間、公開/秘密鍵関係の観点から理解できない状況に直面しました。
推奨される手順は次のとおりです。
ssh user@vm1生産するThe authenticity of host 10.1.10.9 can't be established. Are you sure you want to connect?
yesvm1システムキーの指紋をファイルに入力することを選択します~/.ssh/known_hosts。
ssh user@vm1リターンPermission denied(公開鍵、gssapi、...)
ssh-keygenログインしたユーザー（ 'user'）の~/.ssh/id_rsaローカルキーペアを作成しますid_rsa.pub。どちらもユーザーのコンピューターIDでラベル付けされています[email protected]。
次のステップのバージョンは次のとおりです。ssh-copy-id [-i ~/.ssh/id_rsa.pub] user@vm1
これはPasswordAuthentication設定されていてno帯域外で変更する必要があるため、通常失敗します。/etc/ssh/sshd_configその後、ssh-copy-idユーザーの公開鍵を~/.ssh/_authorizedkeysvm1のファイルにコピーできます。
成功した結果は、ssh-copy-idパブリックファイルの（ローカル）ソースとリモートに追加されたキー数（1）を識別します。
この時点でPasswordAuthenticationリセットできますno。
これで、ユーザーのファイルには、~./ssh/authorized_keysユーザー名とコンピューターIDで示されたキーが含まれています。
それでは、他のユーザー（たとえばroot）に対してSSHログインを設定してみましょう。
それでもユーザーとしてログインしています。
ssh-copy-id root@vm1（パスワード確認ステップをスキップします...）成功しました。 [ユーザー]の公開鍵をauthorized_keysvm1ルートフォルダ~/.ssh/のファイルにコピーしました。キーにはまだ[ユーザー]の名前とコンピュータのラベルが付いています。
これには明らかに欠陥があるように見えるかもしれませんが、MACを使用している場合は、MACにrootユーザーフォルダがないため、これは唯一のオプションです~/.ssh/。
これの効果は、他のコンピュータのすべてのユーザーがルートパスワードを持つすべてのコンピュータでSSHルートログインを作成できることです。authorized_keysターゲットシステム~/.ssh/のルートフォルダにあるファイルに保存されている[ユーザー]アカウントの公開鍵に基づいて、コンピュータにrootとしてログインできます。
私にとって、これはユーザーの公開鍵がログイン権限を認証しますが、ターゲットルートの対応する秘密キーがソースシステムの制限されたルートアカウント~/.ssh/フォルダに保存されないため、ターゲットシステムのルートアクセス保護が弱まるようです。
私は何を逃したことがありませんか？
ベストアンサー1
まだssh-copy-id root @ vm1ユーザーとしてログイン（パスワード認証ステップをスキップする...）に成功し、[user]の公開鍵をvm1のルート〜/ .ssh /フォルダにあるAuthorized_keysファイルにコピーしました。キーにはまだ[ユーザー]の名前とコンピュータのラベルが付いています。
SSH鍵ベース認証の原則は次のとおりです。クライアントがサーバーから要求されたユーザー名ファイルの公開鍵に対応する秘密鍵を所有していることを暗号化方式で証明できる場合は、~/.ssh/authorized_keysアクセスが許可されます。それはすべてです。 「[ユーザー]名とコンピュータ」は、実際には人々が特定の公開鍵を簡単に識別できる自由形式のテキストフィールドです。このフィールドの内容は、いかなる方法でも認証には使用されません。
デフォルトでは、SSH サーバーは、次の理由で、着信接続でクライアントが主張するユーザー名に気を付けません。
- クライアントはそれをサーバーに公開したくないかもしれません。
- サーバーは何らかの方法でクライアントユーザー名を解決できません。
- でも、盗まれたキーを持つ悪意のあるクライアントは、クライアントに役立つクライアントユーザー名を構成できます。
SSH鍵認証の使用を制限するには、マニュアルページの説明に従ってファイルにSSH鍵をauthorized_keys追加するだけですfrom="<hostname-or-IP-address-pattern>"。sshd
このオプションの目的は、オプションでセキュリティを強化することです。公開鍵認証自体は、ネットワーク、ネームサーバー、またはそのいずれか（鍵を除く）を信頼しません。ただし、誰かが何らかの方法で鍵を盗むと、鍵を介して侵入者がどこからでもログインできます。世界に。この追加オプションを使用すると、盗まれたキーを使用することがより困難になります（キーに加えてネームサーバーおよび/またはルーターも破損する必要があります）。
私にとって、これはユーザーの公開鍵がログインを認証しますが、ターゲットルートの対応する秘密キーがソースシステム〜/ .ssh /フォルダの制限されたルートアカウントに保存されないため、ターゲットシステムのルートアクセス保護が弱まるようです。
これは、ソースコンピュータが常にターゲットコンピュータと同じ管理制御を受けている場合にのみ当てはまります。 SSHはこれを前提とせず、ソースシステムに基づいてユーザーが誰であるかを認識するのは役に立ちません。と主張したその主張を確認する方法がなければ。
実行してrootパスワードを正常に入力したい場合は、user@vm1この例で発生した結果にssh-copy-id root@vm1驚くことがあります。ssh-copy-idSSH秘密鍵がなく、SSHプロキシ転送が許可されているuser@vm1:.ssh/id_*場合は、プロキシ接続を使用してMacクライアントホストから公開鍵を取得します。これは、名前とコンピュータでラベル付けされた公開鍵がファイルに保存される方法です。sshdvm1ssh-copy-id[user]root@vm1:.ssh/authorized_keys
最新のmacOSには、ssh-agentすべてのmacOSユーザーセッションでデフォルトで使用できるmacOS Keyringと統合された拡張機能があります。一般的なOpenSSHの動作を期待している場合、これは驚くかもしれません。