Geen ssh verbinding met Raspberry Pi

[Campo di Casa]

Mijn vraag
Ik kan geen verbinding meer krijgen met mijn Raspberry Pi via SSH. Ondanks dat het de juiste inloggegevens zijn. Wat kan ik nog controleren of uitproberen?

Relevante software en hardware die ik gebruik
Gebruik mijn Macbook M1 en terminal.

Wat ik al gevonden of geprobeerd heb
Ik heb al meerdere keren de SDcard geflashed met verschillende distro's. Dietpi en Raspian werken niet. Ondanks dat ik bij Dietpi de standaard login gegevens gebruik en dat er bij Dietpi standaard SSH aan staat.
Bij de Raspian distro heb ik geprobeerd om de SSH gegevens via Raspberry Pi Imager automatisch in te stellen. Ook heb ik dit handmatig geprobeerd door via touch het bestand "ssh" in de boot folder te plaatsen.

Al meerdere keren het bestand ssh_known_hosts verwijderd maar ook dit hielp niet.

Kan wel via SSH verbinding maken met mijn andere Raspberry Pi waar Home Assistant op draait. En heb van beide de log vergeleken via ssh -v maar kan niet echt zien wat er anders is.

Heb ook geprobeerd om via een andere device de ssh verbinding te maken. Maar dat lukt ook niet.

onderstaande is de log van ssh -v.

code:

OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.10.101 [192.168.10.101] port 22.
debug1: Connection established.
debug1: identity file /Users/marcel/.ssh/id_rsa type 0
debug1: identity file /Users/marcel/.ssh/id_rsa-cert type -1
debug1: identity file /Users/marcel/.ssh/id_ecdsa type -1
debug1: identity file /Users/marcel/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/marcel/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/marcel/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/marcel/.ssh/id_ed25519 type -1
debug1: identity file /Users/marcel/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/marcel/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/marcel/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/marcel/.ssh/id_xmss type -1
debug1: identity file /Users/marcel/.ssh/id_xmss-cert type -1
debug1: identity file /Users/marcel/.ssh/id_dsa type -1
debug1: identity file /Users/marcel/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Raspbian-5+deb11u1
debug1: compat_banner: match: OpenSSH_8.4p1 Raspbian-5+deb11u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.10.101:22 as 'pi'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [e-mail] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:66uy/EO8iTPkBVm98R3N0puUytxm829gqWHL1yfZ85k
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.10.101' is known and matches the ED25519 host key.
debug1: Found key in /Users/marcel/.ssh/known_hosts:5
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /Users/marcel/.ssh/id_rsa RSA SHA256:tgcoOd9xX2KQCi0Tif9pkFSvXaaKDDtSBfUJbsA7cGI
debug1: Will attempt key: /Users/marcel/.ssh/id_ecdsa
debug1: Will attempt key: /Users/marcel/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/marcel/.ssh/id_ed25519
debug1: Will attempt key: /Users/marcel/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/marcel/.ssh/id_xmss
debug1: Will attempt key: /Users/marcel/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[e-mail],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[e-mail],[e-mail]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/marcel/.ssh/id_rsa RSA SHA256:tgcoOd9xX2KQCi0Tif9pkFSvXaaKDDtSBfUJbsA7cGI
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/marcel/.ssh/id_ecdsa
debug1: Trying private key: /Users/marcel/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/marcel/.ssh/id_ed25519
debug1: Trying private key: /Users/marcel/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/marcel/.ssh/id_xmss
debug1: Trying private key: /Users/marcel/.ssh/id_dsa
debug1: Next authentication method: password
pi@192.168.10.101's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
pi@192.168.10.101's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
pi@192.168.10.101's password:
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
pi@192.168.10.101: Permission denied (publickey,password).
marcel@MacBook-Air-van-Marcel ~ % nssh.com,[e-mail]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/marcel/.ssh/id_rsa RSA SHA256:tgcoOd9xX2KQCi0Tif9pkFSvXaaKDDtSBfUJbsA7cGI
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/marcel/.ssh/id_ecdsa
debug1: Trying private key: /Users/marcel/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/marcel/.ssh/id_ed25519
debug1: Trying private key: /Users/marcel/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/marcel/.ssh/id_xmss
debug1: Trying private key: /Users/marcel/.ssh/id_dsa
debug1: Next authentication method: password
pi@192.168.10.101's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
pi@192.168.10.101's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
pi@192.168.10.101's password:
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
pi@192.168.10.101: Permission denied (publickey,password).

