⇧ 個人的には、「コクーン（監督：ロン・ハワード）」、「スクリーマーズ（監督：クリスチャン・デュゲイ）」、「バタフライ・エフェクト（監督： エリック・ブレス、J・マッキー・グラバー）」あたりも紹介して欲しかったかな...
スクリーマーズ <コレクターズ・エディション> [Blu-ray]
バタフライ・エフェクト プレミアム・エディション [DVD]
ウォッチメン BDコレクターズ・バージョン [Blu-ray]
⇧ 取り上げられてなくて、個人的に面白かったと記憶しているSF映画で思い出せるのが少なかったけど...
まぁ、「ガタカ（監督：アンドリュー・ニコル）」を取り上げてくれてるのは善き。
映画が観たくなる今日この頃ですかね...
ssh-keyscanはSSH（Secure Shell）の1種のOpenSSHの1機能
ネットの情報を漁っていたら、
ドキュメントに書いてあるとおり、OpenSSHは以下のツールで構成されているになる。
1. リモート操作を司るssh, scp, sftp 2. 鍵の管理ツールであるssh-add, ssh-keysign, ssh-keyscan, ssh-keygen 3. サービスをつかさどるsshd, sftp-server, ssh-agent
⇧ 上記サイト様がまとめてくださっておりました。
ちなみに、OpenSSHの認証方法としては、
It looks like the documentation of methods allowable in AuthenticationMethods made it into version
7.6: OpenSSH 7.6 release notes
https://serverfault.com/questions/880051/how-to-list-all-openssh-supported-authentication-methods
⇧ とあって、バージョン 7.6のドキュメントで確認できると。
⇧ とりあえず、「release-7.6.txt」を確認してみると、
⇧ 「sshd_config(8): document available AuthenticationMethods; bz#2453」とあるということは、version 7.6から認証方法を設定できるようになったってことなんですかね？
OpenSSHのマニュアルで「sshd_config」の「AuthenticationMethods」の説明を確認すると、
AuthenticationMethods
Specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more lists of comma-separated authentication method names, or by the single string any to indicate the default behaviour of accepting any single authentication method. If the default is overridden, then successful authentication requires completion of every method in at least one of these lists.
...省略
The available authentication methods are: "gssapi-with-mic", "hostbased", "keyboard-interactive", "none" (used for access to password-less accounts when PermitEmptyPasswords is enabled), "password" and "publickey".
⇧ となっており、
-
- gssapi-with-mic
- hostbased
- keyboard-interactive
- none
- password
- publickey
- any
⇧ デフォルトは、anyとなっていて、1. の6つの全ての認証方法が利用できるようになっていると。
話が脱線しましたが、「ssh-keyscan」に話を戻すと、「sshd_config」の「AuthenticationMethods」で「publickey」を利用してる時に使うものということになりそうね、つまり、公開鍵認証とかしてないのであれば使うことはないということかと。
OpenSSHのマニュアルで「ssh-keyscan」の説明によると、
⇧ サーバーから公開鍵の情報を取得できると。
DESCRIPTION
ssh-keyscan is a utility for gathering the public SSH host keys of a number of hosts. It was designed to aid in building and verifying ssh_known_hosts files, the format of which is documented in sshd(8). ssh-keyscan provides a minimal interface suitable for use by shell and perl scripts.
⇧ あくまで、公開鍵認証に関連する情報を取得すると。
/etc/ssh/ssh_known_hostsと~/.ssh/known_hostsの関係って？
で、
⇧ の役割の違いがいまいちハッキリしない。
⇧ 上記サイト様がSSHログインの全体像を図にしてくれていますと。
で、2つのファイルの違いはと言うと、
⇧ とのこと。
開発環境だと、各ユーザーでSSHログインすることになるから、各ユーザーのホームディレクトリに配置されている「~/.ssh/known_hosts」が利用されるってことですかね。
で、「sshd_config」の「AuthenticationMethods」で、パスワード認証が利用できるようになっていて、
⇧ 上記サイト様にありますように、パスワード認証が許可されていれば、外部からSSH接続された時に、自動的に「~/.ssh/known_hosts」にSSH接続元のホストが追加されると。
SSH接続元のSSH認証情報が変わっていたりすると、「~/.ssh/known_hosts」に登録された情報と異なるとなって接続できなくなったりするので、「~/.ssh/known_hosts」から旧くなった情報の行を削除しておく必要があると。
SSHサーバー側が管理者しか触れないような環境の場合は、SSH接続の情報が変わった旨を伝えて対応してもらう感じかしら。
話が脱線しましたが、
という感じになるのかな。
ちなみに、SSHクライアントがWindowsの場合で公開鍵認証するとなったら、Git Bash（Git for Windowsをインストールすると同梱される）とかでssh-keygenして、秘密鍵・公開鍵を作成して、公開鍵をSSHサーバーに登録する感じになるんかな。
ssh-keygenのオプションで、
⇧ 暗号化も種類がいろいろあるので、どのアルゴリズムで秘密鍵・公開鍵を作成するかは、開発現場で要確認ですかね。
⇧ 秘密鍵を外部のサーバーに譲渡する感じもあるんだとか。
と思ったら、
⇧ やはりと言うか、秘密鍵を譲渡する接続方法は好ましくない方法ということみたいなんだけど、そもそも、ローカル端末に各サーバーで作成したっぽい秘密鍵をダウンロードしてるっぽいのは良いんかな？
AWSの公開している情報によりますと、
簡単な説明
EC2 Linux インスタンスは、デフォルトの認証方法として SSH キーペアファイルを使用します。キーペアファイルを使用すると、SSH のユーザー名とパスワードが不要になります。安全な環境を維持するために、踏み台ホストにはプライベートキーを保管しないでください。踏み台ホストを使用して接続するには、クライアントで ssh-agent 転送を使用します。ssh-agent を使用すると、管理者はプライベートキーを踏み台に保存しなくても、踏み台から別のインスタンスに接続できます。
⇧ とありますと。
前提条件が端折られてるけど、macOSやWindowsをSSHクライアントと想定しているようなので、macOSやWindows側で事前に作成しておいた秘密鍵・公開鍵の内、公開鍵をEC2 Linuxインスタンス側にアップロードしておく必要があると思われますかね。
とりあえず、
⇧ 上記サイト様にありますように、秘密鍵・公開鍵はローカル環境からSSH接続するんであれば、ローカル環境で作成するべきなような気がするんだけど、ネットの情報が錯綜していて、いまいちよく分からん...
ssh で公開鍵認証を使用し、デフォルトの秘密鍵(~/.ssh/id_rsa)以外でログインする場合は -i オプションで秘密鍵を指定する必要があるが、ssh-agent を使うことで指定が不要になる。さらに SSH Agent Forwarding 機能を使うと、秘密鍵をローカル PC に置いたまま、ログイン先のサーバーからさらに別のサーバーにログインすることもできる。
⇧ やはり、秘密鍵・公開鍵の作成はローカル環境（SSH接続元）で行って、作成した公開鍵をSSH接続したい各サーバー（SSH接続先）に配置で良さそうね。
とりあえず、情報を端折ったりするの止めて欲しいですかね...
まぁ、サービスを利用して欲しいと思っているはずのAWS（Amazon Web Service）さんでさえ、ドキュメントで情報を端折ってるからなぁ...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
