SSHでログインできなくなりました。。。助けてください
という、お客様のお問い合わせから始まりました。
セキュリティ設定をより高度にすることでハッキング対策を行うのは大変重要です。
しかし、ただただ理解せず設定するのはよろしくありません。
絶望的な状況から復活させた記録です。
始まりはお問い合わせから
ヘッドライン
この種の始まりはお問い合わせから始まります。
お問い合わせ内容は以下のようでした。
鍵の設定をした途端、ログインができなくなりました。rootでログインしようにもログインできない設定にしてしまったので入ることができません。
何とかなりませんか？
自分では鍵をうまく作ったつもりでしたが、どうやら鍵の不整合でエラーではじかれます。
こんなことってあるんですか？
答えを先にいうと、SSHではもはやログインのしようがありません。下手をすれば再インストールというところです。。。
なぜ、ログインできないと断言できるのか
100％ログインできないわけではありませんが、お客様の問い合わせ内容を見る限り、絶望的そうだな。。。と判断したわけです。
そもそも、鍵が無いとログインできない設定にしたわけですから、鍵のペアが不一致の時点でログインNGです。
こんなことってあるんですか？の問いに対しては、こんなことはあります。鍵が不整合な場合、不正なログインとみなされます。逆に言えば、ちゃんと機能していてよかったね。という話だと思います。
SSHの不具合ではなく、カギペアの不具合（不整合）であるのは間違いありません。機械のせいにしたい気持ちはわかりますが100%鍵の作り方をミスったのは本人である。と、話を聞いた時点で確信しました。
SSHの鍵とは
ここでは鍵・カギと言っていますが、SSHのセキュリティをより強固にするために、パスワード認証でのログインではなく、公開鍵と秘密鍵のペアで認証しSSHログインさせる仕組みがあります。
そのためには、鍵のペアが必要で、そのペアを作り、パスワードログイン及びrootログインを無効にしたうえで、鍵認証で入れなくなった＝もはやSSHでログインする方法はないという結論です。
鍵がうまく設定できていないだけでなぜ、手の施しようがないと判断したのか？
この状況で、もしログインできるとしたら、まず一つに、SSHの設定がまだはんぱで、パスワードログインができる場合、もう一つは、設定は正しくなっており、今回ログインしようとしたユーザのカギペアはおかしいが、それ以外のユーザで、しっかり鍵のペアが作られているユーザがあり、そのユーザでログインしてrootに化けて失敗したユーザのカギペアを正しいものにやり直すしか方法がないのですが、お話を聞いている限りではそのようなユーザが作られているという感じがしませんでしたし、ログインできていないからにはSSH自身の設定は正しく動いていると判断しました。
対応方法
一番いいのは、そのマシン（機器）にディスプレイとキーボードをつなぎ、SSHではなく、直接ログインして上記の鍵のペアを正しいものにするか、もしくはパスワードログインを有効にしてとりあえずSSH接続が可能な状態にして仕切り直しです。
VPSなどの仮想サーバーや、遠隔地にある場合は？
答えでいうと、SSH以外の方法でログインできない限りおそらく対応は難しいでしょう。
今回は幸いにもVPSで、VNC接続が可能だった
VNCというのはリモート接続で、ディスプレイ・キーボード入力が可能なリモート接続ツールです。
ようは、遠隔地だが、目の前に機器があるがごとく作業ができるのです。
なので、VNC接続して、SSHの設定を修正することにした。
キーボード入力がうまくいかない。。。
VNCの問題なのか、提供会社の設定の問題なのかわかりませんが、【：】コロンが入力できない。。USキーボードの配置と想定しても入力できませんでした。
vimエディタが使えない！
：コロンが使えないということは、viで、設定ファイルを編集した後保存！終了！コマンドが打てないということです。
なので、開いて編集はできますが、保存・終了ができない。。。これは困った。。。
使える文字だけで対応する方法
幸いにもFTPが生きていましたので、まず、sshd_configファイルをコピー、FTPで接続可能な場所へ移動。
FTPで、自分のクライアントに設定ファイルを落としてきてクライアントのエディタで編集。rootログインを可能に、またパスワードログインを許可し、鍵が使えなくてもログインできるように設定ファイルを修正。
修正したファイルを再度FTPでアップロード
そして、設定ファイルの正しい位置に、修正後のファイルを再度移動して、sshdを再起動。
これでうまく修正できました。
今回のポイント～対応できたけど、ほんとにこれで良いの？～
今回のポイントはSSHを使わずにいかに設定ファイルをいじることができるのかにすべてがかかっていました。結果、VNC＋FTP＋クライアントという複合技一本で設定ファイルを修正しパスワードログインが可能な状態にまで戻し、そこから仕切り直しができるようになりました。
逆を返せば、たとえどんなにSSHを固いセキュリティにしても、いとも簡単にroot権限じゃないといじれないような場所のファイルもいじれたということです。
今回の場合は全てはvncで接続できるところです。
もちろんvncの接続もパスワードを知っていたから容易だったわけですが。。。
このVNCでの接続に関してはサーバー会社のコントロールパネルにログインしたのち、指定のサーバーのrootパスワードでrootログインできたから容易に操作ができました。この両方を知っていない限りその位置までたどり着けませんので十分なセキュリティは確保されています。
しかし、このサーバー会社のコンパネパスワードと、rootのパスワードが何かの拍子に漏れたとしたら。。。クラッカーはやりたい放題してくるのでしょうね。。。
SSHだけを固くすることが有効なのか？
今回、大きな穴があった。。。というわけではないですが、SSHを鍵認証にすることにこだわるほど重要だったのか？という点についてです。
もちろんSSHのことだけを考えれば、より強固なセキュリティにすることは大事なことです。やって損はしません。
しかし、鍵が無くてもログインできるルート（道程）があり、そのルートはパスワードというもので守られている以上、SSHだけが鍵認証で堅くてもあまり意味がないということです。ましてや、管理者さんが、鍵の理解が乏しく、ミスってしまう程度のスキルではSSHだけを固くしても意味がないと思います。全体的なスキルの向上がひつであろうと思いました。
また、このサーバーには、WEBサーバーなどを操作するためのコントロールパネルが導入されており、マシン自体の再起動が可能です。そのコンパネにはファイルマネージャーといわれるものが装備されており、今回のようにファイルをクライアントに落として、編集した後、再度上書きアップロードすることで設定の書き換えは容易です。このコンパネ自身もパスワード認証です。と、言うことはパスワード認証で十分クラッキングができるということです。
結果、パスワードが漏れたらログインされ、荒らされるのは、SSHのカギの設定だけでは防御しきれないということです。
セキュリティを強固にするために行う必要があること
最後にまとめとしてセキュリティを強固にするために何が必要なのか、考えてみました。
SSHのみならず、クラック対策としてできうる限りの強固なセキュリティ対策を行う
こちらは鍵認証を採用することで鍵のペアが無い限りパスワードだけでもログインできないようにする設定は可能ですが、先述のように、ほかのツールがパスワードでログインできてしまう以上、それ以上の対応をしても無意味です。その癖に、鍵を作る作業が難しいと。。。そこで皆さん引っかかるわけです。
考えをもう少し柔らかくしてみましょう。
SSH以外に管理ツールにコンパネがある。ほかの方法でログインが可能、ファイアウォールの設定を簡単に修正できる場合
上記のような要件の場合、SSHに普段接続できないよいうにしてしまえばいいわけです。そうすると、セキュリティもへったくれもありません。起動していないのだから接続できないわけです。
今回の場合、VNC接続ができるのでSSHを普段はダウンさせておくという考えもありますが、それよりも、コントロールパネル内でファイアウォールの設定を容易に修正できるツールがありますので、SSHで利用するポート番号22番を普段はクローズしておけばSSH接続そのものが容易ではなく、接続できないという結論に至ります。もちろんポート転送などありとあらゆる技術を駆使すれば接続は不可能ではありませんが、総当たりをかけているようなクラッカーなら、ポートが締められている時点でもう攻めません。簡単に攻めてクラックできるマシンはネット上にごまんとありますから。
接続可能なIPアドレスに制限をかける
これも上記のファイアウォールで締めるという作業に近く、自分が作業するであろうIPアドレスだけを許可するようにすれば、ほかのIPでは接続そのものができなくなります。固定IPをとっている方なら容易ですし、そうではない方も自分が使っているIPアドレスをブロック単位で登録すれば許可されるのはたった数百個ということになります。
もちろんクラッカーが同じIPブロックを使っていた場合はログインされる可能性が出てきますが、その確率は40数億分の数百まで下がります。
まとめ～ログインできる人が自分以外を極力はじく設定をすることが堅いセキュリティへと近づきます～
コントロールパネルにしても、FTPにしてもSSHにしても同じですが、ログインを認めた人以外がログインできなくなってしまえばセキュリティは固くなると言えます。
FTPなどは結構放置されていますが、FTPログインされてしまうと、WEBサイトの買い残が容易にできてしまいますし、FTPのパスワード＝Linuxユーザのパスワードであることも多いので、結果マシンにログインされてしまう危険性をはらんでいます。
どのような接続であれ、必要な人以外が接続できなければいいわけですから、鍵認証などの高度なセキュリティも大事ですが、自分だけはログインできてほかの人ができなくなるという原始的なセキュリティをまずは意識するべきです。
たくさんのプロバイダを使ってログインする可能性があったり、様々な要素が絡んで接続先を限定できない要件がある場合は鍵認証は導入するべきです（そうじゃなくても鍵認証＋IP制限という強固なものにしておくのもいいでしょう。）しかし、ほとんどん場合、そのような要件はなく、数か所からの接続しか想定できない方が多いですし、ルールを決めれば限定可能なはずです。それらを踏まえて今、自らのサーバーのセキュリティは大丈夫ですか？
何かにログインされてしまうようでは、結局何かいたずらされる可能性が高いです。いいセキュリティ対策行っていますか？
最後に～鍵の間違いだったのか？正しい鍵でログインができるか～
結局、今回のお客様のものは、パスワードでログインできる状態にしてから、カギペアの中身を確認しましたところ、公開鍵、秘密鍵ともに内容が全く同じでした。
その時点でわかることとして、鍵＋鍵といいますか、錠前+錠前といいますか、これでは鍵で錠前を開ける。。。
というイメージからしてもあけることができるわけがありませんでした。普段使うカギと、スペアキーをもって、鍵をかけたいけど、南京錠が見当たらないよ？と言っているようなものですね。
一応テストで私が作ったカギペアでログインテストをしたところ、うまくログインできましたし、鍵なしでログインしようとすると、鍵なしエラーを吐きます。要はSSHの不具合ではなく、鍵の不具合です。しかも、同じツールを使って作ったカギで私はうまくいきますので、ツールの不具合でもありませんでした。
結果、運営者さんが理解不足で鍵の作成から保有の過程で訳が分からなくなったのだと思います。
Linuxに関するお問い合わせは、ココナラにて受け付けております。