[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Chris Marget chris@marget.com
Fri, 10 Dec 2010 19:21:13 GMT
bryan@conserver.com wrote: > There's also a "limited" access type for restricting what users can do, which might help. It was added for a setup where a user logs into the conserver host and their shell is a script that invokes console with the appropriate console name. That could be a program that lets them chose their console too, if there are multiple. Luke, thank you for starting this thread. I apologize for the hijack. Bryan, thank you for mentioning the "limited" switch. Somehow I hadn't noticed it before. I'm headed down a similar road where I'd like to deploy a solution in which users telnet to the conserver host and find themselves connected to a serial console on a terminal server somewhere. Basically, the conserver host will be nothing more than a mux for several terminal server appliances. Each physical serial port appears on a different TCP port on the conserver box. Telnet because I can give the users a telnet URL that can be reasonably expected to work, and because I'm not concerned about securing the user's session. The users won't have shell access, and I don't want to require them to have anything beyond a standard telnet client. I'd been thinking about using inetd to start 'console'. ...Probably in a chroot jail, and probably with each bunch of consoles running under different user ids. iptables will make sure that customers can only connect to tcp ports associated with their devices. Is this sane? How can I improve on the plan? Thank you! /chris