Resultaat van nmap om te kijken of port open is

code:

marcel@MacBook-Air-van-Marcel ~ % nmap 192.168.10.101
Starting Nmap 7.93 ( https://nmap.org ) at 2022-12-08 07:13 CET
Nmap scan report for 192.168.10.101
Host is up (0.0045s latency).
Not shown: 999 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 4.25 seconds

[ElCondor]

Als je de SD opnieuw geflasht hebt, maw het OS opnieuw hebt geïnstalleerd, dan zijn je oude passwords niet meer geldig, lijkt me. Wat gebruik je precies om in te loggen?
Hebje een key bestand lokaal staan en log je daar mee in? Dan staat het password op jouw lokale machine en wordt de keyfile aangeboden aan de Pi. Met de herinstallatie van het OS op de Pi is het vertrouwen van jouw key file verloren gegaan.
Dus zul je dat ook opnieuw moeten configureren.
Als je geen key file gebruikt, en je hebt het OS op de Pi opnieuw geïnstalleerd, dan is het password terug naar standaard, volgens mij. Dan zou het account 'Pi' en ww 'raspberry' moeten zijn. Tenzij je na het flashen van het OS dit anders hebt ingesteld.
Als ik het log goed lees, dan wordt een public key geprobeerd en die faalt en vervolgens wordt een password geprobeerd, maar die faalt ook. Dus er is wel degelijk iets mis met de id en password combinatie.

[NimRod1337]

Commando waarmee je inlogt ontbreekt. Probeer het eens vanaf je andere pi.

[Voor 33% gewijzigd door NimRod1337 op 08-12-2022 09:30]

[Destiny]

Het lijkt erop dat je password niet geaccepteerd wordt.

Ik heb ooit een vergelijkbaar probleem gehad.De default keyboard layout van de Raspian is GB. Op een GB keyboard zijn de lettertekens boven de cijfers anders ingedeeld dan US of NL Mac keyboards. Als je dus bijvoorbeeld een @ of $ in je password hebt zitten dan komt dat verkeerd door.

[Shivs]

Het probleem lijkt in het password te zitten. Pubkey plaatsen en kijken of het werkt kan dat uitsluiten.

[Campo di Casa]

ElCondor schreef op donderdag 8 december 2022 @ 09:23:
Als je de SD opnieuw geflasht hebt, maw het OS opnieuw hebt geïnstalleerd, dan zijn je oude passwords niet meer geldig, lijkt me. Wat gebruik je precies om in te loggen?
Hebje een key bestand lokaal staan en log je daar mee in? Dan staat het password op jouw lokale machine en wordt de keyfile aangeboden aan de Pi. Met de herinstallatie van het OS op de Pi is het vertrouwen van jouw key file verloren gegaan.
Dus zul je dat ook opnieuw moeten configureren.
Als je geen key file gebruikt, en je hebt het OS op de Pi opnieuw geïnstalleerd, dan is het password terug naar standaard, volgens mij. Dan zou het account 'Pi' en ww 'raspberry' moeten zijn. Tenzij je na het flashen van het OS dit anders hebt ingesteld.
Als ik het log goed lees, dan wordt een public key geprobeerd en die faalt en vervolgens wordt een password geprobeerd, maar die faalt ook. Dus er is wel degelijk iets mis met de id en password combinatie.

Je hebt gelijk met de standaard login gegevens voor Raspbian. 'pi' met 'raspberry'. Dat zijn dan ook de gegevens die ik heb geprobeerd. Ben ook bezig geweest om een paar keer een verse OS te installeren en via Raspberry Pi Imager andere login gegevens mee te geven om uit te sluiten dat ik probeer in te loggen met de verkeerde gegevens. Dit werkte ook niet.
Ook hetzelfde gedaan met de DietPi OS. Standaard login gegevens gebruikt die bij Dietpi hoort, maar geen resultaat.

Ik log in met login+ww. dus "ssh root@192.168.10.101" als voorbeeld.

@Destiny Dat heb ik kunnen uitsluiten door het wachtwoord te copy-pasten vanuit Bitwarden. Meerdere pogingen gedaan. Heb ook het wachtwoord overgetypt maar werkte ook niet.

Shivs schreef op donderdag 8 december 2022 @ 10:16:
Het probleem lijkt in het password te zitten. Pubkey plaatsen en kijken of het werkt kan dat uitsluiten.

Zal eens kijken of ik daar wat verder mee kom.

[Kalentum]

Pi en raspberry is niet meer geldig. Bij het flashen van de sd card kun je nu een wachtwoord instellen en ssh instellen

https://tutorials-raspber...i-default-login-password/

[Campo di Casa]

Kalentum schreef op donderdag 8 december 2022 @ 18:56:
Pi en raspberry is niet meer geldig. Bij het flashen van de sd card kun je nu een wachtwoord instellen en ssh instellen

https://tutorials-raspber...i-default-login-password/

Dat verklaard dan waarom de pogingen met pi en raspberry niet lukte. Maar heb ook meerdere keren Raspbian opnieuw op de SDcard gezet en de via de Raspberry Pi Imager andere login gegevens opgegeven en ssh geactiveerd. Maar dat werkte ook niet.

[Hero of Time]

En als je er nou eens een scherm en toetsenbord aan hangt, krijg je dan iets zinvols te zien?

[Campo di Casa]

Hero of Time schreef op donderdag 8 december 2022 @ 19:31:
En als je er nou eens een scherm en toetsenbord aan hangt, krijg je dan iets zinvols te zien?

Dat ga ik nu maar doen. Kom er gewoon echt niet uit zo.

[edit]
Ik kan gewoon met de aangemaakte login en ww inloggen op de Raspberry Pi. Maar dezelfde gegevens worden niet geaccepteerd via ssh.

[edit2]
Wist niet dat het kon, zie ook niet in waarom je ooit zoiets zou doen, maar heb gekeken of je naar jezelf kan ssh-en met "ssh root@127.0.0.1" en dat werkt wanneer ik dit doe op mijn Raspberry Pi waar HA op draait. Heb dus eerst via ssh verbinding gemaakt, en vanuit daar nog eens ssh naar jezelf (127.0.0.1).

Waar nu de oude Pi even op zolder draait met monitor en toetsenbord heb ik geen utp en Wifi zit niet op de oude Pi 1. Als ik dan nu naar mezelf ssh (ssh root@127.0.0.1) kom ik er gewoon niet in. Terwijl precies hetzelfde wel werkt op de andere Raspberry Pi met HA.

Ik snap er helemaal niks meer van. Voorheen heeft de Raspberry altijd headless gedraait met Dietpi en gewerkt als simpele netwerkopslag met een externe schijf en Adguard.

[Voor 67% gewijzigd door Campo di Casa op 08-12-2022 20:04]

[ElCondor]

Campo di Casa schreef op donderdag 8 december 2022 @ 19:33:
[...]
[edit]
Ik kan gewoon met de aangemaakte login en ww inloggen op de Raspberry Pi. Maar dezelfde gegevens worden niet geaccepteerd via ssh.

Dit is voor nu even de beste manier om voorwaards te gaan. Je moet lokaal inloggen op de Pi, en dan de SSH server logs er eens bij pakken en kijken wat er gebeurt als je via SSH probeert in te loggen

[edit2]
Wist niet dat het kon, zie ook niet in waarom je ooit zoiets zou doen, maar heb gekeken of je naar jezelf kan ssh-en met "ssh root@127.0.0.1" en dat werkt wanneer ik dit doe op mijn Raspberry Pi waar HA op draait. Heb dus eerst via ssh verbinding gemaakt, en vanuit daar nog eens ssh naar jezelf (127.0.0.1).

Dit is dus vooral interessant als je lokaal op de Pi ingelogd bent en wilt testen of er netwerk connectie te maken is, maar dan buiten de firewall om. Je maakt hierbij namelijk gebruik van de loopback interface.
Ik zou dit dus eens proberen als je met display en keyboard lokaal op de Pi bent ingelogd. Als dat niet lukt, dan zou je in de SSH server logs moete kunnen zien wat er precies binnenkomt.

Het is inderdaad wel een gedoe om een hele display erbij te pakken om dit zoort shit te troubleshooten. Ik ben daarom nog steeds op zoek naar een portable displaytje van 12" met HDMI. Maar ja..

[Voor 7% gewijzigd door ElCondor op 09-12-2022 08:35]

[ahbart]

Kan het zijn dat je de RPi moet verwijderen uit de ~/.ssh/known_host file op je mac?

[Hero of Time]

Als je met root probeert in te loggen is het geen wonder dat het mislukt. Bij een beetje Linux distro is de root gebruiker uitgeschakeld (geen wachtwoord), of als je die wel opgeeft tijdens installatie, is er in de ssh configuratie nog eens expliciet opgegeven dat je absoluut niet mag inloggen met root. Om overduidelijke redenen. Op Windows kan je immers ook niet meer inloggen met Administrator.

In de TS gaat het fout als je wilt inloggen met de gebruiker Pi, maar daar gebruik je dus overduidelijk een verkeerd wachtwoord.

[Campo di Casa]

Hero of Time schreef op vrijdag 9 december 2022 @ 18:45:
Als je met root probeert in te loggen is het geen wonder dat het mislukt. Bij een beetje Linux distro is de root gebruiker uitgeschakeld (geen wachtwoord), of als je die wel opgeeft tijdens installatie, is er in de ssh configuratie nog eens expliciet opgegeven dat je absoluut niet mag inloggen met root. Om overduidelijke redenen. Op Windows kan je immers ook niet meer inloggen met Administrator.

In de TS gaat het fout als je wilt inloggen met de gebruiker Pi, maar daar gebruik je dus overduidelijk een verkeerd wachtwoord.

oke, dat wist ik niet. Ik kan ook gewoon met root inloggen op mijn HA en heb daar nooit bij stil gestaan.
Zal morgen dit eens veranderen door opnieuw de SDcard te flashen met andere gegevens.

[xah5kiDe]

Kijk eens in de nieuwste log file in /var/log/ De sshd deamon wil de reden van geen toegang daar nog wel eens achterlaten.

[Campo di Casa]

Hero of Time schreef op vrijdag 9 december 2022 @ 18:45:
Als je met root probeert in te loggen is het geen wonder dat het mislukt. Bij een beetje Linux distro is de root gebruiker uitgeschakeld (geen wachtwoord), of als je die wel opgeeft tijdens installatie, is er in de ssh configuratie nog eens expliciet opgegeven dat je absoluut niet mag inloggen met root. Om overduidelijke redenen. Op Windows kan je immers ook niet meer inloggen met Administrator.

In de TS gaat het fout als je wilt inloggen met de gebruiker Pi, maar daar gebruik je dus overduidelijk een verkeerd wachtwoord.

Net maar weer opnieuw een SDcard voorzien van een verse Raspbian met andere inloggegevens. Dus geen pi of root. En nu werkt het idd .

Maar wat ik dus raar vind is dat, wanneer ik Dietpi op de SDcard zet en de gegevens root/dietpi gebruik zoals vermeld op de site van Dietpi als standaard, dit niet werkt. Natuurlijk pas je de pw meteen aan zodra je via ssh op Dietpi zit en laat je dit niet standaard. Em omdat ik als root wel via ssh op mijn Home Assistant kan inloggen is het niet in mij opgekomen dat het misschien geblokkeerd word doordat ik probeer in te loggen als root.

Blij dat dit is opgelost. Kan ik mijn externe HDD weer in het netwerk hangen

[Deshmir]

@Campo di Casa Wat je voortaan ook kan doen (als je niks geeft om security lokaal) is het volgende:

code:

nano /etc/ssh/sshd_config
PermitRootLogin op Yes
service sshd restart

Dan kan je met root blijven inloggen; wel handig om je root user dan toch nog een password te geven.

[Voor 21% gewijzigd door Deshmir op 10-12-2022 07:26]

[deHakkelaar]

Deshmir schreef op zaterdag 10 december 2022 @ 07:26:
@Campo di Casa Wat je voortaan ook kan doen (als je niks geeft om security lokaal) is het volgende:

code:

nano /etc/ssh/sshd_config
PermitRootLogin op Yes
service sshd restart

Dan kan je met root blijven inloggen; wel handig om je root user dan toch nog een password te geven.

Aangeraden wordt om met een key in te loggen.
Dit is OOTB zonder aanpassingen wel toegestaan voor de root user:

$ man sshd_config
[..]
     PermitRootLogin
             Specifies whether root can log in using ssh(1).  The argu‐
             ment must be yes, prohibit-password, forced-commands-only,
             or no.  The default is prohibit-password.

             If this option is set to prohibit-password (or its depre‐
             cated alias, without-password), password and keyboard-inter‐
             active authentication are disabled for root.

             If this option is set to forced-commands-only, root login
             with public key authentication will be allowed, but only if
             the command option has been specified (which may be useful
             for taking remote backups even if root login is normally not
             allowed).  All other authentication methods are disabled for
             root.

             If this option is set to no, root is not allowed to log in.

$ sudo grep PermitRootLogin -R /etc/ssh*
/etc/ssh/sshd_config:#PermitRootLogin prohibit-password
/etc/ssh/sshd_config:# the setting of "PermitRootLogin without-password".

Met sleutels inloggen is zoiezo makkelijker.
Ééntje aanmaken met ssh-keygen.
En de publieke sleutel naar het andere systeem toe schieten met:

$ man ssh-copy-id
[..]
NAME
     ssh-copy-id — use locally available keys to authorise logins on a
     remote machine
[..]
SYNOPSIS
     ssh-copy-id [-f] [-n] [-i [identity_file]] [-p port] [-o ssh_option]
                 [user@]hostname
     ssh-copy-id -h | -?
[..]
DESCRIPTION
     ssh-copy-id is a script that uses ssh(1) to log into a remote ma‐
     chine (presumably using a login password, so password authentication
     should be enabled, unless you've done some clever use of multiple
     identities).  It assembles a list of one or more fingerprints (as
     described below) and tries to log in with each key, to see if any of
     them are already installed (of course, if you are not using
     ssh-agent(1) this may result in you being repeatedly prompted for
     pass-phrases).  It then assembles a list of those that failed to log
     in, and using ssh, enables logins with those keys on the remote
     server.  By default it adds the keys by appending them to the remote
     user's ~/.ssh/authorized_keys (creating the file, and directory, if
     necessary).  It is also capable of detecting if the remote system is
     a NetScreen, and using its ‘set ssh pka-dsa key ...’ command in‐
     stead.

