Hintergrund
Ich habe einen Server mit SSH-Zugriff über Ras-Schlüssel eingerichtet. Der Kennwortzugriff ist nicht zulässig.
Es hat gut funktioniert. Mein Benutzer (ich nenne ihn USER1) und Root konnten sich mit ihren jeweiligen Schlüsseln anmelden.
ÄNDERUNGEN, DIE MÖGLICHERWEISE PROBLEME VERURSACHTEN
Gestern habe ich ein paar Änderungen am Server vorgenommen, gemäß den AnweisungenIn diesem Artikel, um einem neuen Benutzer (USER2) eingeschränkten Zugriff auf einen Ordner (das Web-Stammverzeichnis) zu gewähren. Ich habe auch die Anweisungen inDieser Artikel.
Um diese Änderungen zusammenzufassen: Ich habe einen neuen Benutzer (USER2) erstellt und eine Änderung bindfsdes Web-Roots ( /home/user1/sites/domain/public/) auf /home/user2/domain/public/) vorgenommen. Gemäß diesen Artikeln wurden noch ein paar andere Dinge getan, aber soweit ich das beurteilen kann, hat keines davon Auswirkungen auf die Berechtigungen und den SSH-Zugriff von USER1. Ich werde also nicht versuchen, sie hier alle zu wiederholen.
Gemäß 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, ist das das Einzige, was sich geändert hat, seit ich mich das letzte Mal mit USER1 anmelden konnte.
AUSGABE
Nachdem ich die oben genannten Änderungen vorgenommen hatte, konnte ich mich am nächsten Tag (heute) nicht anmelden. Ich erhalte die Fehlermeldung Permission denied (publickey)..
Ich habe alle Standardempfehlungen befolgt, um die richtigen Berechtigungen und Eigentümer für den ~/home/USER1/.sshOrdner und ~/home/USER1/.ssh/authorized_keysdie Datei festzulegen. Allerdings wurde durch meine gestrigen Aktionen nichts davon geändert, sodass ich im Grunde nur die vorhandenen Berechtigungen erneut angewendet habe.
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 zuvor auskommentiert. Ich habe es auskommentiert, während ich versucht habe, dieses Problem zu beheben.
Ich weiß nicht, was meinen USER1 daran hindert, schlüsselbasierten SSH-Zugriff zu erhalten. Wenn es weitere hilfreiche Informationen gibt, lassen Sie es mich bitte wissen.
UPDATE: Konnte das Problem beheben, bin mir aber nicht sicher, warum es aufgetreten ist
Nachdem ich noch einmal überprüft hatte, dass alle Berechtigungen korrekt waren und die Datei keine Auffälligkeiten enthielt sshd-config, richtete ich SSH so ein, dass die Anmeldung mit Passwort möglich war, und kopierte dann meine Datei id_rsa.pub (mithilfe von ssh-copy-id) erneut auf den Server.
Dadurch wurde mein Zugriff für USER1 mit einem Schlüssel wiederhergestellt.
Ich verstehe nicht ganz, warum dieses Problem aufgetreten ist, und ich plane, die Anweisungen in diesen Artikeln auf weiteren Servern zu verwenden (da sie sich als sehr nützliche Möglichkeit erwiesen haben, einem Entwickler beispielsweise strikten SFTP-Zugriff (nur) auf die Website zu gewähren und ihm die Berechtigung zum Vornehmen von Dateiänderungen zu erteilen). Wenn also jemand Zeit hat, auf den Fehler in den Anweisungen hinzuweisen, tun Sie dies bitte.
Damit Sie diese Artikel nicht lesen müssen, finden Sie hier eine Aufschlüsselung 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
Neuen Benutzer 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: Welche Folgen hätte user1der SSH-Zugriff mit dem entsprechenden Schlüssel in den obigen Schritten gehabt?