On Mon, Jun 23, 2003 at 12:07:54AM -0400, Matt Price wrote: > On Sat, Jun 21, 2003 at 12:24:05AM -0400, James Strandboge wrote: > > > > > Ouch. You may already be hacked. > > jeez, guys, it was only up for about 5 minutes -- I'm not THAT stupid (though > I can be pretty dumb if left to my own devices) Sometimes that's all it takes.
> > > > The ports are portmap and whatever is listed with 'rpcinfo -p'. > > thanks. I think I understand (though I don't see how to get information using > portmap.) rpcinfo uses portmap. portmap is a daemon to help handle a bunch of rpc (remote procedure calls) in glibc. > > > > But please don't do this at all-- you are opening yourself up to a whole > > bunch of problems. > > do you mean, don't do NFS via ssh either? No. nfs via ssh is fine as long as you remember that user authentication isn't a part of the core nfs protocol. On a standalone workstation at home, this shouldn't be an issue. I was merely trying to get you to use scp because it is easy. NFS over ssh can be tricky to set up. Also, portmap will expose your mount and umount commands in the clear over the internet-- this may or may not be an issue. People can learn that you have an nfs server at work and may try to attack it. Assuming your /etc/exports, /etc/hosts.allow, /etc/hosts.deny, sshd and firewall rules are all set up properly, this won't be an issue. This is a lot to take into consideration though-- which is one reason why NFS is notorious for its security. It can be made quite secure, but getting it there takes patience and a lot of attention to detail. > > If you must have nfs, it is possible to use nfs with > > ssh. See: > > > > http://www.samag.com/documents/s=4072/sam0203d/sam0203d.htm > > this is a great article, James, thanks for writing it and pointing me > to it. > Thanks, it was fun to write. > Unfortunately, even with directions as explicit and clear as yours, I > couldn't get NFS over SSH to work for me. I think the issue is part > denseness, part the result of working around my home router, and not > understanding port forwarding very well; and at least a small part is > a little harder to explain. > The home router isn't a problem-- this is why nfs over ssh is a nice alternative to IPsec or afs-- ssh works fine with NAT. > Hope folks don't mind if I go through James' article step by step. > > SERVER CONFIGURATION > > 1) setting up /etc/exports > no problem. added this line: > #trying to do ssh tunnelling > /home/matt/Projects 128.100.34.9(ro,insecure,root_squash) > First off, is 128.100.34.9 the server's ip address that ssh is listening on? In other words, it needs to be the *actual* ip address of the server (eg, what use ssh to), not the company gateway machine or similar. Often this is a non-routable address like 192.168.x.x or 10.x.x.x. Because you listed a routable address, I just wanted to make sure you were using the right one. > 2) edit nfs init script > ...er... that didn't go so well! it was easy to get nfs to > stop and kill sshd before working, by adding the lines: > > /etc/init.d/ssh stop > killall sshd > > at the beginning of the script > > but no matter where I put the restart command: > > /etc/init.d/ssh restart > > I couldn't get sshd to start back up again. James, do you have a copy > of a working /etc/init.d/nfs-user-server that starts ssh and then > restarts it? I think I don't fully understand the bash syntax (sorry > for my ignorance). > Don't bother with this at first. Just get ssh and nfs working. Basically, you can selectively kill any ssh pids that are dealing with your nfs connection, but not have to kill the whole sshd server each time-- that was in the article only as a convenience. NFS *must* be started before ssh, and nfs-user-server sometimes gets confused when things aren't quite right. Try this after a failed mount attempt: kill <pids of ssh that are used with nfs (see with 'ps auxww')> /etc/init.d/nfs-user-server stop /etc/init.d/nfs-common stop /etc/init.d/portmap stop /etc/init.d/portmap start /etc/init.d/nfs-common start /etc/init.d/nfs-user-server start Restarting the nfs server in this way makes sure you have a clean slate. This should be all you need to do-- and you shouldn't have to resort to remotely restarting ssh. > 3. setup iptables (in my case using ipmasq) > > had a little trouble here specifying the address of my client (home) > machine, which is set dynamically by pppoe. Finally realized that I > couldn't do as I'd planned and enter my dyndns domain name, since it > can't be determined without DNS, and iptables really didn't want to > let me use dns. I'm wondering if this can somehow be done with a > script -- run a cron job every five minutes that checks the IP adress > of my dyndns.org domain, exports the value as a variable, which is > then read by iptables/ipmasq. Does that sound like it would work? > Yes. But this isn't really needed in your situation because you said you already have ssh connectivity to your server from home. This is *all* that is required. If you couldn't ssh to your work machine, then that would be different. You should be able to get away with not allowing in portmap, if you specify all the options needed to mount (in other words, mount doesn't need to query portmap). However, you may find that allowing your client access to tcp port 111 is easier (in this case, you will need to figure out a way to update the firewall-- a script every five minutes would not be bad). > For now I just entered my current IP, which works fine. > > CLIENT CONFIGURATION > 1. get server's ports > no problem. here's the current output: > matts-mac:~# rpcinfo -p 128.100.34.9 > program vers proto port > 100000 2 tcp 111 portmapper > 100000 2 udp 111 portmapper > 100024 1 udp 865 status > 100024 1 tcp 868 status > 100003 2 udp 2049 nfs > 100003 2 tcp 2049 nfs > 100005 1 udp 986 mountd > 100005 2 udp 986 mountd > 100005 1 tcp 989 mountd > 100005 2 tcp 989 mountd > > 2. set up tunnel > this usually works,with a command like this: > > ssh -f -c blowfish -L 2820:128.100.34.9:2049 -L 3047:128.100.34.9:989 -l matt > 128.100.34.9 /bin/sleep 86400 > This looks fine. > > 3. mount the nfs volume... ... this always fails catastrophically. > In particular, I never seem to be able to open up the requisite ports > on the client end. I suspect this has something to do with the home > network. Now, on my router (an SMC Barricade, with a web-only > interface) I don'th ave tons of options. I can forward individual > port directly from the router to the home computer; or I can put the > home computer in a DMZ. Will either of these strategies work? what > further information can I provide to help with diagnosis? What mount command are you specifying? As far as the router, the client is making direct connections to the server over the ssh port, and the server is responding, shouldn't need to forward anything. You may find port forwarding tcp port 111 to your home machine is worthwhile. Your home machine should have portmap controlled in /etc/hosts.allw|deny and also with iptables/ipchains to only allow access from the server. I assume that you have nfs-common and portmap installed and running at home and have the necessary utilities to mount nfs volumes? Good luck. Jamie PS-- having said all of this, you might try a VPN solution. I use vtund and mount nfs volumes from remote laptops without issue. This way you set up the nfs server in the usual way, have your client VPN into the network, and you have access. Of course, this may be too much access from home-- just a thought. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
