ssh login shell

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 nbuilt-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 NO GUARANTEES 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, 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.

DOING IT SAFELY AND SECURELY

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".

LETTING IT ALL HANG OUT

It's really fairly easy to do; in summary, you:

  1. set up an account named moo,
  2. zero out the moo account's password.
  3. set up ssh keys for the moo account to allow passwordless access
  4. make sure some ssh bits are configured to allow empty passwords, etc.
  5. edit /etc/passwd and set the moo user's shell to be the netcat command

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.

ENCRYPTING YOUR MOO SESSIONS WITH SSH

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,

CREATE AND CONFIGURE THE ANONMOO USER

# 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 NO GUARANTEES 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.

SET UP SSH FOR PASSWORDLESS ACCESS

Now login as the new user "moo" and run ssh-keygen.

Refer to any standard ssh tutorial for how to do this.

MAKE NETCAT THE MOO ACCOUNT'S LOGIN SHELL

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

SET UP THE LOGIN SHELL

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).

OLD, UNSAFE APPROACH USING TINYFUGUE AS THE SHELL SCRIPT

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.

ADD TINYFUGUE TO THE LIST OF VALID LOGIN SHELLS

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.

OLD UNSAFE APPROACH USING A SHELL SCRIPT TO RUN NETCAT

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 

CHANGE THE LOGIN SHELL

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

CONFIGURE SSH CORRECTLY

Before you do this step, remember, NO GUARANTEES. 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

FINALLY, AD EXTREMUM, EN FIN

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.


See original (unformatted) article

Feedback

Verification Image:
Subject:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator.
Message Content: