SSHを使用したパスワードレスアカウントへの一貫した安全なアプローチ


12

場合によっては、パスワードのないサーバーが好きであることを認めなければなりません。一般的なサーバーは、物理的にアクセスできるすべてのユーザーに対して脆弱です。そのため、場合によっては物理的にロックしてから、物理的なアクセスを信頼することが実用的です。

基本概念

理論的には、このようなサーバーに物理的にアクセスする場合root、ログインとして入力するだけでパスワードなしで管理タスクを実行でき、パスワードを要求されることはありません。同じことがユーザーアカウントにも当てはまりますが、実際には物理的にアクセスすることはありません。したがって、(時々)ローカルアクセスにシステムパスワードは必要ありません。

管理またはユーザーアカウントのいずれかでサーバーにリモートでアクセスする場合、常にSSH秘密キーを使用することを期待しています。作成したばかりのアカウントにSSHキーを設定するのは非常に簡単なので、(通常の)リモートアクセスにシステムパスワードは必要ありません。

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

結論は理論的には、我々はneeedいないだろう、ということですどのようなユースケースのためのシステムパスワードを。そこで問題は、システムとユーザーアカウントをどのように構成して、それを一貫性のある安全な方法で実現するかです。

ローカルアクセスの詳細

パスワードなしでrootアカウントにローカルにアクセスできるようにするにはどうすればよいですか?passwd -dルートアクセスを許可しすぎて、権限のないユーザーが無料でルートに切り替えることができるため、使用できないと思います。これは間違っています。passwd -lログインできないため使用できません。

ローカルアクセスは、ローカルキーボードを使用したアクセスのみに関することに注意してください。したがって、有効なソリューションで、ユーザーの切り替えを許可してはなりませんsuまたはを使用sudo)。

リモートアクセスの詳細

最近まで上記のソリューションは機能していましたが、SSHはロックされたユーザーアカウントのチェックを開始しました。passwd -d同じ理由で使用できない可能性があります。それがpasswd -u何をもたらすのか不平を言っているだけなので、私たちは使用できませんpasswd -d

この部分にダミーのパスワードを使用する回避策があります。

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

SSHでロックされたアカウントチェックを完全にオフにすることも可能かもしれませんが、ロックされたアカウントのサポートを保持し、それらのロックを解除できる方がよいでしょう。

最終ノート

私が興味を持っているのは、パスワードなしで、ローカルアカウントと、rootを含むすべてのアカウントにリモートでログインできるソリューションです。一方、ソリューションは、特にリモートユーザーがルートアカウントまたは他のユーザーのアカウントにアクセスできるようにすることによって、明示的に説明されている方法を除き、セキュリティに影響を与えてはなりません。ソリューションは、間接的にセキュリティ問題を引き起こさないように、十分に堅牢でなければなりません。

承認されて授与された回答には、個々のツールの詳細な構成が記載されている場合とされていない場合がありますが、記載された目標を達成するための重要なポイントを含める必要があります。これはおそらくのようなツールの従来の使用では解決できないことに注意してくださいpasswdsshsusudoなどが挙げられます。

最初の回答を読んだ後のアイデア

アイデア-ローカルルートアクセスは、ログインプロセスの代わりにルートシェルを起動することで実現できます。ただし、公開鍵認証ではなく、パスワード認証のみをロックする必要があります。


パスワードなしのローカルアクセス用にカスタマイズされたPAM構成を使用し、sudoおよびSSHログオンに対して同じことを行います。
0xC0000022L

回答:


5

箇条書きとしてソリューションを提供する要件:

  1. パスワードなしのルートコンソールログイン
  2. 事前認証ユーザーからのパスワードなしのルートリモートログイン
  3. 事前承認されたユーザーからの指定されたアカウントのパスワードなしのリモートログイン
  4. 事前承認ユーザーからのアカウントのパスワードなしのリモートログイン

以下の例はDebianをベースにしています。これは私がテストのためにここに持っているものだからです。しかし、どのディストリビューションにも(または実際PAMベースの* ix派生物にも)原則を適用できない理由はありません。

パスワードなしのルートコンソールログイン

これにアプローチする方法は、PAMと/etc/securetty構成ファイルを活用することだと思います。

前提条件として、「十分に安全な」ルートパスワードを設定する必要があります。これはコンソールログインには必要ありませんが、ブルートフォースクラッキングの試行を非現実的にするために存在します。それ以外の場合、アカウントは完全に通常のルートアカウントです。