Boven werkt natuurlijk niet als je niet met root kunt inloggen met een ww via SSH!
Dan zul je met het handje de sleutel in het /root/.ssh/authorized_keys2 --> /root/.ssh/authorized_keys bestandje moeten proppen.

[Voor 0% gewijzigd door deHakkelaar op 11-12-2022 00:13. Reden: verkeerde bestandje]

[Hero of Time]

deHakkelaar schreef op zaterdag 10 december 2022 @ 19:56:
[...]
Boven werkt natuurlijk niet als je niet met root kunt inloggen met een ww via SSH!
Dan zul je met het handje de sleutel in het /root/.ssh/authorized_keys2 bestandje moeten proppen.

In je synopsis staat al waar ssh-copy-id het in opslaat. In sshd_config staat tevens het volgende:

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

Oftewel, het is sterk af te raden om je public key in authorized_keys2 te plaatsen. Heb het in al m'n jaren dat ik met Linux werk nog nooit gehoord om het juist daar in te zetten, ipv 'gewoon' in authorized_keys.

Het is sowieso onverstandig om gelijk in te loggen als root. Beter leer je om sudo te gebruiken. In het verleden was je op Windows ook altijd, non-stop administrator, met alle nare gevolgen van dien. Tegenwoordig krijg je een UAC prompt voor je neus als je verhoogde rechten moet bevestigen voor een actie. Waarom zou je dan met Linux teruggaan naar het punt dat je je hele systeem kan slopen met een typo?

