場合によっては、パスワードのないサーバーを好むことを認める必要があります。一般的なサーバーは、物理的にアクセスできるすべての人に脆弱です。したがって、場合によっては、物理的にロックして信頼することが可能です。どの物理的なアプローチ。
基本思想
理論的には、実際にそのようなサーバーに接続するときにパスワードなしでログイン名を入力するだけで管理タスクを実行できる必要があり、root
パスワードを要求しないでください。ユーザーアカウントにも同様に適用されますが、人々は実際にそのアカウントに物理的にアクセスすることはできません。したがって、(時には)ローカルアクセスにはシステムパスワードは必要ありません。
管理アカウントでもユーザーアカウントでも、リモートでサーバーにアクセスするときは、常にSSH秘密鍵を使用するのが好きです。作成したアカウントのSSHキーを簡単に設定できるため、(定期的に)リモートアクセスにシステムパスワードは必要ありません。
# user=...
#
# useradd -m "$user"
# sudo -i -u "$user"
$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"
結論は理論的にはそうする必要はないということだ。どの同様のユースケースのシステムパスワード。したがって、問題は、これが一貫して安全な方法で発生するようにシステムとユーザーアカウントをどのように構成するかです。
ローカルアクセスの詳細
パスワードなしでルートアカウントにローカルにアクセスできることを確認する方法は?ルートアクセスがpasswd -d
許可されすぎて権限がないユーザー変化無料ルート、これは間違っています。passwd -l
ログインを妨げるため使用できません。
ローカルアクセスには、ローカルキーボードを使用したアクセスのみが含まれます。非常に効果的なソリューション必然ではないすべてのユーザーが切り替えることを許可します(使用su
または関係なくsudo
)。
リモートアクセスの詳細
最近まで、上記の解決策は機能していましたが、SSHはロックされたユーザーアカウントの確認を開始します。passwd -d
同じ理由で使用できない場合があります。passwd -u
それがどのような結果につながるかについて不平を言うので、私たちはそれを使用することはできませんpasswd -d
。
この部分にはダミーパスワードを使用する解決策があります。
user=...
echo -ne "$user:`pwgen 16`\n" | chpasswd
SSHでロックされたアカウントの確認を完全にオフにすることもできますが、ロックされたアカウントのサポートを維持してロックを解除することをお勧めします。
最終メモ
私が興味を持っているのは、ルートアカウントにローカルにログインし、パスワードなしでルートを含むすべてのアカウントにリモートでログインできるソリューションです。一方、ソリューションは明確に説明されている方法、特にリモートユーザーがrootアカウントまたは他のユーザーのアカウントにアクセスすることを許可しない場合を除き、セキュリティに影響を与えてはなりません。ソリューションは間接的にセキュリティ上の問題を引き起こさないほど強力でなければなりません。
承認され、承認された回答には、個々のツールの詳細な構成を説明したり説明したりすることはできませんが、指定された目標を達成するための重要な事項を含める必要があります。passwd
などの一般的なツールを使用すると、この問題が解決しないことがありますssh
。su
sudo
最初の回答を読んだ後のより多くのアイデア
考えると、ログインプロセスの代わりにルートシェルを起動してローカルルートアクセスを取得できます。ただし、まだ公開鍵の確認ではなく、パスワードの確認だけをロックするだけです。
ベストアンサー1
ソリューションの要件を主なものとして提供します。
- パスワードのないルートコンソールログイン
- パスワードなしで事前承認されたユーザールートリモートログイン
- 事前承認されたカスタムアカウントへのパスワードのないリモートログイン
- 事前承認されたユーザーのすべてのアカウントは、パスワードなしでリモートでログインできます
次の例は、私がここでテストしている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
このファイルは、UNIXログインが成功した場合にcommon-auth
ルールをスキップするように(拒否)PAMに指示します。一般的にこれは/etc/shadow
。
このauth ... pam_securetty.so
行は、で指定されたttyデバイスを除いてルートログインを防ぐように設定されています/etc/securetty
。 (このファイルにはすでにすべてのコンソールデバイスが含まれています。)
この行を少し変更すると、auth
ルートログインを許可するルールを定義できます。パスワードなしで指定されたttyデバイスで/etc/securetty
。一致が成功した場合は、スキップされた行数に置き換えるようにsuccess=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
パスワードなしで事前承認されたユーザールートリモートログイン
これは、認証されたユーザーのSSHキーをルートauthorized_keys
ファイルに直接含めるためのものです。
事前承認されたカスタムアカウントへのパスワードのないリモートログイン
これには、認証されたユーザーのSSHキーが直接含まれ、そのユーザー.ssh/authorized_keys
ファイルに追加されます。 (典型的なリモートユーザーchrisは、パスワードなしでローカルユーザーchrisにログインしようとします。想像する。 )
作成後、アカウントはデフォルトでロックされたままになりますが(つまり、!
パスワードフィールドでのみ/etc/shadow
)、SSHキーベースのログインは許可されます。新しいユーザーのファイルにキーを入れるにはrootが必要です.ssh/authorized_keys
。何ですかあまりにも明らかではないはい、この方法はUsePAM Yes
中間設定でのみ使用できます/etc/ssh/sshd_config
。 PAMは!
、「パスワードによりアカウントがロックされていますが、他のアプローチは許可される可能性があります」と「アカウントがロックされています。!...
それはすべてです」と区別します。 (UsePAM No
設定されている場合、OpenSSHは!
ロックされたアカウントを示すために開始パスワードフィールドの存在を考慮します。)
事前承認されたユーザーのすべてのアカウントは、パスワードなしでリモートでログインできます
あなたがこの施設が欲しいかどうかはわかりません。つまり、一部の認証済みユーザーは、パスワードなしでSSHを介してすべてのローカルアカウントにログインできます。
これをテストすることはできませんが、OpenSSH 5.9以降では可能だと思います。これにより、2番目の名前を含むように設定ファイルをauthorized_keys
編集できます。選択した認証済みユーザーの公開鍵をこのファイルに追加します。 rootが所有し、rootのみが書き込み権限(0644)を持ちます。/etc/ssh/sshd_config
/etc/ssh/authorized_keys