SSH-Berechtigung für öffentlichen Schlüssel nicht möglich

SSH-Berechtigung für öffentlichen Schlüssel nicht möglich

Ich werde versuchen, dies so gut und detailliert wie möglich zusammenzufassen. Ich habe gestern Abend meine erste Django-Site auf einem Ubuntu-Server (23.04) auf Linode bereitgestellt, nachdem ich dies befolgt hatte Corey Schafer Python DjangoLernprogramm. Alles lief gut und ich richtete SSH ein, wie im Tutorial im Video beschrieben, nach etwa 23-25 ​​Minuten ohne Probleme. Ich überprüfte, ob alles funktionierte. Ich verließ den Server und überprüfte, ob ich mich ohne Probleme über SSH wieder anmelden konnte. Anschließend verbrachte ich noch ein oder zwei Stunden damit, eine Reihe anderer Dinge zu konfigurieren und sicherzustellen, dass die Site aktiv war, bevor ich ins Bett ging und den Server verließ. Heute gehe ich zurück, um mich mit dem Server zu verbinden, und erhalte eine MeldungPermission denied (publickey).

Da ich nach all dem wusste, dass ich eine Firewall installiert hatte, dachte ich, großartig, ich habe mich wahrscheinlich selbst aus SSH-Verbindungen ausgesperrt oder so etwas. Nach einigem Googeln stieß ich jedoch auf diesen Modifikator ssh -vT user@IPund sah schnell, dass er tatsächlich versucht, eine Verbindung über SSH herzustellen, und eine Verbindung hergestellt wird, aber aus Gründen, die ich nicht ganz verstehe, einfach fehlschlägt.

Als Nächstes habe ich versucht, mich als Root-Benutzer über Linodes Weblish anzumelden. Ich konnte mich erfolgreich anmelden und habe versucht, ein paar Dinge zu überprüfen.

• Zuerst habe ich überprüft, ob am Speicherort ein Ordner vorhanden ist /home/user/.ssh, der eine Datei mit dem Schlüssel enthält.

• Zweitens habe ich die Berechtigungen überprüft, indem ich mir die Videoanleitung für den Ordner ~/.ssh/ und den Inhalt noch einmal angesehen und die folgenden beiden Befehle erneut ausgeführt habe. sudo chmod 700 ~/.ssh/undsudo chmod 600 ~/.ssh/*

Das Ergebnis ist das Folgende für den SSH-Ordner in meinem Home-Verzeichnis.

lewpiper@django-server:~$ la -la
total 40
drwxrwxrwx 6 lewpiper lewpiper 4096 Jun 14 06:37 .
drwxr-xr-x 3 root     root     4096 Jun 14 05:22 ..
-rw------- 1 lewpiper lewpiper  100 Jun 14 05:34 .bash_history
-rw-r--r-- 1 lewpiper lewpiper  220 Jun 14 05:22 .bash_logout
-rw-r--r-- 1 lewpiper lewpiper 3771 Jun 14 05:22 .bashrc
drwx------ 4 lewpiper lewpiper 4096 Jun 14 06:09 .cache
drwxrwxr-x 3 lewpiper lewpiper 4096 Jun 14 06:37 .local
drwxr-xr-x 8 lewpiper www-data 4096 Jun 14 06:36 Portfolio
-rw-r--r-- 1 lewpiper lewpiper  807 Jun 14 05:22 .profile
drwx------ 2 lewpiper lewpiper 4096 Jun 15 06:03 .ssh
-rw-r--r-- 1 lewpiper lewpiper    0 Jun 14 05:33 .sudo_as_admin_successful

Im Folgenden sind die Berechtigungen für die Datei im SSH-Ordner im Home-Verzeichnis aufgeführt.

lewpiper@django-server:~/.ssh$ ls -la
total 12
drwx------ 2 lewpiper lewpiper 4096 Jun 15 06:03 .
drwxrwxrwx 6 lewpiper lewpiper 4096 Jun 14 06:37 ..
-rw------- 1 lewpiper lewpiper  749 Jun 14 05:32 authorized_keys

• Drittens habe ich eine Firewall auf dem Server eingerichtet und die aktuell zulässigen Verbindungstypen sind wie folgt.

lewpiper@django-server:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)  

• Schließlich ging ich zur /etc/ssh/sshd_configDatei und aktivierte PasswordAuthentication vorerst wieder, bis ich dem SSH-Problem auf den Grund gehen konnte. Ich kann mich also vorerst anmelden, ohne das von Linode angebotene Weblish verwenden zu müssen. Nachdem ich dies getan hatte, versuchte ich jedoch, den SSH-Dienst auf dem Server mit dem folgenden Befehl neu zu starten, sudo systemctl restart sshdwie es im Tutorial beim Bearbeiten dieser Datei beschrieben wird. Stattdessen erhielt ich eine Fehlermeldung. Failed to restart sshd.service: Unit sshd.service not found.Ich erinnere mich, dass ich diese Meldung gestern Abend auch erhalten hatte, als ich das Setup für den Server durchführte und eine schnelle Google-Suche ergab, dass sich der Name des Dienstes geändert hatte, also versuchte ich es sudo systemctl restart sshund das schien gestern Abend zu funktionieren, aber ich frage mich, ob ich mich dabei geirrt hatte.

Unten ist die Datei sshd_config, wie ich sie jetzt habe. Beachten Sie jedoch, dass ich die Kennwortauthentifizierung auf „Ja“ geändert habe, sodass ich mich anmelden konnte, ohne den generierten RSA-Schlüssel verwenden zu müssen, was mein Problem ist.

LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

Fragen: Meine Frage hier ist also zweiteilig. Erstens: Habe ich etwas übersehen, was ich tun könnte, um die Ursache für das Problem besser zu ermitteln, oder könnte ich es versuchen? Zweitens: Wenn es keine andere empfohlene Fehlerbehebung gibt, sollte ich einfach versuchen, meine Datei authorized_keys auf dem Server zu löschen und sie sicher auf den Server zu kopieren? Beachten Sie, dass ich nicht einmal sicher bin, ob das funktionieren würde, da ich nicht davon überzeugt bin, dass das überhaupt das Problem ist. Ich vermute, dass ich vielleicht etwas übersehen habe oder dass mehr hinter der Failed to restart sshd.service: Unit sshd.service not found.Meldung steckt, die ich zuvor erwähnt habe. Ist auch ein Neustart des Servers in Erwägung gezogen worden? Klingt seltsam, aber vielleicht wird etwas wie die Firewall oder so neu geladen und dann ist alles in Ordnung.

verwandte Informationen