[gelöst] Autentification error bei (tailscale) ssh agent weiterleitung

[HousyHarry]

Hallo zusammen

Ich will Borg backup über einen ssh-agent im Pull-mode laufen lassen.
Die Anleitung dazu gibt es hier: Backing up in pull mode - ssh-agent
Kurze zusammenfassung:

1. Ich erstelle auf dem Backup-server einen ssh-key.
2. Trage diesen in .ss/authorized_keys ein
3. danach melde ich über vom Backup-Server via Client auf dem Backup-server ein

hier der vereinfachte Befehl:

Code: Alles auswählen

(   eval $(ssh-agent) > /dev/null;   ssh-add -q ~/.ssh/private-key; ssh  -A -o StrictHostKeyChecking=no clientuser@client "ssh -t -v serveruser@backupserver";   kill "${SSH_AGENT_PID}"; )

Dabei kriege ich allerdings einen Fehler bei der Anmeldung:

Code: Alles auswählen

OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Connecting to serverhostname [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to serverhostname:22 as 'user'
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
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: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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:XXX
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
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 'serverhostname' is known and matches the ED25519 host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_rsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/user/.ssh/id_ed25519 
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/user/.ssh/id_xmss 
debug1: Will attempt key: /home/user/.ssh/id_dsa 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_ed25519_sk
debug1: Trying private key: /home/user/.ssh/id_xmss
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
user@serverhostname: Permission denied (publickey,password).
exit status 255

Gibt es Ideen was hier falsch läuft?
Gruss Harry

[Livingston]

Ich würde mal hiermit anfangen:

Code: Alles auswählen

ssh-add -q ~/.ssh/private-key

vs.

Code: Alles auswählen

debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_ed25519_sk
debug1: Trying private key: /home/user/.ssh/id_xmss
debug1: Trying private key: /home/user/.ssh/id_dsa

private-key ist schon mal ein seltsamer Name, vor allem wenn Du ihn mit ssh-Mitteln erstellt hast.

[HousyHarry]

Hallo Livingston

Danke für deine Antwort.
Ich habe evtl. etwas viel anonymisiert. Der Name des Schlüssels stimmt.

Wahrscheinlich ist das Problem, dass ich Tailscale nutze, um die Geräte zu verbinden.
Die Doc's sind hier.
Allerdings sehe ich nicht wie ich hier den Schlüssel weiterleiten kann.

Gruss Harry

[mat6937]

Allerdings sehe ich nicht wie ich hier den Schlüssel weiterleiten kann.

Warum generierst Du die Schlüssel nicht auf deinem ssh-Client (statt auf deinem sshd-Server)? Den pubkey kannst Du dann per copy&paste, in die Datei des sshd-Servers eintragen.

[MSfree]

Warum generierst Du die Schlüssel nicht auf deinem ssh-Client (statt auf deinem sshd-Server)?

Es spielt überhaupt keine Rolle, ob man das Schlüsselpaar auf dem Server, auf dem Client oder auf einem völlig unabhängigen Rechner erzeugt. Wichtig ist nur, daß der öffentliche Schlüssel auf dem Server in der Datei ~/.ssh/authorized_keys landet. Der private Schlüssel sollte auf dem Client im Verzeichnis ~/.ssh landen. Der Dateiname ist völlig frei wählbar, darf also auch donald.duck heißen. Wichtig ist nur, daß man den Schlüssel beim Aufruf von ssh mitgibt, entweder als Kommandozeilenparamet ( -i <Dateiname> ) oder als Eintrag in der ~/.ssh/config:

Code: Alles auswählen

Host server.tld
  IdentityFile  ~/.ssh/donald.duck

[mat6937]

Es spietl überhaupt keine Rolle, ob man das Schlüsselpaar auf dem Server, auf dem Client oder auf einem völlig unabhängigen Rechner erzeugt.

Das ist richtig und niemand hat das Gegenteil behauptet. Ich habe das _deshalb empfohlen_, weil der TE anscheinend Probleme hat, den privaten Schlüssel dorthin zu bekommen, wo er auch hingehört.

EDIT:

@TE: Wenn Du schon ssh-Verbindung (mit password authentication) vom Client zum Server hast, kannst Du u. a. Möglichkeiten, auch ssh und cat, zum ubertragen/holen einer Datei vom Server zum Client, benutzen. Z. B.:

Code: Alles auswählen

ssh <user@server> "cat </Pfad_auf_dem_Server/zur/fernen_Datei>" | cat > <lokale_Datei_auf_dem_Client>

[MSfree]

Ich habe das _deshalb empfohlen_, weil der TE anscheinend Probleme hat, den privaten Schlüssel dorthin zu bekommen, wo er auch hingehört.

Das Problem ist halt, daß mindestens einer der beiden Schlüssel irgendwie seinen Weg auf den anderen Rechner finden muß.

Generiert man das Schlüsselpaar auf dem Server, muß man den privaten Schlüssel auf den Client bringen.
Generiert man das Schlüsselpaar auf dem Cliebt, muß man den öffentlichen Schlüssel auf den Server bringen.
Generiert man das Schlüsselpaar auf einem unabhängigen Rechner, muß man öffentlichen und privaten Schlüssel transportieren.

Der Transport kann sogar mittels USB-Stick passieren, wenn man Zugang zum Rechner hat und dort einen USB-Stick einstecken kann. Ansonsten sind die Schlüssel nur einfache ASCII-Dateien, die man mittels Copy'n'Paste in einem Loginterminal übertragen kann.

[HousyHarry]

Hallo Zusammen

Warum generierst Du die Schlüssel nicht auf deinem ssh-Client (statt auf deinem sshd-Server)? Den pubkey kannst Du dann per copy&paste, in die Datei des sshd-Servers eintragen.

Das habe ich auch probiert ohne Erfolg

Der private Schlüssel sollte auf dem Client im Verzeichnis ~/.ssh landen.

.

So wie ich die Anleitung verstehe, gebe ich den privaten Schlüssel, welcher ich auf dem Server lade, mit der Option -A dem Client mit, damit ihn dieser wiederum bei der Anmeldung am Server benutzen kann.
Mein Ziel ist es, den Schlüssel eben gerade nicht auf dem Client zu speichern.

Verstehe ich da was falsch?

Gruss Harry

[mat6937]

Mein Ziel ist es, den Schlüssel eben gerade nicht auf dem Client zu speichern.

Verstehe ich da was falsch?

Evtl. ja. Der Client braucht den privaten Schlüssel, damit er sich beim Server anmelden/authentifizieren kann. Der Server braucht nur den pubkey.
Aber viellicht geht es um etwas anderes und ich verstehe dich nicht richtig.

[HousyHarry]

Hallo zusammen

Der Client braucht den privaten Schlüssel, damit er sich beim Server anmelden/authentifizieren kann

Den Schlüssel will ich ja mit ssh -A mitgeben.

Ich war mittlerweile mit dem Initiieren des Borg-Rpos erfolgreich.
Tailscale ssh war auf dem Server nicht aktiviert, nach dem ich dieses aktiviert, habe klappte die Anmeldung auf Client und Server.
Tailscale übernimmt den Schlüsselaustausch, da muss ich ihn nicht mitgeben.

Hier das Skript

Code: Alles auswählen

#!/bin/bash

CLIENT_USER= "client_user"
SERVER_USER= "server_user"
CLIENT= "client"
SERVER= "server"
REPO_PATH= "/path/to/repo"

# Initialize the Borg repository
echo "Initializing Borg repository..."
if echo 'XXX' | \
  ssh ${CLIENT_USER}@${CLIENT} \
  "BORG_PASSPHRASE=\$(cat) ${USER} --rsh 'ssh -v' init --encryption repokey ssh://${SERVER_USER}@${SERVER}${REPO_PATH}"; then
  echo "Borg repository initialized successfully."
else
  echo "Failed to initialize Borg repository." >&2
  kill "${SSH_AGENT_PID}"
  exit 1
fi

# Kill the SSH agent
echo "Killing SSH agent..."
kill "${SSH_AGENT_PID}"