sshfs mit fstab: Verbindung durch Peer zurückgesetzt

10

Ich versuche, meinem Laptop (Ubuntu 13.04) den Zugriff auf meine PC-Festplatte (Lubuntu 13.04) über SSHFS zu ermöglichen. Ich verwende RSA-Schlüssel, um eine Verbindung herzustellen.

Es funktioniert einwandfrei, wenn ich dies in das Terminal eingebe:

sshfs my-PC:/a_folder /media/a_folder

Aber ich möchte, dass es automatisch gemountet wird, wenn ich meinen Laptop boote. Also habe ich mich der Sicherungsgruppe hinzugefügt:

sudo adduser mynickname fuse

Und ich habe meiner fstab-Datei die folgende Zeile hinzugefügt:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse defaults,idmap=user,_netdev 0 0

Wenn ich den Laptop starte, wird a_folder in der Liste der Geräte angezeigt, ist jedoch nicht gemountet. Wenn ich versuche, über Nautilus darauf zuzugreifen, wird der folgende Fehler angezeigt:

mount: only root can mount sshfs#mynickname@my-PC:/a_folder on /media/a_folder

Ich erhalte den gleichen Fehler, wenn ich es versuche

mount /media/a_folder

in einem Terminal.

Wenn ich es versuche

sudo mount /media/a_folder

Ich bekomme

read: Connection reset by peer

Ich habe versucht, "allow_other" als Option in den fstab-Eintrag einzufügen und die zugehörige Zeile in /etc/fuse.conf auskommentiert, aber nichts daran geändert.

Der Benutzer "mynickname" ist der Eigentümer des Ordners / media / a_folder und verfügt über rwx-Berechtigungen.

Ich habe mir im Internet viele Themen über Menschen mit ähnlichen Problemen angesehen, aber bisher hat nichts funktioniert. Normalerweise können die Leute das nicht einmal

sshfs my-PC:/a_folder /media/a_folder

ohne einen Fehler zu bekommen, während dies auf meinem Laptop gut funktioniert.

Alle Einblicke und Tipps werden sehr geschätzt! Vielen Dank.

EDIT: Ich habe dieses Problem vor einiger Zeit gelöst, aber ich habe vergessen, diesen Beitrag zu aktualisieren. Also hier ist was in meiner fstab ist:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse noauto,_netdev,idmap=user,user,default_permissions 0 0

Die Schlüsseloption zum Hinzufügen war default_permissions, wenn ich mich erinnere. Ich musste mynickname zu der Gruppe hinzufügen, zu der / a_folder / auf meinem PC gehört.

fstab sshfs

8

Das Problem besteht darin, dass Ihr normaler Benutzer ein korrektes Setup für Ihre Identitätsdatei hat, während der Root-Benutzer keine Ahnung hat, welchen SSH-Schlüssel er verwenden soll.

Sie können dies beheben, indem Sie fstab mitteilen, welche Identitätsdatei / welcher SSH-Schlüssel beim Verbindungsversuch verwendet werden soll:

sshfs#user@host:/mnt/whatever/ /mnt/whatever/        fuse    user,_netdev,reconnect,uid=1000,gid=1000,IdentityFile=/home/USER/.ssh/KEYFILE,idmap=user,allow_other  0   2

— ErdmeLon
quelle

Danke für deine Antwort. Ich habe es bereits mit der Option IdentityFile versucht, aber ich habe die Optionen uid und gid nicht angegeben, also werde ich das versuchen!

Technisch gesehen sollten Sie nicht verwenden müssen, sudowenn alles für eine FUSE-Halterung richtig eingerichtet ist. Außerdem sollten die UID / GID-Einstellungen nur beeinflussen, welcher Benutzer Rechte an den Dateien auf Ihrem System hat.

— EarthmeLon

Also habe ich es gerade mit uid, gid, IdentityFile, allow_other und all diesen Optionen gleichzeitig versucht, und leider funktioniert es immer noch nicht. Immer noch der gleiche Fehler.

Würde es Ihnen etwas ausmachen, ein Beispiel dafür zu veröffentlichen, wie Sie es geschrieben haben? Sie sollten auf Ihren privaten Schlüssel und nicht auf Ihren öffentlichen Schlüssel zeigen.

— EarthmeLon

1

Beide Methoden haben also nicht funktioniert. Immer noch der gleiche Fehler. Für die Konfigurationsdatei habe ich versucht, den richtigen Host anzugeben: Benutzer, Hostname (sowohl IP als auch Name ausprobiert), Identitätsdatei. Aber es hat nicht so gut funktioniert. Am Ende mache ich also den Befehl sshfs my-PC: / a_folder / media / a_folder in den Startanwendungen. Es ist nicht so sauber wie die Verwendung von fstab, aber es funktioniert vorerst gut genug. Vielen Dank für Ihre Hilfe und Ihre Vorschläge! Wenn Sie an etwas anderes denken, können Sie es gerne teilen, ich werde es zu schätzen wissen!

