On Sun, 20 Mar 2011 12:27:40 +0100 Klistvud <quotati...@aliceadsl.fr> wrote:
> Dne, 20. 03. 2011 05:23:34 je Celejar napisal(a): > > On Sun, 20 Mar 2011 00:01:27 -0400 > > Chris Brennan <xa...@xaerolimit.net> wrote: > > > > > Sshfs requires fusefs to function, syntax is the same as > > SSH/sftp/scp. > > > > IIUC, sshfs+fusefs must be on the system from which I'm running the > > sshfs command, but is not necessary on the other one; correct me if > > I'm > > wrong. As I've said, I do have a working sshfs setup on my Debian box > > (it works with other Debian boxes). > > Then it's probably something with your OpenWrt ssh daemon and how it's > configured (you *have* the daemon running on it, I trust). In my > experiences with OpenWrt, they are forced to strip down their packages > quite a bit (for example, they ship a tiny cron that won't recognize > directives such as @reboot and the like; and God only knows what gets > left out from their kernel in order to keep it so small). Well, OpenWrt uses Dropbear, not the regular ssh to begin with. > > > > I did consider sshfs, but for some reason, it won't work; when I > > try to > > > > connect from my linux system to the OpenWrt box, all I get is the > > less > > > > than helpful error "remote host has disconnected". ssh works fine > > > > between the two boxes (using public / private keys), and I've > > used sshfs > THIS! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Probably the reason. Did you try running sshfs with simple password > verification first? Setting the right keys into the right ~/.ssh > directories, and with the right permissions, is probably the most > annoying part when setting up sshfs/fusefs with public/private keys > verification. It certainly helps if you set your remote ssh daemon to > "verbose" logging for the time being. I'm not sure exactly what I need to do to prevent sshfs from using keys, but no matter what I try, I get the same error. > > > > before between two Debian boxes. > > > > > > > > Celejar > > FWIW: fusefs issupposedly more secure than nfs, but being done in user > space, it's also less flexible. For example, simply copying some user > A's files, if done from user B's account (which generally does not have > write permissions to A's home subtree) may involve copying them to an > intermediate "staging" area on the remote machine first, then logging > into the remote machine, becoming root there, moving over the copied > files from the staging area to their final, intended destination, and > finally setting their ownership/permissions right. Quite a chore, as > opposed to the totally seamless usage I was used to with nfs... Got it, thanks. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110321150701.3dd96a57.cele...@gmail.com
