ssh chroot fine, but telnet wide open

[Steve Post]

I'm really surprised this is not already answered. I clicked on lots and lots of links that supposedly answer my question. They don't answer it. So....... I gotta ask.

I used the hp document and ran /opt/ssh/utils/ssh_chroot_setup.sh.

It works great for ssh.
But normal telnet is WIDE OPEN.
In other words, I locked the door to the barn. But it is missing an entire WALL.

Turning off telnet is one option. But that is not the only answer is it? And if I make nice changes so telnet is chrooted, will it make ssh wide open?

[Matti_Kurkela]

Not only is your barn missing a wall; the keys of your barn are inadequately protected too. I'm talking about telnet transmitting the passwords in plaintext, of course.

You've discovered one feature of the classic Unix login procedure: all different login methods are essentially separate, and making changes to one login method has no effect at all on other methods.

PAM has the capability to remedy this. If you had a PAM session module that could set up a chroot around the user's session, configuring that module would enable the chroot functionality at once for all login methods (that use the PAM session module).

Unfortunately as far as I know, HP has not implemented this. So the current state of affairs with HP-UX is that you must configure each and every login method separately to use chroot and/or disable those that cannot be chrooted.

If you created a chrooting PAM session module and configured all the login methods to use it, it would be the closest thing to the one-stop solution you seem to be seeking.

Note that SSH has a configuration setting that allows you to choose whether SSH uses PAM or not. If you configure PAM to chroot the users and then configure SSH _not_ to use PAM, then SSH sessions won't be chrooted unless you separately configure SSH to chroot the users too.

In practice, when implementing a chroot for security, you should try to make the chroot environment as minimalistic as practical. Usually that means there's only one login method (or maybe two if the bad old FTP absolutely must be one of them).

I don't know what kinds of primary threats you're trying to protect against, but usually getting rid of protocols that transfer passwords in plaintext over the network is a basic security requirement, while implementing a chroot is somewhat more advanced one.

MK

[Steve Post]

In this case, the box is far inside the firewall. I don't want to use telnet, and would turn it off immediately except that I need to make sure no one (or horrible batch job) is still committed to using it.

The only thing I'm really doing is keeping developers from wandering around on the box. I can talk to all 6 of them directly.

I know I can reject users in sftp/ssh via the sshd_config file.
I know I can reject ftp users in the ftpd/ftpusers file.
I was kind of hoping for a telnet config file where I can say that user billy can't telnet in.

I wouldn't mind using PAM if I knew more about it.

Short term solution: simple script in user's .profile. Ask the guys not to use telnet.

Long term solution: turn off telnet.

Longer term solution: research PAM. (oh and keep telnet off still).

Thanks for the help.

Steve

[J. Bravo · Accepted solution]

Hi, Steve!

Please, take a look at this document:

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en&docId=emr_na-c00843266-1

Regards;

J. Bravo.

[Steve Post]

YEP. That was it. That was exactly what I was looking for.