Fine, now, on your local machine (LOCAL), generate an IdentityFile to be used for mounting the remote filesystem. I suggest that, while root, you execute the following:
ssh-keygen -f /root/.ssh/YOURKEYFILE
Assure that permissions are set accordingly:
chmod -R 700 /root/.ssh
Now, get the /root/.ssh/YOURKEYFILE.pub file. Yes, the one ending in .pub, not your secret one. Now, on the machine REMOTE, I suggest you add a new user, to be used solely for mounting with sshfs. Give it a catchy name like REMOTEUSER:
useradd -m REMOTEUSER
password REMOTEUSER #do not leave this blank!
Now make sure that the contents of YOURKEYFILE.pub get appended or added to /home/REMOTEUSER/.ssh/authorized_keys (which is of course on REMOTE, not on LOCAL). I don’t know (or care) how, use scp, use another machine, use an USB stick, you’ll figure it out.

After all this, you should be able to log into REMOTEUSER from LOCAL by executing the following as root:
ssh -i /root/.ssh/YOURKEYFILE -p REMOTEPORTNUMBER REMOTEUSER@REMOTE
If this does not work, check logfiles or use debugmodes.

From here it’s not that much work to get to mounting disks or folders which are physically on REMOTE to LOCAL. First, make sure you have sshfs installed. In Gentoo you can simply emerge:
emerge -av sshfs-fuse
Do this.

Now, make sure you know your LOCALMOUNTPOINT (and ensure the empty folder exists by using mkdir) on LOCAL and know which REMOTEMOUNTPOINT you want to mount (located on REMOTE). Try mounting it by executing the following as root:
sshfs REMOTEUSER@REMOTE:REMOTEMOUNTPOINT LOCALMOUNTPOINT -pREMOTEPORTNUMBER -o uid=LOCALUSERID -o gid=DESIREDGROUPID -o idmap=user -o IdentityFile=/root/.ssh/YOURKEYFILE -o allow_other
Please pay close attention to which value is entered where, and, if in doubt, read man sshfs. The values for LOCALUSERID and DESIREDGROUPID determine with what ownership the REMOTEMOUNTPOINT is mounted on LOCAL. The numbers entered represent uid and gid numbers residing on LOCAL.

If this works as expected, it is a simple matter of reformatting the above command, so /etc/fstab is able to automatically mount your REMOTEMOUNTPOINT at (LOCAL)boot. Or so I thought. Turns out it was slightly more complicated, but after some trial and error and some more searching the web I came up with the following working line for fstab:
sshfs#REMOTEUSER@REMOTE:REMOTEMOUNTPOINT LOCALMOUNTPOINT fuse port=REMOTEPORTNUMBER,uid=LOCALUSERID,gid=DESIREDGROUPID,idmap=user,IdentityFile=/root/.ssh/YOURKEYFILE,allow_other 0 0
That should do the trick! You can test this by ensuring you have not mounted your REMOTEMOUNTPOINT on LOCAL at this moment (try fusermount -u LOCALMOUNTPOINT) and then simply entering:
mount LOCALMOUNTPOINT #Yes, the one you just entered in /etc/fstab
That’s it! Any comments or questions can be directed to the comments below and I will attempt to adjust the above as needed.

Yet after some more searching I discovered that ntpd quits if it discovers that the time offset is too large. As my server time was about 1 hour off, that kind of made sense. Another logfile revealed that this was indeed the issue:
tail /var/log/syslog

time correction of -3635 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

So how do we do that? Easy:
date MMDDhhmmYYYY #(Month, Day, hour, minute and Year)

And presto, problem solved! Do note that some programs may not appreciate sudden jumps in system time which you do cause by manually setting system time.

But it failed.

nmap: unrecognized option '--script'
[snip: followed by regular nmap --help output]

Eh?

As my thinking was suspended, I went for Google to find me the culprit responsible for this error. No results. What? Ah, well, this is just why I wanted my own blog: to enhance Google with yet unknown knowledge (or knowledge previously only available in obscure languages). Now only to find the solution…

Turns out it was actually rather simple: compile Nmap with the lua USE flag. Yes, that’s all.

OPEN PACKAGE.USE
nano /etc/portage/package.use
AND INSERT
net-analyzer/nmap lua
OR ON A TERMINAL ENTER
echo "net-analyzer/nmap lua" >> /etc/portage/package.use

After this you’re good to go.

While I’m at it, let’s leave you with the recommended scan options at the moment of writing:

#Source: Nmap changelog
o Recommended command for a fast Conficker scan (combine into 1 line):
nmap -p139,445 --script p2p-conficker,smb-os-discovery,smb-check-vulns
--script-args checkconficker=1,safe=1 -T4 [target networks]
o Recommended command for a more comprehensive (but slower) scan:
nmap --script p2p-conficker,smb-os-discovery,smb-check-vulns -p-
--script-args checkall=1,safe=1 -T4 [target networks]