sshfs with fstab: resetowanie połączenia przez peer

Usiłuję umożliwić mojemu laptopowi (Ubuntu 13.04) dostęp do mojego dysku twardego komputera (Lubuntu 13.04) przez SSHFS. Do połączenia używam kluczy RSA.

Działa idealnie dobrze, jeśli wpiszę to w terminalu:

sshfs my-PC:/a_folder /media/a_folder

Ale chciałbym, aby został on zamontowany automatycznie po uruchomieniu komputera. Więc dodałem się do grupy bezpieczników:

sudo adduser mynickname fuse

I dodałem następujący wiersz do mojego pliku fstab:

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

Kiedy uruchamiam laptopa, folder__ pojawia się na liście urządzeń, ale nie jest zamontowany. Kiedy próbuję uzyskać do niego dostęp za pośrednictwem Nautilus, wyświetla następujący błąd:

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

Otrzymuję ten sam błąd, jeśli spróbuję

mount /media/a_folder

w terminalu.

Jeśli spróbuję

sudo mount /media/a_folder

dostaję

read: Connection reset by peer

Próbowałem dodać „allow_other” jako opcję we wpisie fstab i odkomentowałem odpowiednią linię w /etc/fuse.conf, ale nic to nie zmieniło.

Użytkownik „mynickname” jest właścicielem folderu / media / a_folder i ma uprawnienia rwx.

Przejrzałem wiele wątków w Internecie na temat osób o podobnych problemach, ale jak dotąd nic nie działało. Zwykle ludzie nawet nie potrafią

sshfs my-PC:/a_folder /media/a_folder

bez błędu, ale działa to dobrze na moim laptopie.

Wszelkie spostrzeżenia i wskazówki będą mile widziane! Dzięki.

EDYCJA: Rozwiązałem ten problem jakiś czas temu, ale zapomniałem zaktualizować ten post. Oto, co jest w moim fstab:

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

Jeśli pamiętam, kluczową opcją do dodania były uprawnienia domyślne. Musiałem dodać mynickname do grupy, do której należy / a_folder / na moim komputerze.

Występuje problem polegający na tym, że normalny użytkownik ma poprawną konfigurację pliku tożsamości, podczas gdy użytkownik root nie ma pojęcia, jakiego klucza ssh użyć.

Możesz to naprawić, informując fstab, jakiego pliku tożsamości / klucza ssh należy użyć podczas próby połączenia:

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

Aby uzyskać prawdziwy wynik debugowania, musisz dodać obie opcje sshfs_debugi debugopcje do montowania:

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

Dzięki temu otrzymasz wiele informacji debugowania, które pomogą Ci:

$ 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

W moim przypadku odkryłem, że moja maszyna była tylko wymieniona na liście .ssh/config, więc nie można jej było usunąć z roota.

I BTW, musisz ustawić uid i gid, ponieważ idmap=userwydaje się, że działa tylko dla bieżącego użytkownika, który w tym przypadku jest rootem.

Ten problem może również wystąpić, gdy zmienia się klucz hosta ssh.

Spróbuj połączyć się z serwerem przez ssh (np ssh username@hostIP.). Jeśli pojawi się następujący błąd:

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

Postępuj zgodnie z instrukcjami w komunikacie o błędzie, aby usunąć stary klucz i spróbuj ponownie połączyć się przez ssh. Jeśli błąd już się nie pojawia, połączenie sshfs powinno działać.

Pełne ujawnienie: oldschoolowy maniak, ale nowa klapsa marki w świecie linux / open source

Po pierwsze, nadal używam uwierzytelniania hasłem, ponieważ nie jestem jeszcze wystarczająco zorientowany z kluczami RSA. To jednak zbliża się do szczytu listy.

Ważne informacje o konfiguracji: Używanie MacBooka Pro z zainstalowanym VMWare Fusion, na którym mam serwer Ubuntu 10.04 LTS. Poleganie na terminalu Mac i SSH dla prawie wszystkich moich interakcji z serwerem

Po zainicjowaniu instalacji Drupala przywróciłem poprzednią migawkę i nagle nie byłem w stanie wykonać polecenia, którego użyłem chwilę wcześniej: sshfs -o idmap=user -o allow_other user@mac.home:/Users/<username>/Documents ~/mountpoint

Problem polega na tym, że klucze zostały zsynchronizowane. Nie wiem, czy rzeczywiście musiałem to zrobić na moim hoście i serwerze, ale wyczyściłem wszystkie klucze lokalne na każdym z nich, najpierw wykonując kopię zapasową pliku znanego_hosta, a następnie edytując plik znanego_hosta, aby usunąć wpisy .
W systemie Mac ten plik znajdował się w: /Users/<username>/.ssh/known_hosts
W systemie Ubuntu ten plik znajduje się w:/home/<username>/.ssh/known_hosts

Podsumowując, wszystkie wykonywane z mojego terminala Mac, po uruchomieniu serwera Ubuntu:

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

Po pierwszym SSH w każdym systemie, SSH monituje mnie o zezwolenie na dodanie kluczy RSA i wszystkie prace później.