Behebung des SSH-Zugriffs mit rsa-Schlüssel

320
inspirednz

Hintergrund

Ich habe einen Server mit SSH-Zugriff über Ras-Schlüssel eingerichtet. Passwort Zugang ist nicht erlaubt.

Es hat gut funktioniert. Mein Benutzer (ich nenne diesen USER1) und root könnten sich mit ihren jeweiligen Schlüsseln anmelden.

ÄNDERUNGEN, DIE DIE MÖGLICHKEIT AUSGEWIESEN HABEN

Gestern habe ich einige Änderungen am Server vorgenommen, indem ich den Anweisungen in diesem Artikel folgte, um einem neuen Benutzer (USER2) eingeschränkten Zugriff auf einen Ordner (das Web-Root) zu gewähren. Ich habe auch die Anweisungen in diesem Artikel befolgt .

Um diese Änderungen zusammenzufassen, habe ich einen neuen Benutzer (USER2) und hat eine bindfsder Web - Root ( /home/user1/sites/domain/public/) auf /home/user2/domain/public/). Gemäß diesen Artikeln wurden einige andere Dinge erledigt, aber soweit ich nicht feststellen kann, hat dies keinen Einfluss auf die Berechtigungen und den SSH-Zugriff von USER1. Also werde ich nicht versuchen, sie alle hier zu wiederholen.

In einem dieser Artikel habe ich der sshd_configDatei außerdem Folgendes hinzugefügt :

subsystem sftp internal-sftp Match User USER2 ChrootDirectory %h AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp 

Soweit ich das beurteilen kann, hat sich daran nichts geändert, seit ich mich zuletzt mit USER1 einloggen konnte.

PROBLEM

Nachdem ich die oben genannten Änderungen vorgenommen hatte, konnte ich mich am nächsten Tag (heute) nicht anmelden. Ich bekomme den Fehler Permission denied (publickey)..

Ich habe alle Standardempfehlungen befolgt, um die richtigen Berechtigungen und den Besitz für den ~/home/USER1/.sshOrdner und die ~/home/USER1/.ssh/authorized_keysDatei festzulegen. Obwohl gestern nichts von meinen Handlungen geändert wurde, habe ich im Grunde nur die vorhandenen Berechtigungen erneut angewendet.

Der Inhalt meiner /etc/ssh/sshd_configDatei ist:

Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 1024 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes  AuthorizedKeysFile %h/.ssh/authorized_keys IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no PasswordAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* UsePAM yes Subsystem sftp /usr/lib/openssh/sftp-server  Match User USER2 PasswordAuthentication yes ChrootDirectory %h AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp 

AuthorizedKeysFile %h/.ssh/authorized_keyswurde durchweg auskommentiert. Ich habe es unkommentiert, als ich versuchte, dieses Problem zu beheben.

Ich weiß nicht, was meinen USER1 am schlüsselbasierten SSH-Zugriff hindert. Wenn weitere Informationen hilfreich sind, lass es mich wissen.

UPDATE: Es wurde geschafft, das Problem zu beheben, aber nicht sicher, warum es aufgetreten ist

Nachdem ich überprüft hatte, dass alle Berechtigungen korrekt waren und sich in der sshd-configDatei nichts Ungewöhnliches befand, stellte ich ssh so ein, dass das Passwort-Login zugelassen wurde, und kopierte meine id_rsa.pub-Datei (mit ssh-copy-id) erneut auf den Server.

Dies hat meinen Zugriff für USER1 mit einem Schlüssel wiederhergestellt.

Ich kann nicht ganz genau verstehen, warum dieses Problem aufgetreten ist, und ich plane, die Anweisungen in diesen Artikeln auf zusätzlichen Servern zu verwenden (da dies sich als sehr nützliche Methode erwies, um einem Entwickler (beispielsweise) strengen SFTP-Zugriff (nur) auf den Server zu gewähren Wenn Sie die Zeit haben, den Fehler in der Anleitung anzugeben, tun Sie dies bitte.

Um Sie vor dem Lesen dieser Artikel zu bewahren, finden Sie hier eine Übersicht der Schritte, die ich unternommen habe:

mkdir -p /home/user2/websites/application1 chown -Rf user2:user2 /home/user2/websites chmod -Rf 770 /home/user2/websites 

Folgendes hinzufügen zu /etc/fstab

bindfs#/home/user1/websites/domain/public /home/user2/websites/application1 fuse force-user=user2,force-group=user2,create-for-user=user1,create-for-group=user1,create-with-perms=0770,chgrp-ignore,chown-ignore,chmod-ignore 0 0  chown user1:user1 /home/user1/websites/domain/public chmod 770 /home/user1/websites/domain/public 

Der neue Benutzer wurde erstellt:

sudo useradd -d /home/user2/website/application1 user2 sudo passwd user2 

Zu sshd-config hinzugefügt

subsystem sftp internal-sftp Match User user2 ChrootDirectory %h AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp 

Dann, sudo service ssh restart

FRAGE

Meine modifizierte Frage lautet also: Was hätte user1der SSH-Zugriff mit seinem Schlüssel in den obigen Schritten bewirkt ?

1
sshd selbst liefert sehr nützliche Informationen, wenn Sie LogLevel DEBUG3 verwenden. grawity vor 6 Jahren 0
Danke, ich habe mich gefragt, wie ich aus SSHD-Protokollierung mehr nützliche Informationen erhalten kann. Sagte mir fast nichts. inspirednz vor 6 Jahren 0

0 Antworten auf die Frage