sshd_configファイルを見て、次を見つけました。
#Uselogin no
コメントが走ったのは分かりますが、上記の説明がなくてグーグルをしてみると、次のような結果が出ました。
ユーザーログインに既存のlogin（1）サービスを使用しないでください。権限分離を使用するため、ユーザーがログインすると login(1) サービスが無効になります。
または
対話型ログインセッションに login(1) を使用するかどうかを指定します。デフォルトは「いいえ」です。 login(1) はリモートコマンドの実行には使用されません。また、
X11Forwardinglogin(1) が xauth(1) Cookie を処理する方法がわからないため、この機能が有効になると無効になります。指定すると、UsePrivilegeSeparation認証後に無効になります。
sshが「レガシーログイン」を使用するのを防ぐことは理解されていますが、no「レガシー」ログインに関する情報が見つかりません。
誰かがそれをしていることを説明できますか？
答え1
ここでは少し歴史が必要です。 UNIXシステムにアクセスする主な手段がターミナルとシリアル回線だった頃には、ログインに関連する4つのプログラムがありました。 init、getty、login、shellがそれです。 initはgettyを起動して実行し続けます。 gettyはシリアルポートを開き（モデム関連の操作も実行できます）、ログインプロンプトを表示してユーザー名を待ちます。ユーザー名を入力すると、gettyはそのユーザー名でログインを実行します。次に、ログインにパスワードの入力を求め、アカウント操作を実行し、システムを使用できるシェルを実行します。これは、データセンター、仮想マシン、その他多くの場所で使用されます。
以下はリモートログインです。 Telnet はシリアルポートを使用しないため、状況が若干変わります。 gettyに加えて、initはtelnetd（またはtelnetdを起動するにはinetd）も起動し、telnetdはユーザー名を取得し、ログインを実行し、すべてがそこで動作します。
これで安全シェルが提供されます。セキュリティシェルを使用すると、パスワードなしで（キーを使用するか、GSSのバージョンに応じて）ログインできるため、いくつかの方法でログインできます。良い機能を使わずにTelnetのようにログインすることもできます。sshdはログインを処理し、シェルを起動してあらゆる種類の素晴らしいタスクを実行できます。カスタムバージョンのログインがない場合は、sshdにログインを処理させることをお勧めします。 （Pamがあれば、カスタムログインをする理由はもうありません。）