☰

Sicherheit: Git-Server mit SSH-Authentifizierung

tag-icon • tag-icon linux ssh security unix
Sicherheit: Git-Server mit SSH-Authentifizierung
  1. Ich habe den Benutzer „git-server“ erstellt.
  2. Eingerichtetopenssh-server
  3. Geändert /etc/ssh/sshd_confighinzugefügtPasswordAuthentication no
  4. .ssh/authorized_keysZum öffentlichen Fall meiner Kollegen hinzugefügt

Fragen:

  • Ist der Benutzer „git-server“ für mein System sicher? Was ist das schlimmste Szenario für das System, wenn ein Angreifer Zugriff auf „git-server“ erhält, vorausgesetzt, dass „git-server“sudoer
  • Wie kann ich dem „Git-Server“ alle Operationen außer gitBefehlen verbieten?

Antwort1

Sie sollten die Standard-Shell des Benutzers „Git-Server“ in „Git-Shell“ ändern.

https://git-scm.com/docs/git-shell.html

Dies ist eine Login-Shell für SSH-Konten, die eingeschränkten Git-Zugriff bietet. Sie erlaubt nur die Ausführung von serverseitigen Git-Befehlen, die die Pull/Push-Funktionalität implementieren, sowie benutzerdefinierte Befehle, die in einem Unterverzeichnis namens git-shell-commands im Stammverzeichnis des Benutzers vorhanden sind.

Antwort2

Sehen wir uns an, wie Sie dieses Git-Server-Konto auf dem System einrichten.

Geändert /etc/ssh/sshd_config hinzugefügt PasswordAuthentication nein

Da Sie die Kennwortauthentifizierung auf „Nein“ eingestellt haben, ist es ohne einen gültigen SSH-Schlüssel praktisch unmöglich, sich unter diesem Namen remote beim System anzumelden. Soweit ich weiß, glaube ich nicht, dass SSH-Schlüssel geknackt wurden, allerdings hängt es von der von Ihnen verwendeten Verschlüsselung und der Verschlüsselungskomplexität ab, um dies festzustellen.

Damit ist diese Tatsache geklärt. Wenn es jemandem gelingt, auf dieses Konto zuzugreifen, bedeutet dies höchstwahrscheinlich, dass es jemand getan hat, der bereits Zugriff auf Ihr System hat und über die Berechtigung verfügt, su zu verwenden. Oder wenn Sie Ihr System ordnungsgemäß gesperrt haben, hat sich jemand irgendwie Zugriff auf Root verschafft, was noch unmöglicher ist, als auf das Git-Server-Konto zuzugreifen. Wenn dies jedoch nicht der Fall ist und sich die Person per Remote-Zugriff über SSH bei diesem Konto angemeldet hat, ist jeder, der SSH verwendet, in Schwierigkeiten, da das bedeutet, dass jedes System, das SSH verwendet, anfällig wäre. Der größte Schaden, der jetzt angerichtet werden kann, ist der gleiche, den Sie mit Ihrem normalen Konto mit Sudo-Berechtigungen anrichten können.

Antwort3

Einige Variablen müssen festgelegt werden, falls Vorschläge befolgt werden müssen …

_git_user='git-user'
_git_group='git-devs'
_git_home_base="/srv/${_git_group}"
_client_certs_root='/home/admin/client-certs'

... die aus der Perspektive Ihres Serveradministratorkontos geschrieben werden.

  1. Ich habe den Benutzer „git-server“ erstellt.

Hast du es zufällig gesperrt und zu einem Systemkonto gemacht?

sudo adduser\
 --system\
 --disabled-password\
 --gecos ''\
 --shell "$(which git-shell)"\
 --home "${_git_home_base,,}/${_git_user,,}"\
 --ingroup "${_git_group}"\
 "${_git_user}"

Beachten Sie: Wenn $(which git-shell)die Auflösung zu einem Dateipfad erfolgt, --shelldie Option jedoch Fehler ausgibt, …

if [ -e "$(which git-shell)" ] && ! grep -q -- "$(which git-shell)" /etc/shells; then
    sudo tee -a /etc/shells 1>/dev/null <<<"$(which git-shell)"
fi

git-shell... kann hilfreich sein, den Pfad an die /etc/shellsDatei anzuhängen

  1. Eingerichtetopenssh-server
  2. Geändert /etc/ssh/sshd_confighinzugefügtPasswordAuthentication no

Haben Sie deaktiviertrootPasswortauthentifizierung über SSH?

/etc/ssh/sshd_configTeile, die hilfreich sein könnten …

permitrootlogin without-password


## Additionally consider locking-down other unneeded features
Match Group git-devs
  AllowTcpForwarding no
  AllowStreamLocalForwarding no
  PermitOpen none
  1. .ssh/authorized_keysZum öffentlichen Fall meiner Kollegen hinzugefügt

