sshfs com fstab: redefinição de conexão por pares


10

Estou tentando permitir que meu laptop (Ubuntu 13.04) acesse o disco rígido do meu PC (Lubuntu 13.04) através do SSHFS. Estou usando chaves RSA para conectar.

Funciona perfeitamente bem se eu digitar isso no terminal:

sshfs my-PC:/a_folder /media/a_folder

Mas eu gostaria que fosse montado automaticamente quando eu inicializar o meu laptop. Então eu me adicionei ao grupo de fusíveis:

sudo adduser mynickname fuse

E adicionei a seguinte linha ao meu arquivo fstab:

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

Quando eu inicializo o laptop, a_folder aparece na lista de dispositivos, mas não está montado. Quando tento acessá-lo através do Nautilus, ele exibe o seguinte erro:

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

Eu recebo o mesmo erro se tentar

mount /media/a_folder

em um terminal.

Se eu tentar

sudo mount /media/a_folder

eu recebo

read: Connection reset by peer

Tentei adicionar "allow_other" como uma opção na entrada fstab e descomentei a linha relacionada no /etc/fuse.conf, mas não mudou nada.

O usuário "mynickname" é o proprietário da pasta / media / a_folder e possui permissões de rwx.

Analisei muitos tópicos na internet sobre pessoas com problemas semelhantes, mas nada funcionou até agora. Normalmente, as pessoas não conseguem nem fazer

sshfs my-PC:/a_folder /media/a_folder

sem obter um erro, enquanto isso funciona bem no meu laptop.

Qualquer insight e dicas serão muito apreciados! Obrigado.

EDIT: Solucionei esse problema há um tempo, mas esqueci de atualizar este post. Então, aqui está o que está no meu fstab:

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

A principal opção a ser adicionada foi default_permissions, se bem me lembro. Eu tive que adicionar mynickname ao grupo ao qual pertence / a_folder / no meu PC.

fstab  sshfs 

Respostas:


8

O problema que você está enfrentando é que seu usuário normal possui uma configuração correta para o seu arquivo de identidade, enquanto o usuário root não tem idéia de qual chave ssh usar.

Você pode corrigir isso dizendo ao fstab qual arquivo de identidade / chave ssh usar ao tentar se conectar:

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

Obrigado pela sua resposta. Eu já tentei com a opção IdentityFile, mas não especifiquei as opções uid e gid, então tentarei isso!

Tecnicamente, você não precisa usar sudose tudo estiver configurado corretamente para uma montagem FUSE. Além disso, as configurações de uid / gid devem afetar apenas qual usuário tem direitos sobre os arquivos no seu sistema.
earthmeLon

Então, eu apenas tentei com uid, gid, IdentityFile, allow_other, todas essas opções ao mesmo tempo e, infelizmente, ainda não funciona. Ainda é o mesmo erro.

Você se importaria de postar uma amostra de como a escreveu? Você deve estar apontando para sua chave privada e não para sua chave pública.
earthmeLon

1
Portanto, ambos os métodos não funcionaram. Ainda é o mesmo erro. Para o arquivo de configuração, tentei especificando o host correto: usuário, nome do host (tentei o IP e o nome), arquivo de identidade. Mas não funcionou tão bem. Então, o que acabo fazendo agora é que adicionei o comando sshfs my-PC: / a_folder / media / a_folder nos aplicativos de inicialização. Não é tão limpo quanto usar o fstab, mas funciona bem o suficiente por enquanto. Obrigado por sua ajuda e suas sugestões! Se você pensa em outra coisa, sinta-se à vontade para compartilhar, eu aprecio isso!

4

Para obter uma saída de depuração real, você precisa adicionar as opções sshfs_debuge e debugo mount:

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

Com isso, você obterá muitas informações de depuração para ajudá-lo:

$ 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

No meu caso, descobri que minha máquina estava listada apenas em .ssh/config, portanto, não era possível resolvê-la como root.

E, BTW, você precisa definir uid e gid, pois idmap=userapenas parece funcionar para o usuário atual, que é a raiz nesse caso.


3

Esse problema também pode ocorrer quando a chave do host do ssh é alterada.

Tente se conectar ao servidor via ssh (por exemplo ssh username@hostIP). Se o seguinte erro aparecer:

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

Siga as instruções na mensagem de erro para excluir a chave antiga e tente conectar-se novamente via ssh. Se o erro não aparecer mais, a conexão sshfs deverá funcionar.


"tente conectar-se ao servidor via ssh" Certifique-se de fazer isso como root se estiver montando o diretório como root (o que acontece ao montar automaticamente). O known_hostsarquivo de um usuário pode ser diferente do known_hostsarquivo raiz .
Shelvacu

0

Divulgação completa: nerd da velha escola, mas uma nova marca no mundo do linux / código aberto

Primeiro, ainda estou usando a autenticação de senha porque ainda não me tornei experiente o suficiente com as chaves RSA. Isso está chegando ao topo da lista.

Informações relevantes de configuração: Uso de um MacBook Pro com o VMWare Fusion instalado, no qual tenho o servidor Ubuntu 10.04 LTS. Confiando no terminal e SSH do Mac para quase toda a interação com o servidor

Depois de danificar uma instalação do Drupal, voltei para um instantâneo anterior e de repente não consegui executar um comando que acabara de usar momentos antes: sshfs -o idmap=user -o allow_other user@mac.home:/Users/<username>/Documents ~/mountpoint

O problema é que as chaves ficaram fora de sincronia. Não sei se realmente precisava fazer isso no meu host e no servidor, mas limpei todas as chaves locais em cada uma, primeiro fazendo um backup do arquivo known_hosts e editando o arquivo known_hosts para remover as entradas .
No Mac, este arquivo estava localizado em: /Users/<username>/.ssh/known_hosts
No Ubuntu, este arquivo está localizado em:/home/<username>/.ssh/known_hosts

Então, para resumir, tudo foi executado no meu terminal Mac, após a inicialização do servidor 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

Após o primeiro SSH em cada sistema, o SSH solicita que eu permita a adição de chaves RSA e todos os trabalhos posteriores.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.