Brauche Hilfe unter Debian 9

  • Hallo Breadfish Community,


    ich besitze einen Rootserver und habe Dinge wie MySQL, PHP, apache2, usw. mit Erfolg installiert und konfiguriert und bin nun soweit um meinen Rootserver abzusichern.
    Den ersten Schritt den ich vorhabe ist eine Public Key Authentifizierung zu erstellen, nur leider komme ich dort nicht zum Erfolg was mir aber unter Debian 8 in ca. 10Minuten gelang.


    Wenn ich in SSH sssh-keygen -t ed25519 -o -a 100 eingebe und später in /home/brandt/.ssh mit:


    touch .ssh/authorized_keys
    chmod 700 .ssh
    chmod 600 .ssh/authorized_keys
    chown -R brandt:ssh-manager .ssh
    nano .ssh/authorized_keys (schlüssel einfügen zb. ssh-ed25519 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ ed25519-key-20171026)



    und die sshd_config bearbeite mit:



    Das ist die Debian 9 sshd_config die ich bearbeitet habe!!!!



    # $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $



    # This is the sshd server system-wide configuration file. See
    # sshd_config(5) for more information.



    # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin



    # The strategy used for options in the default sshd_config shipped with
    # OpenSSH is to specify options with their default value where
    # possible, but leave them commented. Uncommented options override the
    # default value.



    Port 28
    Protocol 2
    #AddressFamily any
    #ListenAddress 0.0.0.0
    #ListenAddress ::



    #HostKey /etc/ssh/ssh_host_rsa_key
    #HostKey /etc/ssh/ssh_host_ecdsa_key
    HostKey /etc/ssh/ssh_host_ed25519_key



    # Ciphers and keying
    #RekeyLimit default none



    # Logging
    #SyslogFacility AUTH
    #LogLevel INFO



    # Authentication:


    LoginGraceTime 1m
    #PermitRootLogin prohibit-password
    PermitRootLogin no
    StrictModes yes
    MaxAuthTries 6
    MaxSessions 10
    AllowUsers brandt
    AllowGroups ssh
    DenyUsers root
    DenyGroups root


    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 no
    PermitEmptyPasswords no



    # Change to yes to enable challenge-response passwords (beware issues with
    # some PAM modules and threads)
    ChallengeResponseAuthentication 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 ChallengeResponseAuthentication and
    # PasswordAuthentication. Depending on your PAM configuration,
    # PAM authentication via ChallengeResponseAuthentication 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 ChallengeResponseAuthentication to 'no'.
    UsePAM no



    #AllowAgentForwarding yes
    #AllowTcpForwarding yes
    #GatewayPorts no
    X11Forwarding no
    X11DisplayOffset 10
    #X11UseLocalhost yes
    #PermitTTY yes
    PrintMotd no
    PrintLastLog yes
    TCPKeepAlive yes
    #UseLogin no
    #UsePrivilegeSeparation sandbox
    #PermitUserEnvironment no
    #Compression delayed
    #ClientAliveInterval 0
    #ClientAliveCountMax 3
    #UseDNS no
    #PidFile /var/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



    einfüge und mich dann als brandt anmelden will werde ich nach der Key-passphrase gefragt und die eingebe sagt es mir das die nicht stimmt, und ich weiß nicht wieso, ich hoffe Hier kann mir geholfen werden.


    Mit freundlichen Grüßen


    Kmdt.Brandt

  • Im Normalfall sollte das eigentlich alleine dadurch, dass beim Generieren die Passphrase abgefragt wird insofern richtig eingegeben gar nicht möglich sein, dass
    diese beim private Key falsch hinterlegt wird. Daher vermute ich mal stark, dass du dich einfach vertippt hast. Da hilft dann nichts außer neu generieren.


    Sollte das danach immer noch nicht funktionieren versuchs einfach mit puttygen. Damit kannnst du auch nen public und nen private key generieren (auch mit Passphrase).
    Den im oberen Bereich dargestellten Schlüssel musst du dann nur noch in die authorized_keys kopieren und es sollte soweit alles funktionieren.
    Der Vorteil an der Methode ist, dass dir der private key auch gleich als ppk Datei abgespeichert wird, welche mit dem putty agent oder putty direkt verwendet werden kann.


    Wenn dein Server nicht alleine über SSH erreichbar ist, kannst du auch einfach mal den Dienst stoppen und mit /usr/sbin/sshd -d den Prozess im Debug Modus starten.
    Das hilft dir allerdings nur, wenn es doch nicht an der Passphrase sondern an der Key-Authentifizierung liegen sollte.

    Mit freundlichen Grüßen


    Headscracher | Tobi :thumbup:

  • Ich habe jetzt mit puttygen einen SSH-1 (RSA) schlüssel generiert dann ein langes PW in Key passphrase geschrieben und dann den public, private key und den langen key in einen Ordner auf meinem Desktop gelegt.
    Danach habe ich mich mit putty verbunden und habe als root folgende befehle ausgeführt:


    cd /home/brandt
    mkdir .ssh
    touch .ssh/authorized_keys
    chmod 700 .ssh
    chmod 600 .ssh/authorized_keys
    chown -R brandt:ssh-manager .ssh


    Danach habe ich die sshd_config mit nano geöffnet und habe folgendes gemacht:
    PasswordAuthentication no
    PermitRootlogin no
    DenyUsers/Groups AllowUsers/Groups (Deny... root Allow... brandt/ssh-manager)


    Ob das richtig ist weiß ich nicht:
    AuthorizedKeysFile %h/.ssh/authorized_keys



    Sieht standartmäßig so aus:


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

  • Von der Config her sieht das Ganze auf jedenfall schonmal gut aus.
    Außer vielleicht das PasswordAuthentication no. Da wäre ich mir dann nicht ganz so sicher,
    wie du wieder auf den Server kommen willst, wenn die Key Authentifikation nicht funktioniert.
    Das mit den authorized_keys passt auf jeden Fall und die Config ist auch im Regelfall standardmäßig
    so eingestellt, dass die Public-Key Authentfizierung ohne weitere Konfigurationen funktioniert.


    Warum du hier auch noch der Gruppe ssh-manager als Besitzer zuweist ist mir zwar nicht ganz klar,
    da deine Berechtigung eh nur für den Eigentümer gelten, aber auch das sollte kein Prolbem sein.


    Wichtig ist halt auf jeden Fall, dass du in die authorized_keys den in PuttyGen oben generierten Schlüssel kopierst und nicht
    den Public Key nimmst, da sich der Aufbau der authorized_keys Datei auch nochmal leicht von dem von PuttyGen generierten public key unterscheidet.

    Mit freundlichen Grüßen


    Headscracher | Tobi :thumbup:

  • Ich habe die PasswordAuthentication jetzt auf yes gesetzt das funktioniert zwar auch aber die Authorized_keys benutzt ssh iwie immer noch nicht. Also dass ich mich in SSH als brandt anmelde und dann die passphrase eingeben muss. Oder ist das eig. dann genau dasselbe wie ein standart PW?

  • So funktioniert das mit der Key Authentifizierung auch nicht. Die Passphrase muss nicht bei der Anmeldung selbst angegeben werden, sondern um den private Key zu verwenden.
    Am einfachsten geht das, wenn du den pagent verwendest. Von ablauf her solltest du dann überhaupt kein Kennwort mehr eingeben müssen, insofern der private Key im pagent geladen
    ist. Wie das genau abläuft, wenn du den private key über putty direkt lädst kann ich dir leider nicht sagen.
    Sollte das nichts bewirken müssen wir erstmal gucken, ob das Authentfifizierungsverfahren überhaupt verwendet wird. Dafür musst du in der sshd_config das Log Level auf Debug3 setzen
    und dir die /var/log/auth.log angucken. Dadrin wird dann zu erkennen sein, ab welchem Schritt die Authentifizierung fehlschlägt/abbricht.

    Mit freundlichen Grüßen


    Headscracher | Tobi :thumbup:

    Einmal editiert, zuletzt von Headscracher ()

  • Wie stelle ich das mit dem pagent "Verfahren" genau an? Und was ist das genau, das habe ich noch nie gehört um ehrlich zu sein.


    MfG

  • pAgent ist einfach ein Zusatz für Putty (kann auch von der selben Seite herunter geladen werden und ist im Setup schon mit dabei).
    Du hast damit einfach den Vorteil, dass du mit PuTTYgen gespeicherte private Keys(ppks) durch einen Doppelklick oder das hinzufügen im Agent selbst
    nach Eingabe der Passphrase diese Keys in eine Art Zwischenablage laden kannst. Auf diese wird dann einfach bei dem nächsten Login mit putty an deinem Server
    zurückgegriffen und das manuelle Laden des Keys oder das erneute eingeben einer Passphrase wird überflüssig. Die in die Zwischenablage geladenen Keys kannst du natürlich auch
    manuell wieder entfernen und nach einem Neustart des Rechners sind diese auch nicht vorhanden.


    Das deine Probleme dadurch behoben werden ist jetzt auch nur reine Vermutung, da du eben schon zu Anfang meintest, dass dir zurückgegeben wird, dass
    die Passphrase falsch ist und ich mir dadurch gut vorstellen kann, dass einfach dein Vorgehen beim Anmelden nicht 100% richtig ist.

    Mit freundlichen Grüßen


    Headscracher | Tobi :thumbup: