パスワード認証ではなく、公開キーssh認証のためにアカウントのロックを解除する方法は？

アカウントがロックされているため、sshはログインを許可しません。sshを介した公開キー認証のためにサーバー上のユーザーのロックを解除したいのですが、パスワードによるログインを有効にしません。

私はもう試した：

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

認証ログエントリ：

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

アカウントのロックを解除し、@ Skaperenが示唆するようにユーザーに複雑なパスワードを与えます。

以下を編集/etc/ssh/sshd_configして確認します。

PasswordAuthentication no

行がコメントさ#れていないこと（開始時）を確認し、ファイルを保存します。最後に、sshdサービスを再起動します。

これを行う前に、公開鍵認証が最初に機能していることを確認してください。

1人（または少数）のユーザーに対してのみこれを行う必要がある場合は、PasswordAuthentication有効のままにして、代わりに使用しますMatch User。

Match User miro, alice, bob
    PasswordAuthentication no

次のMatchコマンドまたはEOF まで有効であるため、ファイルの下部に配置します。

Match Group <group name>または否定を使用することもできますMatch User !bloggs

コメントで述べたように、設定のメイン部分でパスワード認証を無効にし、Matchステートメントを使用して少数のユーザーに対して有効にするように、逆にすることもできます。

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

何をするにしても、アカウントをpasswd -u空白のパスワードフィールドを残した状態のままにしないでください。これにより、パスワードを入力せずにログインできます（SSHは拒否するため、SSH経由を除く）。

パスワードを持たないようにアカウントを変更しますが、ロック解除します。パスワードデータベース内のパスワードハッシュが文字列のハッシュでない場合、アカウントにはパスワードがありません。伝統的に、のような1文字の文字列*または!そのために使用されています。

ロックされたアカウントは、パスワードフィールドで特別なマーカーを使用して、文字列が文字列のハッシュにならないようにします。マーカーはシステムに依存しています。Linuxでは、passwdコマンド!は先頭にを付けることでロックされたパスワードをマークし、フィールドがで始まる場合、OpenSSHはアカウントをロックされたものとして扱います!。他のUnixの亜種は類似のメカニズムを使用する傾向がありますが、同一のメカニズムではないため、パスワードデータベースが異種ネットワーク間で共有される場合は注意してください。

Linuxでは、アカウントへのパスワードベースのアクセスを無効にしながら、SSHアクセスを許可できます（他の認証方法、通常はキーペアを使用）。

usermod -p '*' username

ユーザーは、有効なパスワードを入力する必要があるため、アカウントをパスワードを持つように戻すことはできません。

必要に応じて、代わりにアカウントにパスワードがあるかどうかに関係なく、パスワード認証を拒否するようにSSHを構成できます。アカウントがロックされていると見なさないようにSSHを設定する必要があります。たとえば、Linuxでは!パスワードフィールドから削除する必要があります（ただし、フィールドを空にしないでください。*上記のように設定します） ）。SSHのパスワード認証を無効にするには、または（システム上のいずれか）にPasswordAuthenticationディレクティブを追加します。ブロックを使用して、そのディレクティブを特定のユーザーのみに適用します。ブロックが表示される必要があります/etc/sshd_config/etc/ssh/sshd_configMatchMatch

…
Match User username
    PasswordAuthentication no

すでに強力なキーを使用している場合は、パスワードを有効にしたり設定したりする必要はありません。既存のセッションからアカウント（sudo passwd -l username）を再度ロックし、SSH構成を修正するだけです。

これが発生した理由は、おそらく（/ etc / ssh / sshd_configの）デフォルトのSSHデーモン設定の1つを編集したためです。

/ etc / ssh / sshd_configでこれを変更し、SSHを再起動します。

UsePAM yes

一般に、PAMを無効にする本当に正当な理由がない限り、有効にしておくことをお勧めします。SSH内でPAMを有効にすると、パスワードが削除されていてもログインできます。何をするにしても、空のパスワードなどを設定しないでください。パスワードフィールドをロックすることは、アカウント全体をロックアウトすることを意味する必要はありません。

SSHをいじるときの簡単なヒント：SSH構成を変更するたびに（別のウィンドウで）別のセッションを開いたままにして、ログインできることをテストします。誤ってアクセスを中断した場合は、現在のセッションを使用して修正してください。

（免責事項：SSHキー管理ソフトウェアを提供するUserifyで働いています。）

私はCentOS 7でこの問題を抱えていました。私はDebianベースのLinuxユーザーであるため、水から魚でした。一部のサーバーでは機能し、一部のサーバーでは機能しないことに気付きました。audit.logには有用なものは何もなく、secure.logからも何も得られませんでした。唯一の本当の違いは、ファイルとディレクトリのセキュリティコンテキストの違いが、機能するものと機能しないものとの間にあることです。でセキュリティを確保

sudo ls -laZ <user-home>/.ssh

ディレクトリの（私はsshd_configの多くのデフォルトを仮定しています）。

あなたは、いくつか見るべきであるssh_home_tとuser_home_tの属性を。そうでない場合は、chconコマンドを使用して欠落している属性を追加します。

例えば

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

私の場合、ユーザーが非標準的な方法で作成されたのではないかと疑っています。彼の家はのディレクトリでした/var/lib。

詳細：https : //www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

アカウントのロックを解除し、パスワードをランダムな文字列に変更します