Brauche Hilfe unter Debian 9

Kmdt.Brandt · 26. Oktober 2017

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

Headscracher · 26. Oktober 2017

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.

Kmdt.Brandt · 26. Oktober 2017

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

Headscracher · 26. Oktober 2017

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.

Kmdt.Brandt · 26. Oktober 2017

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?

Headscracher · 27. Oktober 2017

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.

Kmdt.Brandt · 27. Oktober 2017

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

Headscracher · 27. Oktober 2017

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.

Kmdt.Brandt · 30. Oktober 2017

Es funktioniert alles jetzt so wie ich es wollte,, vielen vielen Dank @Headscracher

Mit freundlichen Grüßen

Kmdt.Brandt

Brauche Hilfe unter Debian 9

seegras 27. Oktober 2021

breadfish.de 12. März 2022