パスワードを忘れた? アカウント作成
13914021 story
Linux

Fedora、rootユーザーによるsshパスワードログインのデフォルト無効化を検討開始 48

ストーリー by hylom
結局手動でいつも変えるんだよね 部門より
headless曰く、

Fedoraは今秋リリースのFedora 31に向け、rootユーザーによるsshパスワードログインをデフォルトで無効化すべく検討を開始したようだ(PhoronixFedora Wikidevelメーリングリストのスレッド)。

OpenSSHでは2015年からrootユーザーのパスワードログインをデフォルトで無効化しているが、Fedoraはデフォルト設定を変更してパスワードログインを許可し続けていた。しかし、Linuxのrootログインは攻撃者に狙われやすい部分であり、パスワードはその弱点となっている。Fedoraがパスワードログインを許可し続けてきたのにはさまざまな実用的な理由があるものの、OpenSSHのデフォルトとの違いが許容できない段階に達しており、ユーザーの期待するデフォルト設定にも反するため変更が必要になったとのこと。変更後も公開鍵認証やGSS-API認証は影響を受けない。

一方、この設定に依存するものも多く存在するため、対策の検討も必要となる。最終的にはFedora Engineering Steering Committee(FESCo)での採決が必要になるが、develメーリングリストで強い反対意見は出ておらず、Fedora 31ではrootユーザーのsshパスワードログインがデフォルト無効になる可能性が高いとみられている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2019年05月21日 15時07分 (#3618446)

    root自体とかrootのパスワードをなくすとか…他はやってるんだし。

    • by Anonymous Coward on 2019年05月21日 15時56分 (#3618470)

      sudoは操作ミスで致命的な事態になるのを防ぐにはいいんだけどセキュリティ的には問題ありすぎる
      sudoできるアカウント(非root)が乗っ取られたらsudoコマンド自体が不正なものに書き換えて、入力されたパスワードをクラッカーに送信するように改変できる
      あとはクラッカーがその乗っ取ったアカウントにログインして入手したパスワードでsudoすればroot権限で任意のコマンドが実行可能

      sudoできるアカウントを乗っ取ったら事実上rootを奪えるので、rootになれるアカウント(sudoできるアカウント)が増える分だけリスクが高まるといえる

      親コメント
      • by Anonymous Coward on 2019年05月21日 16時08分 (#3618476)

        ほんとそれ、そのへんの権限周りで他の良い方法が出来ないかなぁ

        sudoコマンド自体が不正なものに書き換えて、入力されたパスワードをクラッカーに送信するように改変できる

        ただこの表現だとわかってない人は「どうやってrootの所有のファイル/usr/bin/sudoを書き換えるんだよw」みたいな勘違いした反応がありそう

        要は本物のsudoの実行ファイル自体はそのまんまでも各ユーザーが陥落した時点でそのユーザーのホームに偽sudoバイナリ置いてPATHいじるなりシェルのaliasなりで偽のsudo使うようにできちゃうのよね
        んでそれに気づかずに偽のsudoにパスワード入力しちゃってrootの権限がウンタラカンタラって

        親コメント
        • by Anonymous Coward

          sudo できるアカウントって、 Windows で言うところの Administrators グループのユーザみたいなものだから、
          乗っ取られるような運用している時点でだめなんじゃないですかね?

          Administrators グループの権限で cmd.exe 置き換えられる!って騒いでるような感じ?

          • by Anonymous Coward

            そんな感じだけど、Windowsの場合UACが有るからねぇ……
            UACの確認画面はすり替える意味すら無いのだけど、
            それと同等の安全確保がsudoには無いってのがキモかな。
            # あとコマンドすり替えはsuでも怖い。
            ログイン等にCTRL+ALT+DEL使うようなプロテクトがCUIでは困難、てのがな……

            まぁUACにしても予め特権を得た際に実行する処理を決めておいて、
            確認画面が出るような操作の際に正規の操作の代わりにそっちの処理でUAC承認取れば攻撃は出来るんだが。

            • by Anonymous Coward

              UACはさまざまな手段でバイパス可能で、MSはそもそもセキュリティ機能ではないから仕様って言ってるじゃん。すり替えだったらカレントディレクトリが勝手に検索されて無効にできないし実行可能パーミッションに存在するものがあるにはあるけどまったく運用されていないも同然のWindowsのほうが圧倒的に簡単だ。

              • by Anonymous Coward

                特権の利用可否を問うダイアログを表示するに当たり通常外のコンソールに切り替える機能があるか否かってだけの話なんで。
                最終的な安全の話に持っていってまで反論してもそこに意味はないですよ。
                単方向でテキストのストリームでコンソール出せる以上、致し方の無い仕様なんだから素直に諦めときなさい。

            • by Anonymous Coward

              例えば、攻撃者が runas.exe 置き換えて外部にパスワード流すようにしていたら
              sudo 置き換えられたのと何も変わらんわ
              UAC が表示されたってそれが正規の操作中に起きた内容ならなんも気づかないでしょ

              sudoers や Administrators グループのユーザ取られた時点でアウトだよ

              • by Anonymous Coward

                元コメの最後二行がその手のリスクの話なんだが。
                特権の利用に専用のコンソールが入る事で攻撃に制限が生じるって話であって完全な防御って話では無い。

      • by Anonymous Coward

        2段階認証sudoとか?
        携帯電話やスマホにセキュリティコードのメールが飛んでくるみたいな。

        • by Anonymous Coward

          それLinuxのディストリに実装するの?いやFedoraならやってくれるはず!

          • by Anonymous Coward

            PAM の sudo に google authenticator とか設定すれば良いんじゃないの?
            ubuntu では出来ていたような記憶があるけど、Fedora でも似たような感じじゃないかな・・・

      • by Anonymous Coward

        通常使用するアカウントはsudoできないようにして、sudo専用アカウント作ればいいんじゃない。
        そもそもsudoできるアカウントをばらまくから問題なのでは。

        • by Anonymous Coward

          sudo専用アカウントがばらまかれるだけかと。

          • by nim (10479) on 2019年05月22日 17時06分 (#3619227)

            その必要があるなら、もし sudo 使ってなかったら、 かわりに root のパスワードがばらまかれるだけでは?

            親コメント
            • by Anonymous Coward

              sudoじゃないユーザで通常作業
              sudoできるアカウントで管理作業

              ・・・って普通じゃないの?
              rootのパスワードなんて必要ないよね?

    • by Anonymous Coward

      sudoめんどくさー

  • by Anonymous Coward on 2019年05月21日 15時08分 (#3618447)

    今さらというか、ようやく対応ですね。
    遅くてもやらないよりはマシ。

  • by Anonymous Coward on 2019年05月21日 15時49分 (#3618465)

    sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。
    パスワード認証だろうと通信自体は暗号化されるし、なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。
    つまり、ブルートフォースアタックに弱いだけですので、「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。
    多くの組織の場合、パスワードの前半部分をメモして担当者の手帳と会社の金庫に入れておき、後半部分は他の記憶させる(他のパスワードなどとも使いまわしだったりするが)などの安全対策をしているはずです。
    パスワード漏洩=危険 は分かりやすいですから、多くの組織ではそれなりの管理になるわけですね。

    一方、これが公開鍵認証になると、秘密鍵をUSBメモリに入れておく、終業時には金庫に入れるといった運用になり、物理的に泥棒が入ったらアウトです。下手したら面倒になってデスクに放置されたり、担当者が出先で落としたりするリスクもあります。更に酷いと操作用のノートPCにコピーされるかもしれません。
    秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。

    秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。

    • sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。

      中間経路でのなりすまし攻撃に対して公開鍵認証と比べたらパスワード認証の方が弱いというのは事実でしょう。

      なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。

      まともな運用が出来ていればいいのですが、『日本の運用』を考えた場合、「取り合えずyesと入力しろ」とか「訊かれたくなければStrictHostKeyChecking=noに設定しろ」等の情報が氾濫している現状から、あまり考えもせずにyesを入力するケースも有りそうです。
      実際、Tera Termにも「警告を抑制できるようにして欲しい」という要望が多く来たのに負けて /nosecuritywarning [ttssh2.osdn.jp] を追加してしまいましたし。
      # 実際には海外からも要望が来ていたので日本に限ったものではないかもしれませんが

      そしてホスト鍵の確認が不十分な時はパスワード認証は脆弱で、中間者攻撃が行われている場合は接続先が本物のホストだった(ように見えた)時でも安全ではありません。
      一方、公開鍵認証は(認証に関しては)安全ですし、本物のホストのホスト鍵が変わったのか、それとも中間者攻撃が行われているかの判別も可能です。(中間者攻撃の場合は認証が失敗する)

      「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。

      14文字ありますが

      • 使われている記号が : だけ
      • 大文字のFが3度使われている

      など、かなり使われている文字に偏りが有りますね。
      それらをおまけして"英大文字"/"小文字"/"数字"/"記号"の四種類、計95文字の中から14文字と考えると92bit程度の強度ですね。
      これはRSA 1024bit鍵の80bit相当よりは安全ですが、現在主流のRSA 2048bit鍵の112bit相当やED25519鍵の128bit相当よりはかなり落ちます。
      # 最新のOpenSSHではRSA鍵はデフォルトで3072bit(128bit相当)を生成するように変わりました

      また、このパスワードは「英大文字/小文字/数字4桁を3つ作り、それを : で繋げる」というルールで作られているようにも見えます。
      この場合は72bit程度の強度になるので、今はもう使うなと言われているRSA 1024bit鍵よりも弱い事になります。
      # まあそれでもオンラインでのブルートフォース攻撃だけを想定するならば十分ではありますが

      秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。

      秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。

      他のコメントでも指摘されていますが、OpenSSH標準で秘密鍵は暗号化されますし、パスフレーズを付けて保護されるのが一般的です。
      一般的には行われていない運用を仮定してそれをもって公開鍵認証の方が脆弱だとするのは不公平な比較でしょう。前述したパスワード認証の問題も評価出来ていませんし。

      親コメント
    • by Anonymous Coward

      多くの組織の場合、パスワードの前半部分をメモして担当者の手帳と会社の金庫に入れておき、後半部分は他の記憶させる(他のパスワードなどとも使いまわしだったりするが)などの安全対策をしているはずです。

      それはあなたの想像ではないでしょうか

      • by Anonymous Coward

        2人揃わないと開けられない的な? 核ミサイルスイッチかよ。

        • by Anonymous Coward

          インド辺りの核スイッチの方が緩かったりしてね。

    • by Anonymous Coward

      パスフレーズ無しの鍵認証なんて何らかの自動化目的以外で使われること
      あんまりないと思うけどなあ。

      • by Anonymous Coward

        だよねえ。

        それはそれとして、秘密鍵がパスフレーズで保護されているとしても、
        もし鍵ファイルが盗まれたら盗んだ奴のローカルな環境でブルートフォースアタックが可能なのに対して、
        パスワード認証は(まともな)サーバーならブルートフォースアタック対策が出来てるはずだから、
        そういう意味じゃ公開鍵認証のほうが柔いって言えるかな?

        • ssh 鍵のパスフレーズを忘れたら [improve-future.com] の方法でブルートフォース解析できます。
          オフラインで解析できるので早いですよ。

          親コメント
          • by Anonymous Coward

            John the Ripper使ってる時点でかなり古くないか?この情報。それにブルートフォースで破れるパスフレーズって、どんだけ弱いんだ?解析はできます、でも結果は出るかわかりませんってことか?

          • by Anonymous Coward

            その記事にも
            > (実際のところ Minlen = 3, MaxLen = 10, CharCount = 62 だとまず終わらないです。)
            と書いてあるんですが…

            ブルートフォース解析できたのは、パスフレーズが短かったからです
            あなたの職場はsshを正しく運用できてないし、正しいsshの使い方も知らないのでしょう

        • by Anonymous Coward

          >パスワード認証は(まともな)サーバーならブルートフォースアタック対策が出来てるはずだから、
          え。どんな?鍵認証使うより簡単に?
          使ってるなぁパスフレーズ無しの鍵認証。パスフレーズ付けるぐらいなら鍵認証使わない。

          • by Anonymous Coward

            秘密鍵が絶対に盗まれないと自信を持って言えるなら、
            パスフレーズなしでも良いのかもしれないけど、
            普通はパスフレーズつけますわな。

            秘密鍵を盗むことができれば、秘密鍵に対してローカルでブルートフォースアタックが可能。
            # ただ、パスフレーズが十分な長さを持っていれば、攻撃は実質不可能。
            パスワードはブルートフォースアタックが来ても、
            サーバでアカウントがロックされるなどするので攻撃は不可能。

    • by Anonymous Coward

      sshでroot loginできること自体の是非は別にあるとして、
      sshの「公開鍵認証はパスワード認証よりも安全」みたいな誤解はどうにかして欲しいですねマジで。

    • by Anonymous Coward

      > 多くの組織の場合、パスワードの前半部分をメモして担当者の手帳と会社の金庫に入れておき、後半部分は他の記憶させる

      そんな組織見たことねぇな
      忘れたら再発行・再登録なのはよく見るけど

      > 秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではない

      えぇ!OpenSSHのパスフレーズ対応は標準じゃない???

      # あれ、俺の生きてる世界が変わったのか?

      • by Anonymous Coward

        異世界転生ですか、おめ。

        おそらく元コメは公開鍵暗号というものを理解していないだけかと。
        きっと秘密鍵を共有しちゃうんでしょうね。
        何故にsshの秘密鍵を金庫で保存せにゃならんのだ。

    • by Anonymous Coward

      ssh-keygen
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/whoami/.ssh/id_rsa):
      Enter passphrase (empty for no passphrase):
      標準で聞いてくるよなあ…emptyにするのが標準なんだろうか?あと、秘密鍵暗号化に対応してないSSHクライアントってなんだろ?これってネタとか釣りなのかな?

      パスワード認証許可だと、パスワードを使いまわされた結果別のところから漏洩することになるから、やっぱり公開鍵+暗号化だよなあ?パスワード変更不可ならまだしも…

      • by Anonymous Coward

        パスワード認証許可だと、パスワードを使いまわされた結果別のところから漏洩することになるから、やっぱり公開鍵+暗号化だよなあ?パスワード変更不可ならまだしも…

        使いまわすのは秘密鍵も同じでは?
        PuTTYgenとかで作って同じのサーバにアップして使いません?

        VPS50台管理していたら50セットもキーペア作るんですか?

        • > VPS50台管理していたら50セットもキーペア作るんですか?
          自分の周りの場合基本的に接続元端末毎に接続先台数分作る
          ~/.ssh/config に書いとけばいいし
          親コメント
        • by Anonymous Coward

          使いまわしても、自分の端末から漏洩することはあっても
          別のところから漏洩はしないでしょw

          • by Anonymous Coward

            ちゃうちゃう、秘密鍵自体をみんなで共有しやがるの。
            だから同じ秘密鍵がいろんな端末に入っているという。
            その時点で漏れたとみなすべきだろうけど、彼女らはそういう認識を持たない。
            何言っているんだって思おうかもしんないけど、そういう運用する馬鹿多い。
            というか、運用に携わるITエンジニアってそんなばっか。

        • by Anonymous Coward

          秘密鍵の使いまわしって、基本SSHでしかやらないでしょう?パスワードはWindowsのサインインに始まり、GmailだFaceBookだYahooだOffice365だAppleIDだ、全部同じにしている人が結構いるわけです。haveibeenpwned.comで検索するとまあ出るわ出るわ。この理由だけでパスワードはだめなんです。使いまわしの抵抗感がほぼゼロなんです。

      • by Anonymous Coward

        パスワード使い回すのって、パスワードをpasswordにしたり、
        秘密鍵の入ったモバイルPCやUSBメモリにパスフレーズ書いた付箋貼っとくのと同じぐらいアホなことなので、
        そんなアホのやることまで考えてたら、どっちもどっちじゃろ

        • by Anonymous Coward on 2019年05月21日 19時12分 (#3618593)

          はははは…。
          https://it.srad.jp/story/19/03/13/0457206/ [it.srad.jp]

          IT従事者でもこのざまなのに、ガチ素人相手にシステム運用してる社内SEとしては、そんな正論空しいだけだな。

          親コメント
          • by Anonymous Coward

            初期パスワード渡して変えてもらうようなシステムならよいのだが、そうもいかないシステムでユーザに希望するパスワードを提出してもらうと、
            それ他のサービスでも使いまわしてるだろ…みたいなパスワードを無邪気に提出してくるので知るのが怖い。

            • by Anonymous Coward

              銀行口座の乱数表カードっていろいろ考えられてるなと気づかされるな。
              口座ごとに固有のものだから使いまわしできないし、書留で郵送することで二段階認証にもなっている。

              ただしログインのたびに乱数表見るのはめんどくさすぎるので、振り込みなどの一部のオペレーションのみに要求されるsudo的な位置づけか。

    • by Anonymous Coward

      >安全対策をしているはずです。
      思い込むのは自由ですが、実際は直接リモートログイン可能だけならまだマシで、rshダイレクトに叩けるようにしてたとこがありました。
      rootです。
      絶句しましたね。

  • by Anonymous Coward on 2019年05月22日 22時14分 (#3619474)

    元に戻す方法を教えてください。
    という質問がRHEL9のサポート窓口に来るようになると、今から予測。

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...