On Wed, 30 Jun 2004, Michael A. Alderete wrote:
> It should be noted that this is a specific design decision made by Manuel,
> and that it's pretty firm.
> I once made a cash donation to the project, and then followed up by asking
> for ssh. Manuel asked me what I thought I would do with ssh access, since
> there was no shell, no text editor, etc. My only answer was "uh...dick
> around, like on my FreeBSD system". After a couple more e-mails, I conceded
> that having ssh access in m0n0wall did not make sense, and withdrew the
Well, I can think of a few things: :-)
1) Do things that you might do with exec.php but can't because they may
generate too much output or hang up for too long.
2) Use diagnostic functions that are more useful interactively.
3) Execute (with string authentication) commands via SSH's "remote
command" mechanism without "logging in" to the m0n0wall at all.
4) Move files back and forth via scp instead of clumsy upload/download.
5) Tunnel a connection to the WebGUI to make access orders of magnitude
more secure than you get with lame HTTP authentication, SSL
6) Tunnel WAN connections to other machines on the LAN, without requiring
another machine to be up just to act as an SSH server.
With regard to "no shell, no editor, etc.":
1) There *is* a shell there. Maybe not as featureful as bash, but
nevertheless a shell. And guess what? It's used by exec.php.
2) You can get along without an editor by just using scp to move files
elsewhere for editing. That has the added benefit of leaving the editor
backup files on the other machine.
3) Not sure what's critical in the "etc." category, though "mv" would be
On Thu, 1 Jul 2004, Gorm J. Siiger wrote:
> tcpdump is your most important tool in debugging and problem solving, sure
> you can put up three or four local sniffers, do port mirroring and other
> stuff but it takes time and cost money.
And since most things use switches these days, packet capture via another
machine typically doesn't work with "default hardware".
> So I see two ways of solving this problem:
> 1. Make shell access via SSH and give access to tcpdump, ping, tracroute,
> arp etc.
A limited ping is available, but the command-line version is
Arp could be done through the GUI; that's just an oversight.
Traceroute would be kinda sorta usable through the GUI, though the
real-time version is better.
You could manage to do tcpdump capturing to a file in a really kludgy way,
but running it interactively is more useful. Unfortunately,
tcpdump+libpcap is almost 1.5MB, so shell access isn't the only issue, at
least for those of us running on Soekris hardware.
> 2. I know there is a client/server tcpdump util, and with the client you can
> dump remotely on the box from you pc.
One that really works? I did some looking around for such a beast, and
found two things:
1) An experimental SNMP-based packet capture mechanism (called RMON
IIRC) that has so many problems that even the guy who wrote it (as an
experiment) doesn't really recommend the approach.
2) A package called "rpcap", that seems to be a work-in-progress.
On Thu, 1 Jul 2004, zealot wrote:
> I'm curious, do you guys run m0n0wall on compact flash or hard drive? If
> compact flash, how large is the CF card?
I happen to be using 128MB cards, but m0n0wall currently only uses
5MB. It could expand considerably and still fit in 16MB cards recycled
from digital cameras. :-)