sshfs con fstab: connessione ripristinata dal peer

10

Sto cercando di consentire al mio laptop (Ubuntu 13.04) di accedere al disco rigido del mio PC (Lubuntu 13.04) tramite SSHFS. Sto usando le chiavi RSA per connettermi.

Funziona perfettamente se lo scrivo nel terminale:

sshfs my-PC:/a_folder /media/a_folder

Ma vorrei che venisse montato automaticamente all'avvio del mio laptop. Quindi mi sono aggiunto al gruppo dei fusibili:

sudo adduser mynickname fuse

E ho aggiunto la seguente riga al mio file fstab:

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

Quando avvio il laptop, a_folder appare nell'elenco dei dispositivi, ma non è montato. Quando provo ad accedervi tramite Nautilus, viene visualizzato il seguente errore:

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

Ottengo lo stesso errore se provo

mount /media/a_folder

in un terminale.

Se ci provo

sudo mount /media/a_folder

ottengo

read: Connection reset by peer

Ho provato ad aggiungere "allow_other" come opzione nella voce fstab e ho decommentato la riga relativa in /etc/fuse.conf, ma non ha cambiato nulla.

L'utente "mynickname" è il proprietario della cartella / media / a_folder e dispone delle autorizzazioni rwx.

Ho guardato molti thread su Internet su persone con problemi abbastanza simili, ma nulla ha funzionato finora. Di solito, le persone non possono nemmeno farlo

sshfs my-PC:/a_folder /media/a_folder

senza errori, mentre questo funziona bene sul mio laptop.

Eventuali approfondimenti e suggerimenti saranno molto apprezzati! Grazie.

EDIT: ho risolto questo problema qualche tempo fa, ma ho dimenticato di aggiornare questo post. Quindi ecco cosa c'è nel mio fstab:

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

L'opzione chiave da aggiungere era default_permissions se ricordo. Ho dovuto aggiungere mynickname al gruppo a cui appartiene / a_folder / sul mio PC.

fstab sshfs

8

Il problema che stai riscontrando è che il tuo normale utente ha una configurazione corretta per il tuo file di identità, mentre l'utente root non ha idea di quale chiave ssh usare.

È possibile risolvere questo problema dicendo a fstab quale file di identità / chiave ssh usare durante il tentativo di connessione:

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

— earthmeLon
fonte

Grazie per la tua risposta. Ho già provato con l'opzione IdentityFile, ma non ho specificato le opzioni uid e gid, quindi lo proverò!

Tecnicamente, non dovresti aver bisogno di usare sudose tutto è impostato correttamente per un innesto FUSE. Inoltre, le impostazioni uid / gid dovrebbero influenzare solo quale utente ha i diritti sui file sul proprio sistema.

— earthmeLon

Quindi ho appena provato con uid, gid, IdentityFile, allow_other, tutte quelle opzioni allo stesso tempo, e sfortunatamente non funziona ancora. Ancora lo stesso errore.

Ti dispiacerebbe pubblicare un esempio di come l'hai scritto? Dovresti puntare alla tua chiave privata e non alla tua chiave pubblica.

— earthmeLon

1

Quindi entrambi i metodi non hanno funzionato. Ancora lo stesso errore. Per il file di configurazione, ho provato specificando l'host giusto: utente, nome host (provato sia IP che nome), file di identità. Ma non ha funzionato altrettanto bene. Quindi quello che finisco per fare ora è che ho aggiunto il comando sshfs my-PC: / a_folder / media / a_folder nelle applicazioni di avvio. Non è pulito come usare fstab, ma per ora funziona abbastanza bene. Grazie per il vostro aiuto e i vostri suggerimenti! Se pensi a qualcos'altro, sentiti libero di condividere, lo apprezzerò!

4

Per ottenere un output di debug reale è necessario aggiungere entrambe sshfs_debuge debugopzioni alla montatura:

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

Con questo otterrai molte informazioni di debug per aiutarti:

$ 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

Nel mio caso ho scoperto che il mio computer era elencato solo in .ssh/config, quindi era irrisolvibile per root.

E a proposito, devi impostare uid e gid, poiché idmap=usersembra funzionare solo per l'utente corrente, che è root in questo caso.

— Alexander Torstling
fonte

3

Questo problema può verificarsi anche quando cambia la chiave host di ssh.

Prova a connetterti al server tramite ssh (ad es ssh username@hostIP.). Se viene visualizzato il seguente errore:

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

Seguire le istruzioni nel messaggio di errore per eliminare la vecchia chiave e provare a riconnettersi via ssh. Se l'errore non viene più visualizzato, la connessione sshfs dovrebbe funzionare.

— Gorka
fonte

"prova a connetterti al server tramite ssh" Assicurati di farlo come root se stai montando la directory come root (che è ciò che succede quando si monta automaticamente). Il known_hostsfile di un utente può essere diverso dal known_hostsfile di root .

— Shelvacu,

0

Divulgazione completa: fanatico della vecchia scuola, ma il marchio è nuovo di zecca nel mondo linux / open source

Prima di tutto, sto ancora usando l'autenticazione con password perché non sono ancora diventato abbastanza esperto con le chiavi RSA. Questo è quasi in cima alla lista però.

Informazioni importanti sulla configurazione: utilizzo di un MacBook Pro con VMWare Fusion installato, su cui ho il server Ubuntu 10.04 LTS. Affidandomi al terminale Mac e SSH per quasi tutte le mie interazioni con il server

Dopo aver fallito l'installazione di Drupal, sono tornato a un'istantanea precedente e improvvisamente non sono stato in grado di eseguire un comando che avevo appena usato in precedenza: sshfs -o idmap=user -o allow_other user@mac.home:/Users/<username>/Documents ~/mountpoint

Il problema è che i tasti non sono stati sincronizzati. Non so se in realtà avevo bisogno di farlo sia sul mio host che sul mio server, ma ho cancellato tutte le chiavi locali su ognuna facendo prima un backup del file known_hosts, quindi modificando il file known_hosts per rimuovere le voci .
Su Mac, questo file si trova su: /Users/<username>/.ssh/known_hosts
Su Ubuntu, questo file si trova su:/home/<username>/.ssh/known_hosts

Quindi, per riassumere, tutto eseguito dal mio terminale Mac, dopo aver avviato il server 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

Al primo SSH in ciascun sistema, SSH mi chiede di consentire l'aggiunta delle chiavi RSA e tutte le funzioni successive.

— innamorato
fonte