では/etc/pam.d/login、私が認証(キーワードで始まるこれらの行の次の標準セットを持っていますauth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

参照さcommon-authれるインクルードファイルには、次の関連する行が含まれます。

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

このcommon-authファイルは、「UNIXログイン」が成功した場合に1つのルール(拒否)をスキップするようにPAMに指示します。通常、これはの一致を意味し/etc/shadowます。

このauth ... pam_securetty.so行は、で指定されたttyデバイスを除き、rootログインを防止するように構成されてい/etc/securettyます。(このファイルにはすでにすべてのコンソールデバイスが含まれています。)

このauth行をわずかに変更することにより、で指定されたttyデバイスからのパスワードなしでルートログインを許可するルールを定義することができます/etc/securettysuccess=okパラメータは、なるように修正される必要があるokの数に置き換えられてauth成功した試合のイベントにスキップする行。ここに示されている状況では、その数は3であり、次のauth ... pam_permit.so行にジャンプします。

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

事前認証ユーザーからのパスワードなしのルートリモートログイン

これは、ルートauthorized_keysファイルに追加される許可ユーザーのsshキーを簡単に含めることです。

事前承認されたユーザーからの指定されたアカウントのパスワードなしのリモートログイン

これは、適切で対応するユーザーの.ssh/authorized_keysファイルに追加される承認済みユーザー用のsshキーを簡単に含めることでもあります。(一般的なリモートユーザーchrisは、ローカルユーザーchrisシナリオへのパスワードなしのログインを望んでいます。)

アカウントは、作成後もデフォルトのロック状態(つまり!、のパスワードフィールドのみ/etc/shadow)のままにすることができますが、SSHキーベースのログインを許可することに注意してください。新しいユーザーの.ssh/authorized_keysファイルにキーを配置するには、rootが必要です。それほど明白でないのは、このアプローチがUsePAM Yesで設定されて/etc/ssh/sshd_configいる場合にのみ利用可能であるということです。PAMは!、「パスワードはアカウントがロックされていますが、他のアクセス方法は許可されている可能性があります」と!...「アカウントはロックされています。期間」と区別します。(UsePAM No設定されている場合、OpenSSH !はロックされたアカウントを表すためにパスワードフィールドの開始の存在を考慮します。)

事前承認ユーザーからのアカウントのパスワードなしのリモートログイン

この施設が必要かどうかは、私には完全にはわかりませんでした。つまり、特定の許可されたユーザーは、すべてのローカルアカウントにパスワードなしでsshログインできます。

このシナリオをテストすることはできませんが、これはOpenSSH 5.9以降で実現できると考えています。OpenSSH5.9以降では、複数のauthorized_keysファイルをで定義できます/etc/ssh/sshd_config。構成ファイルを編集して、という2番目のファイルを含めます/etc/ssh/authorized_keys。選択した許可ユーザーの公開鍵をこのファイルに追加します。これにより、rootが所有し、rootのみが書き込みアクセス権(0644)を持つように許可を設定します。


#1をより注意深く調べ、テストする必要があります。(強力な)パスワードを設定する必要がありますが、非常に興味深いものです。#3は、最近ではSSHログインからもデフォルトで新しく作成されたユーザーがロックされるため、完全ではありません。私はポイント4を本当に要求しませんでしたが、とにかく非常に面白そうに見え、実際にそのような方法を使用するかもしれません。
パベルシメルダ

rootの強力なパスワードは必須ですが、使用されることはありません。#3の実装方法を知っていると仮定しました。詳細が必要な場合はお知らせください。(Debian)システムでは、.ssh/authorized_keysファイルに関連する公開鍵が含まれていれば、まだパスワードが定義されていない新しいアカウントにsshすることができます。これは役立ちますか?
ロアイマ

Debianで見られる動作を回復するための素敵で標準的な方法が必要だと思います。つまり、新しく作成されたアカウントは、パスワード認証のためだけにロックされ、公開キーのアカウントに対してはロックされません。
パベルシメルダ

前のコメントのsshステートメントを確認するために作成したテストユーザーアカウントの場合!、のパスワードフィールドにシングルが表示されます/etc/shadow。manページによると、これはパスワードが一致しない有効なアカウントを示します。
ロアイマ

1
それはおもしろい、それは少なくともそれほど明白ではない、ありがとう。
パベルシメルダ

1

sshキーとフルNOPASSWDアクセスを使用した実際の(非ルート)ユーザーアカウントが必要なようです(sudo最近のほとんどのLinuxディストリビューションではデフォルトで使用可能で、手動でのインストールも簡単です)。各ユーザーアカウントに空のパスワードを設定して(リモートでは機能しません)、ユーザーを実行するsudo -sか、ユーザーの~/.bash_profileコマンドにそのコマンドのみを含めることができます。

須藤

各ユーザーをsudoUNIXグループに追加します(たとえばusermod -a -G sudo USERNAME、古いシステムではこれを行う方法は直感的ではありませんが、最悪の場合、/etc/groups直接編集します)。

では/etc/sudoersまたは/etc/sudoers.d/local、次のような行をしたいです:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

自動ルートアクセスが必要な場合は、これをユーザーのプロファイルに追加します。の場合bash、それは次のようになります~/.bash_profile

sudo -s

これにより、誰がログインしているか(whoまたはlast)を確認でき、ログインしたままになり/var/log/auth.logます。

パスワードなしのログイン

はるかに古いシステムでは、ハッシュを編集して/etc/passwd(または少し古いシステムで/etc/shadow)ハッシュを削除することbob:$1$salt$hash:12345:0:99999:7:::ができbob::12345:0:99999:7:::ます。これで十分です。現代のシステムはこれを好まない。これを行う方法は他にもある可能性がありますが、確認した方法は次のとおりです(出典:Leo's Random Stuff

/etc/shadow実際の情報でアカウントを開いて観察します。これには、ドル記号($)で区切られた3つの要素が含まれます。これらはハッシュメカニズムを表し、次にsalt、次にハッシュを表します。ソルトに注意して、これを実行します:

openssl passwd -1 -salt SALT

(これはハッシュメカニズムとしてMD5を使用します。これは空のパスワードなので、気にする必要はありません。)パスワードの入力を求められたら、Enterキーを押します。末尾のドットを含むその文字列を保存し、そのユーザーの行の最初のコロンの後に貼り付けます/etc/shadow(これにより、最初と2番目のコロンの間の既存のコンテンツが置き換えられます)。(文字通りSALTあなたの塩として使用しないでください!)

SSH

あなたのsshデーモンの構成は、のいずれかで住んでいます/etc/sshd_config/etc/ssh/sshd_config。適切なセキュリティのために、次の行を含めることをお勧めします。

PermitRootLogin no
PermitEmptyPasswords no

ssh構成に追加できるセキュリティ対策については、Secure Secure Shellの記事を参照して、高度な攻撃者に対するセキュリティを強化してください。

空のパスワードがあるため、ユーザー経由でログインできなくなりましたssh(これは必要なセキュリティ対策です)。これは、sshキーでしかログインできないことを意味します。

各ユーザーは、クライアントシステムごとに、sshキーペアを作成する必要があります。たとえば、

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

これにより、秘密鍵$HOME/.ssh/id_rsaとで公開鍵が生成され$HOME/.ssh/id_rsa.pubます。そのユーザーに公開鍵を送信して、このサーバーに追加してもらいます$HOME/.ssh/authorized_keys(各ユーザー$HOME/.sshはモード700でなければならないことに注意してください(例:)mkdir -p ~user/.ssh && chmod 700 ~user/.ssh)。

SSHキーを必要としないユーザーは、物理システムにアクセスできます。そこで、彼らの空のパスワードはそれらにログインし、その時点でpasswdシェルから入力してパスワードを設定し、リモートアクセスを許可します。

(私は実際に私はIT部門を実行したときに戻って人々にシステムのコレクションへのアクセスを与えるためにこの手法を使用これは、SSHキーを使用するようにユーザーを強制的に、私はパスワードそれらを与える必要はありませんでした彼らの初期は、。。~/.bash_profile一番下の2行を持っていました: passwdその後mv ~/.bash_profile.real ~/.bash_profile、最初のログイン時に新しいパスワードを設定します。)

リスク

ユーザーを完全に信頼しています。ユーザーが別のユーザーの~/.ssh/authorized_keysファイルをいじって、アクセスを取り消して監査する機能を変更することを妨げるものはありませんが、完全なルートアクセスを許可している場合、これは避けられません。

結論

各ユーザーはsudoグループのメンバーになり、ルートシェルへの完全なパスワードなしのアクセス権を持ちます。これらのユーザーにはアカウントのパスワードがなく、sshキーを使用してリモートでログインできます。

従業員の1人を失った場合、そのアカウントを削除できます。従業員のラップトップの1つが盗まれた場合、そのラップトップのsshキーをそのユーザーのauthorized_keysファイルから削除できます。セキュリティ侵害がある場合、ログインしたユーザーを示すログがあります。


sudoに関する部分は、ユーザーの切り替えではなく、新規ログインに関するものであるため、質問を見逃しています。質問をより明確にするために修正しました。パスワードなしのログインに関する部分passwd -dは、質問とまったく同じ間違った動作を示し、suパスワードなしでそのユーザーに切り替えることができます。リスクのセクションでは、2つのこと(他のユーザーのデータをいじり、ルートアクセスを取得する)について説明します。その削除がまさに問題のポイントです。したがって、個々のセクションはうまく書かれていますが、これは決して質問に対する答えではありません。
パベルシメルダ

ユーザーを追加してからユーザーを制限すると仮定しました。
アダムカッツ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.