アカウントがロックされているため、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]
答え1
何をしても、アカウントをpasswd -u
パスワードフィールドが空のままにしないでください。これにより、パスワードを入力せずにログインできます(これを拒否するSSHを除く)。
アカウントをパスワードなしでロック解除するように変更します。パスワードデータベースのパスワードハッシュが文字列のハッシュではない場合、そのアカウントにパスワードはありません。伝統的に*
これは、または同じ単一文字列を使用して実行されます。!
ロックされたアカウントはパスワードフィールドに特別なトークンを使用するため、文字列はどの文字列のハッシュにもなりません。このフラグはシステムによって異なります。 Linuxでは、このpasswd
コマンドは先頭に追加してロックされたパスワードを表示します!
。 OpenSSHは、フィールドがで始まるとアカウントをロックされたものとして扱います!
。他のUnixバリアントは同様ですが、同じではないメカニズムを使用する傾向があるため、パスワードデータベースが異機種間ネットワークで共有される場合は注意してください。
Linuxでは、SSHアクセスを許可しながらパスワードベースのアカウントアクセスを無効にできます(他の認証方法、通常はキーペアを使用)。
usermod -p '*' username
ユーザーは有効なパスワードを入力する必要があるため、アカウントをパスワードに戻すことはできません。
必要に応じて、アカウントにパスワードがあるかどうかにかかわらず、パスワード認証を拒否するようにSSHを設定できます。アカウントがロックされていると見なさないようにSSHを準備する必要があります。たとえば、Linuxでは!
パスワードフィールドを削除する必要があります(ただし、フィールドを空にしないで*
上記のように設定します)。 SSHのパスワード認証を無効にするには、または(システムの場所に関係なく)ディレクティブをPasswordAuthentication
追加します。特定のユーザーにのみディレクティブを提供するには、ブロックを使用してください。ブロックが必要です。/etc/sshd_config
/etc/ssh/sshd_config
Match
Match
…
Match User username
PasswordAuthentication no
答え2
@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
答え3
パスワードを有効または設定する必要はなく、すでに強力なキーを使用している場合は、パスワードを設定しないでください。既存のセッション(sudo passwd -lユーザー名)でアカウントを再ロックしてSSH設定を変更します。
これは、デフォルトのSSHデーモン設定の1つ(/etc/ssh/sshd_config)を編集したために発生する可能性があります。
/etc/ssh/sshd_configでこの設定を変更してSSHを再起動します。
UsePAM yes
SSHでPAMを有効にすると、パスワードを削除してもログインできます。何をしても、空白のパスワードなどを設定しないでください。パスワードフィールドをロックしても必ずしもアカウント全体がロックされるわけではありません。
SSHデーモンを設定するときのクイックヒント:SSH設定を変更するたびに別のセッションを別のウィンドウで開いたままにしてアクセスが誤って破損した場合は、以前のセッションを使用して問題を解決してください。
(免責事項:私はUserifyで働いています。)
答え4
CentOS 7でこの問題が発生しました。私は一般的なDebianベースのLinuxユーザーなので、水から出た魚のようです。一部のサーバーでは機能しますが、1つのサーバーでは機能しないことがわかりました。 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
。