Hast du den Key als anderer user / root erzeugt oder dem einen anderen Namen gegeben? Das ist der, der nach deinem ssh-keygen funktionieren müsste:
Codeno such identity: /home/bud/.ssh/id_ed25519: No such file or directoryGibt's den?
Also user bud lokal auf meinem Linux - ist das relevant? Es wurde ein sudo-User xyz auf dem Server angelegt, für welchen ich den Schlüssel hinterlegt habe.
Versuch's damit:
Host bud.example.com 192.0.2.211
HostName 192.0.2.211
User bud
PubKeyAuthentication yes
IdentityFile ~/.ssh/key/private.txtDer Pfad* muss stimmen, aber am Log siehst du, dass er deinen Key gar nicht versucht hat. Das liegt daran, dass der Eintrag in der Config nur zum Tragen kommt, wenn der Host stimmt.
(Was da hinter Host steht sind keine IP-Adressen oder Domains, sondern Namen. Da kann auch meinvserver stehen, und dann kannst du dich mit ssh meinvserver einloggen, ohne bud@)
*) Der Pfad wird relativ zum aktuellen Verzeichnis interpretiert, nicht relativ zum Verzeichnis der config-Datei. Wenn du beim ssh Aufruf in deinem Homeverzeichnis bist, ist .ssh/meinkey die gleiche Datei wie ~/.ssh/meinkey oder /home/bud/.ssh/meinkey, aber sonst nicht.
/home/bud/.ssh/key/private.txt
Lass mal das Unterverzeichnis "key" weg und lege die Datei direkt ins .ssh Verzeichnis. Warum weiß ich zwar leider nicht, aber der ssh-agent mag es leider nicht so, wenn die Keys nicht an der gewohnten Stelle liegen.
Da bin ich vor ein paar Jahren auch mal reingelaufen, als ich Ordnung schaffen wollte.
ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id.ed25519.ncsrv01~/.ssh/config
Host ncsrv01
Hostname 192.0.2.211
Port 22
User root
IdentityFile ~/.ssh/id.ed25519.ncsrv01
IdentitiesOnly yes
PreferredAuthentications publickeyDann kannst du mit dem folgenden Befehl auf den Server zugreifen.
ssh ncsrv01Und wie von GTAzoccer bereits erwähnt.
Alle aktiven Keys sollten direkt in ~/.ssh/ liegen.
Spielerei, für wenn das Reportageteam den Bildschirm filmt:
Host 8.8.8.8
HostName 192.0.2.211
User terence
IdentityFile ~/.ssh/key/private.txtUnd dann ssh bud@8.8.8.8
Aber Achtung: cli vor config -> bud@ und nicht terence@ wird ge»user«t
Aber Achtung
Es war nicht nur eine Spielerei sondern sollte auch genau das zeigen. Man schießt sich mit den "IP-Adressen als Namen" übrigens auch schnell selbst in den Fuß, weil man irgendwann vergisst, dass man die eingetragen hat, und sich dann wundert, warum ein einfaches ssh user@adresse nicht das macht, was man denkt.
wass ssh-key betrifft würde ich es wie folgt konfigurieren:
.ssh/config
### SSH - Verbindungen
#Host *
ForwardAgent yes
### Include
Include config.d/*Dann
mkdir .ssh/config.d/In Folge innerhalb Diener angelegten .ssh/config.d/ für jeden Deiner vielen Orgas/Vereine die jeweilige config anlegen:
config-verein-01
config-verein-02
config-verein-03
etc.Alle config mit innerhalb ssh/config.d/ mit chmod 700 versehen.
und in jeder der jeweiligen config Deine:
Für Server im RZ
Host foobar01
HostName rDNS Host
#HostName Host vom Provider
#HostName IP vom Provider
User foobar01
Port 22 # oder anderer PortFür lokale Rechner im Intranet
Host foo01
HostName jeweilige IP
User foo01
Port 22 # oder anderer PortIch habe es bei mir (wie hier beschrieben so in der Anwendung.
So habe ich keine einzelne ellenlange config, sondern alles schön für mich getrennt.
Forwardagent sollte man generell (*) nur aktivieren, wenn man weiß, was man tut.
Siehe manpage und typische mitm-angriffe.
Außerdem willst du chmod 600, nicht chmod 700.
Forwardagent sollte man generell (*) nur aktivieren, wenn man weiß, was man tut.
Siehe manpage und typische mitm-angriffe.
Da gebe ich Dir Recht - wenn man weiß was man tut
Außerdem willst du chmod 600, nicht chmod 700.
Danke, war ein Fehler von mir beim verfassen. Ich selbst habe an für die config Files chmod 700
Ich selbst habe an für die config Files chmod 700
du meinst 700 für config.d und 600 für die configs, oder? ODER??? 
Die Borg führen ihre Konfigurationsdateien aus.
Wenn man so viele Hosts hat, dass man die .ssh/config aufteilen muss, sollte man die Hosts strukturiert benennen, und zwar andersherum als Domainnamen, z.B. verein1-foo, verein1-bar, verein2-ernie, verein2-bert, privat-bud01. Dann kann man sich auf komfortablen Systemen die relevanten Namen durch eine kurze Eingabe und Autocompletion mit Tab-Tab schnell auflisten lassen.
Die Borg führen ihre Konfigurationsdateien aus.
kennt man ja: erst exekutieren, dann (nach dem passwort) fragen… (jaaa, der ist ganslahm)
ja, meins wär's auch nicht, mit den aufgeteilten configs. ich hab's gern zentralistisch übersichtlich.
und vor allem ein user, ein key.
.ssh/config
Code### Include Include config.d/*
Danke für den Tipp.
Ein cat .ssh/config | grep Host\ | wc -l sagt 42.
Jetzt wird es übersichtlicher 
Die Borg haben es gerne untergliedert & strukturiert. 
Und was ssh ForwardAgent betrifft, muss die Borgqueen schnell von Cube zu Cube wechseln können. 
Ich google mir seit Tagen die Finger wund, dann überwinde ich mich dazu diese simple Frage hier zu stellen, und letztendlich ist es wirklich nur das Unterverzeichnis gewesen... What?!
Es funktioniert, aber mein innerer Monk ist damit nicht zufrieden 
Vielen Dank für die ganzen Antworten!
Ich google mir seit Tagen die Finger wund, dann überwinde ich mich dazu diese simple Frage hier zu stellen, und letztendlich ist es wirklich nur das Unterverzeichnis gewesen... What?!
Für den Fall das es Dich tröstet. Mir ging es vor ein paar Jahren zwecks einiger ssh-key Zugriffe optimal verwalten ähnlich wie Dir.
Es funktioniert, aber mein innerer Monk ist damit nicht zufrieden
Streng Dich noch etwas an, dann nominiere ich Dich für den Monk Award 2025. 
letztendlich ist es wirklich nur das Unterverzeichnis gewesen...
strenggenommen war es doch nur der falsch angegebene pfad in deiner config (siehe #942, zeile 5).
