ubuntuusers.de

matze31 schrieb:

Auch

sftp://user@ip:port -i ~/.ssh/server

verweigert der server den Zugriff.

BTW: Es gibt einen Workaround mit dem bzw. über den ssh-agent: Den Schlüssel im ssh-agent laden und freischalten, dann reicht thunar die Anfrage weiter, ohne selber den pass-key verstehen zu müssen.

Um einer praktikablen Lösung näher zu kommen, schlage ich dir die Verwendung von sshfs in der /etc/fstab vor.

Diesem zwar bereits 13 Jahre alten Thread nach kommt sshfs sowohl mit der Verwendung eines ~/.ssh/config Files wie auch der Angabe eines Pfades zu einer abweichenden privaten Schlüsseldatei zurecht. Da du bereits eine ~/.ssh/config verwendest solltest es damit also funktionieren ohen weitere große Anpassungen

Mein Vorschlag daher:

• Nutzung von FUSE/sshfs (Abschnitt „Beim-Systemstart“) mit den <options> user,noauto oder auch users,noauto

Die Option user bewirkt dass das Einbinden nicht mit den Rechten von Root erfolgt sondern dem jeweiligen User (so wie eben über Thunar auch) und die Option noauto verhimdert ein Mounten bereits beim Systemstart (vorteilhaft wenn die Ressourche nicht immer verfügbar ist, etwa bei einem Notebook außerhalb des LAN's). Eingebunden wird die Ressourche erst wenn ein User diese tatsächlich nutzen will.

Ich habe jetzt den Server komplett neu aufgesetzt und alles neu generiert. Auch habe ich den "private key" dann wieder umbenannt. Dann die ~/.ssh/config so gelassen (weil die Daten gleich sind) und ich kann jetzt mittels sftp://server mich einloggen. Warum das vorher nicht ging weiß ich nicht. Evtl fehlten irgendwelche Berechtigungen.

Ich bedanke mich für die vielen Antworten.

Grüße

Wie ist als normaler User, die Ausgabe von:

1

ssh-add -l

?

lubux schrieb:

Wie ist als normaler User, die Ausgabe von:

Auf dem Client

$ ssh-add -l
The agent has no identities.

Ok,… dann hat es andere Gründe, dass es funktioniert.

Das heißt?

Evtl. ist das Package „ gvfs-backends“ auch installiert worden, das einen geeigneten Treiber dann zur Verfügung stellt.

OK, wer weiß.