3

Um eine echte Debug-Ausgabe zu erhalten, müssen Sie dem Mount sowohl sshfs_debugals auch debugOptionen hinzufügen :

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse defaults,idmap=user,_netdev,debug,sshfs_debug 0 0

Damit erhalten Sie viele Debug-Informationen, die Ihnen helfen:

$ sudo mount -a
SSHFS version 2.5
FUSE library version: 2.9.2
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <user@box> <-s> <sftp>
user@box's password: 
Server version: 3
Extension: posix-rename@openssh.com <1>
Extension: statvfs@openssh.com <2>
Extension: fstatvfs@openssh.com <2>
Extension: hardlink@openssh.com <1>
Extension: fsync@openssh.com <1>
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.22
flags=0x0000f7fb
max_readahead=0x00020000
remote_uid = 1001
   INIT: 7.19
   flags=0x00000011
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40
unique: 2, opcode: STATFS (17), nodeid: 1, insize: 40, pid: 2771
unique: 3, opcode: LOOKUP (1), nodeid: 1, insize: 47, pid: 3371

In meinem Fall stellte ich fest, dass mein Computer nur in aufgeführt war .ssh/config, sodass er für root nicht auflösbar war.

Übrigens müssen Sie uid und gid einstellen, da dies idmap=usernur für den aktuellen Benutzer zu funktionieren scheint, was in diesem Fall root ist.

— Alexander Torstling
quelle

3

Dieses Problem kann auch auftreten, wenn sich der Hostschlüssel von ssh ändert.

Versuchen Sie, über ssh (z ssh username@hostIP. B. ) eine Verbindung zum Server herzustellen . Wenn der folgende Fehler auftritt:

 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Befolgen Sie die Anweisungen in der Fehlermeldung, um den alten Schlüssel zu löschen, und versuchen Sie erneut, eine Verbindung über ssh herzustellen. Wenn der Fehler nicht mehr auftritt, sollte die sshfs-Verbindung funktionieren.

— Gorka
quelle

"Versuchen Sie, über ssh eine Verbindung zum Server herzustellen" Stellen Sie sicher, dass Sie dies als root tun, wenn Sie das Verzeichnis als root mounten (was beim automatischen Bereitstellen der Fall ist). Die known_hostsDatei eines Benutzers kann sich von der Root- known_hostsDatei unterscheiden.

— Shelvacu

0

Vollständige Offenlegung: Old-School-Geek, aber brandneu in der Linux / Open Source-Welt

Zunächst einmal verwende ich immer noch die Kennwortauthentifizierung, da ich mit RSA-Schlüsseln noch nicht vertraut genug bin. Das steht jedoch fast ganz oben auf der Liste.

Relevante Einrichtungsinformationen: Verwenden eines MacBook Pro mit installierter VMWare Fusion, auf dem Ubuntu Server 10.04 LTS installiert ist. Ich verlasse mich bei fast meiner gesamten Serverinteraktion auf Macs Terminal und SSH

Nachdem ich eine Drupal-Installation verpfuscht hatte, kehrte ich zu einem vorherigen Snapshot zurück und konnte plötzlich keinen Befehl mehr ausführen, den ich gerade zuvor verwendet hatte: sshfs -o idmap=user -o allow_other user@mac.home:/Users/<username>/Documents ~/mountpoint

Das Problem ist, dass die Schlüssel nicht mehr synchron sind. Ich weiß nicht, ob ich dies tatsächlich sowohl auf meinem Host als auch auf meinem Server tun musste, aber ich habe alle lokalen Schlüssel auf jedem gelöscht, indem ich zuerst eine Sicherungskopie der Datei "unknown_hosts" erstellt und dann die Datei "unknown_hosts" bearbeitet habe, um Einträge zu entfernen .
Unter Mac befand sich diese Datei unter: /Users/<username>/.ssh/known_hosts
Unter Ubuntu befindet sich diese Datei unter:/home/<username>/.ssh/known_hosts

Zusammenfassend lässt sich sagen, dass alle nach dem Start des Ubuntu-Servers von meinem Mac-Terminal aus ausgeführt wurden:

cp /Users/<username>/.ssh/known_hosts /Users/<username>/.ssh/known_hosts.old
nano  /Users/<username>/.ssh/known_hosts
  # remove extra entries, save file
ssh <username>@ubuntu_server
cp /home/<username>/.ssh/known_hosts, /home/<username>/.ssh/known_hosts.old
nano /home/<username>/.ssh/known_hosts
  # remove extra entries, save file

Beim ersten SSH in jedem System fordert SSH mich auf, das Hinzufügen von RSA-Schlüsseln zuzulassen, und danach funktioniert alles.

— Beau
quelle