Nou zijn fouten niet onvermijdelijk als je als gewoonte al alles via sudo uitvoert, dan schiet je het doel voorbij. Maar genoeg software klaagt gelukkig als je iets met root rechten uitvoert terwijl het dat helemaal niet nodig heeft.

[deHakkelaar]

Hero of Time schreef op zaterdag 10 december 2022 @ 23:19:
In je synopsis staat al waar ssh-copy-id het in opslaat. In sshd_config staat tevens het volgende:

[...]

Oftewel, het is sterk af te raden om je public key in authorized_keys2 te plaatsen. Heb het in al m'n jaren dat ik met Linux werk nog nooit gehoord om het juist daar in te zetten, ipv 'gewoon' in authorized_keys.

Bedankt!
Ik dacht altijd dat authorized_keys2 gewoon de opvolger was.
Dit wordt redelijk duidelijk uitgelegd hieronder:
https://rus.io/authorized_keys-vs-authorized_keys2/

EDIT:

Why sudo?

Using sudo could be more familiar to newer users, and it could be better (safer) than allowing a normal user to open a session as root. Some reasons:

Nobody needs to know the root password (sudo prompts for the current user's password). Extra privileges can be granted to individual users temporarily, and then taken away without the need for a password change.

It's easy to run only the commands that require special privileges via sudo; the rest of the time, you work as an unprivileged user, which reduces the damage that mistakes can cause.

Auditing/logging: when a sudo command is executed, the original username and the command are logged.

For the reasons above, switching to root using sudo -i (or sudo su) is usually deprecated because it cancels most of the above features.

https://wiki.debian.org/sudo

[Voor 41% gewijzigd door deHakkelaar op 10-12-2022 23:59]