web-dev-qa-db-ja.com

パスワード認証ではなく、公開鍵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]
sshpassword
36
kravemir

アカウントのロックを解除し、@ 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
16
garethTheRed

何をするにしても、アカウントを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_config（システムにある方）に追加します。 Matchブロックを使用して、そのディレクティブを特定のユーザーにのみ適用します。 Matchブロックが必要です

…
Match User username
    PasswordAuthentication no
46
Gilles 'SO- stop being evil'

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

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

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

UsePAM yes

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

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

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

11
Jamieson Becker

私は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/

0
hanzo2001