by Steven J. Owens (unless otherwise attributed)
Written by clutch@xao, further tested and extended by puff@xao/lambda/darksleep.
I run a mud on my colo box. Actually a MOO, much more fun. One problem with muds and MOOs is that they don't have built-in ssh support. Here's how to fake that.
This document describes how to set up an anonymous account which allows outsiders to ssh into moo@yourdomain.com, and have all of their I/O automatically forwarded to the moo.
I make that this will not open you up to some clever and subtle attack. I can't see any obvious problems, but I don't even pretend to have thought long and hard on this. I have run it by a few other knowledgable folks, who also don't see any obvious vulnerabilities.
Also note, I'm not actually doing this with my own server, at present. If I were, I'm not sure I'd be publishing the details so cavalierly (not that security through obscurity is ever a good idea... but if I was actually doing this on my own server, I'd make sure to run this by a lot of smart, paranoid people before publishing it).
As a further caution: I've had some more paranoid folks review this, and they've pointed out several things that can go wrong, just off the tops of their heads. For example, using ssh port-forwarding, the passwordless user account we create below can also do an end-run around any TCP/IP stack-level firewall and use any other open services that are running on the box, like ftp.I don't actually think this is that big a vulnerability. I think you should make sure such services are secure on their own, and not depend entirely on firewalling at your TCP/IP stack. Defense in depth is a key security principle. If this really bothers you, you can use xinetd or rinetd to set up internal redirection.
But still, long story short, I am leaving this doc up as interesting reading, but I don't recommend actually doing the following without putting more skull sweat into figuring out how to lock down the anonymous user account.
You don't need to do any of the rest of this if your moo users actually have a normal shell login on your server. They can just use ssh tunneling to protect their tinyfugue connection to the moo. Like this:
# ssh -N -L 6666:mymoo.com:7777 moo@mymoo.com &
Now you just tell tinyfugue that the MOO is really at localhost, port 6666 and it will all connect up nicely. For instance, if you want to use your own local version of tinyfugue, you'd do it like this:
# tf localhost 6666
Note: Under windows, you can do the same thing using putty or similar windowsy ssh apps, but you'll have to look that up yourself. Google on "ssh tunneling" or "ssh portforwarding" and add appropriate search keywords and phrases like "windows" or "I like to run unsecure OSes".
It's really fairly easy to do; in summary, you:
Note that this will also allow any random outsider to connect to your server using all the powers of ssh. That seems to boil down to being able to portforward to any port on the server. Some sort of internal redirection using xinetd or rinetd might be a good diea.
On the other hand, I don't see that as being too threatening, other than perhaps by sucking up resources by setting up numerous portforwarding sessions.
You'll need root permission to do this. Essentially you're going to set up an account with no password, which is configured not to use a normal shell (like bash) but instead to run netcat and forward all IO to the MOO.
So, su to root, or use sudo, or whatever you do, then come on back. In the following examples, I'm going to assume you're logged in as root, so the prompt will be a "#" instead of "$".
Back? Ok. First,
# sudo adduser moo
On BSD systems, just
# adduser
then follow the prompts. Create the user as you would create any normal user.
Don't worry about the password, since we're going to delete it. Just make one up, and enter it.
Done? Good.
Now we want to zero out the password; remove it completely.
Remember, I make about the safety of this whole approach. This is where we potentially step off the security cliff and have our Wile E. Coyote moment.
On Linux systems,
# vi /etc/shadow
and find the line that looks like
moo:vq.6C3yUWBZcAw:11660:0:99999:7:::
and delete the encrypted password from the second field. In this example that's the part that looks like "vq.6C3yUWBZcAw". Delete it entirely, leaving just two colons with not even a space in between them. It should end up looking like:
moo::11660:0:99999:7:::
On BSD systems, just
# vipw
and find the line that looks like
moo:$2a$06$SO.e.mDkAeVP7ryRdDaog.cgm8vpCmgciIdCzVHbHfPbLYkB/GZZu:1001:1001::0:0::/home/moo:/bin/sh
and change it like so:
moo::1001:1001::0:0::/home/moo:/bin/sh
That's the password taken care of.
Now login as the new user "moo" and run ssh-keygen.
Refer to any standard ssh tutorial for how to do this.
The original version of this (see below) set up the account's default shell as either directly running tinyfugue or running a shell script that invoked netcat. I'm told that we don't really need to do either one of those, and since they're not as safe, we're going to just set up the account's default shell to directly run netcat:
Just use vipwd to directly edit /etc/passwd and set the shell field to be the entire netcat command, including path and parameters, something like this:
moo::1001:1001::0:0::/home/moo:/usr/bin/nc localhost 7777
Now we need to set up the login shell, which for the sake of example will be tinyfugue (note; we went back and did it with netcat, with no problems; netcat is probably safer).
Install tinyfugue. The steps to do this vary, depending on your particular system. I use Debian gnu/linux, so I just "apt-get install tinyfugue".
Cut and paste the following into the file ~moo/.tfrc
/hook DISCONNECT = /quit /more on /connect localhost 7777
Log out and continue as root.
Pretty much edit /etc/shells and add a line "/usr/games/tf"
One quick way to do this:
# echo /usr/games/tf >> /etc/shells
Note that this just executes tinyfugue (or tinyfugue) without any arguments. All of the important details are specified in the ~/.tfrc file, above.
To use netcat, we need to create a specific shell script to invoke netcat, and add that specific shell script to /etc/shells:
In the moo user's home directory (which we will assume is /home/moo), create a file named moo.sh, and edit, adding these lines:
#! /bin/bash /bin/nc localhost 7777
Make the file executable:
# chmod ugo+x moo.sh
Now change the login shell of your anonymous moo account, either by editing the user's line in /etc/passwd, or by using the "chsh" command:
# chsh -s /usr/games/tf moo
Or for netcat:
# chsh -s /home/moo/moo.sh moo
When you're done, the line for the moo user should look like either of these two lines. For using tinyfugue:
moo:x:1090:1090:MOO server user,,,:/home/moo:/usr/games/tf
Or, for using netcat:
moo:x:1090:1090:MOO server user,,,:/home/moo:/home/moo/moo.sh
Before you do this step, remember, . Note that permitting empty passwords is generally a bad idea. Having an account with an empty password creates a lot of opportunities for security holes. Even if you get it all right for this particular account with an empty password, disabling the PAM protections against empty passwords creates the opportunity for some other user of your system to not get it right.
Edit /etc/ssh/sshd_config. Make sure you have the following lines somewhere in your sshd_config file:
PubkeyAuthentication yes RSAAuthentication yes PasswordAuthentication yes PermitEmptyPasswords yes
And if necessary, restart your sshd. On a debian system (and any system that follows the Linux File System Standard, that's:
# /etc/init.d/ssh restart
If you are running Linux, you probably have PAM. Make sure you have this exact line in your /etc/pam.d/ssh file:
auth required pam_unix.so nullok
and not a line that looks like this:
auth required pam_unix.so
Thats it. You are done. To connect to the MOO and use the tinyfugue MOO client program, just
# ssh moo@mymoo.com
And we're done.