Wo genau haben Sie ihre öffentlichen Schlüssel hinzugefügt?

Hier sind einige Beispielbefehle zum Einrichten von drei Git-Konten …

declare -a _accounts_keys=(
    ["name-one"]="${_client_certs_root}/${_git_group}/name-one/ssh.pub"
    ["name-two"]="${_client_certs_root}/${_git_group}/name-two/ssh.pub"
    ["name-three"]="${_client_certs_root}/${_git_group}/name-three/ssh.pub"
)



for _name in "${!_accounts_keys[@]}"; do
    sudo su --login "${_name}" --shell /bin/bash <<EOF
mkdir .ssh
tee -a .ssh/authorized_keys 1>/dev/null <<<"$(<"${_accounts_keys[${_name}]}")"
chmod 600 .ssh/authorized_keys
EOF
done

Ist der Benutzer „git-server“ für mein System sicher? Was ist das schlimmste Szenario für das System, wenn ein Angreifer Zugriff auf „git-server“ erhält, vorausgesetzt, dass „git-server“sudoer

Nein, und wenn Sie alle Schlüssel zum selben Konto hinzugefügt haben und dieses Konto ein ist sudoer, dann ist die Menge anAlptraum TreibstoffIch könnte diese Situation mit nahezu grenzenlosen Mitteln löschen ...

Wie kann ich dem „Git-Server“ alle Operationen außer Git-Befehlen verbieten?

Fügen Sie git-shell-commands/no-interactive-loginjedem Git-Konto ein Skript hinzu …

for _name in "${!_accounts_keys[@]}"; do
    sudo su --login "${_name}" --shell /bin/bash <<EOC
tee 'git-shell-commands/no-interactive-login' 1>/dev/null <<'EOF'
#!/usr/bin/env bash
printf 'Hi %s, you have successfully authenticated!\n' "${USER}"
printf 'However, there is not an interactive shell here.\n'
exit 128
EOF

chmod u+x 'git-shell-commands/no-interactive-login'
EOC
done

... solange sich keine anderen ausführbaren Dateien im git-shell-commandVerzeichnis befinden, ist das Konto auf nicht-interaktive Git-Befehle beschränkt; vorausgesetzt, dass die Shell des Kontos auch richtig eingerichtet ist.

Das Obige ist nicht das Sicherste, aber mit Komfort im Gleichgewicht;

  • git-devsDie Gruppe sollte für jedes Konto unterschiedlich sein, wenn kein Cross-Cloning erwünscht ist. Dies könnte beispielsweise name-onemöglich sein (wenn die primäre Gruppe zwischen Konten geteilt wird), git clone name-two@server:/srv/git-devs/name-two/project-namewenn man wüsste, wie die Dinge serverseitig strukturiert sind.

Beachten Sie, wenn Berechtigungen vorhanden sind, bei denen 600dies pro Projekt innerhalb eines einzelnen Kontos deaktiviert werden könnte, und wenn Berechtigungen vorhanden sind, bei denen dies der freigegebenen Gruppe sowie einem Repository 660ermöglicht würde ... persönlich finde ich das am bestenpushpull640am bestenvon beiden Optionen, da dies einer Gruppe ermöglicht, Code untereinander auszutauschen, ohne allzu große Angst haben zu müssen, dass ein Abweichler git push -fvon einem anderen Konto alles durcheinanderbringt.

  • Beispiele für andere git-shell-commandsSkripte finden Sie untergit-utilities/git-shell-commandsRepository, aus dem die obigen Tipps übernommen wurden, obwohl dasTippnoch mehr in Richtung Bequemlichkeit.

ZusamenfassendnichtFügen Sie die oben verlinkten Skripte hinzu, wenn Sie den Clients nicht vertrauen können, dass sie nicht versuchen,Pop-Ah-Muscheldenn solche Dinge sind so konzipiert, dass diebrauchenfür eine interaktive Shell ist nicht so weit verbreitet.

Bonuspunkte

  • Hier finden Sie man --pager='less -p "ChrootDirectory"' sshd_configHinweise, wie Sie den SSH-Server noch sicherer machen können.

  • Überprüfen Sie man git-shellund man git-daemondie zugehörige Dokumentation. Es gibt einige nützliche Optionen, um Dinge zu sperren und/oder die Kommunikation mit dem Server etwas einfacher zu machen, z. B. --strict-paths, --base-path=<path>, und --listen=<host_or_ipaddr>es könnte sich lohnen, sich näher damit zu befassen.

Wenn an den oben genannten Punkten etwas fragwürdig ist, hinterlassen Sie bitte einen Kommentar, damit die Antwort verbessert werden kann.

verwandte Informationen