WindowsのCpas LockとCtrlがMacと逆なのは、Windows開発当時Macintoshその他のコンピューター達と被らないようにという権利的な理由らしいという話を聞いたことがあります。今ではAの横にCaps Lockがあるレイアウトがデファクトスタンダードになってしまいましたが。

またもやLPIC-1からの内容になりますが、今回はSSHのユーザー認証・ホスト認証についてです。

SSHではID＋パスワードによるログインの他、公開鍵暗号形式でのログインを行うことが出来るのはご存じかと存じます。おそらく全人類一度はSSHでサーバーにログインしたことがあるはずです。いやどうでしょう...自信がなくなってきました。



自身の秘密鍵と公開鍵を生成したら、事前に接続先のサーバーに自分の公開鍵を送りつけておき、
いざ接続する段階では秘密鍵を使って生成した署名をサーバーに送信、サーバーは公開鍵を使って署名を検証する。問題なく検証できれば晴れて認証成功！ログインしてよし！というのが公開鍵暗号方式の大まかな流れです。

すなわち、ID/パスワードor公開鍵暗号方式を用いて
サーバー側が、正しいクライアントであることを識別する
のがユーザー認証になります。



さて、クライアントからログインするためには予めサーバーと接続する必要があるわけですが、もしかしたら接続先のサーバーが悪意のあるなりすましであるという可能性は否定できません。
公開鍵暗号方式ならまだしも、パスワードでログインしていた場合、パスワードが漏洩し悪用される危険性があります。
そこでSSHでは接続を確立する際に、サーバーのホストキーの公開鍵をクライアントが受け取り、公開鍵暗号方式によって正しいサーバーであることを判断します。

すなわち
クライアント側が、正しいサーバーであることを識別する
のがホスト認証になります。


RSAを暗号形式に用いる場合、
ユーザー認証では
クライアントの公開鍵「~/.ssh/id_rsa.pub」は、
サーバー側の「~/.ssh/authorized_keys」に保存される一方、


ホスト認証の場合
サーバーの公開鍵「/etc/ssh/shh_host_rsa_key.pub」は、

クライアント側の「~/.ssh/known_hosts」に保存されます。

参考URL：

https://hostingstock.net/blog/20150516/

https://qiita.com/angel_p_57/items/2e3f3f8661de32a0d432#fnref11