woo@ornl.gov (John W. Wooten) (05/28/91)
Is there a way to set up workstations so that if a user types woo@woonext.dsrd.ornl.gov at login, the login procedure would open a telnet session to the machine described without every giving access to the physical machine he's standing in front of? I'm looking for a way to allow people to walk up to a workstation in someone else's office and (with their permission) allow them to access their own workstation without having to have an account opened or without letting them use a terminal window in another users open area. Has this been done? Is it doable? How?
verber@pacific.mps.ohio-state.edu (Mark Verber) (05/28/91)
> Is there a way to set up workstations so that if a user types > woo@woonext.dsrd.ornl.gov at login, the login procedure would open a > telnet session to the machine described. I'm looking for a way to > allow people to walk up to a workstation in someone else's office > allow them to access their own workstation without having to have an > account opened or without letting them use a terminal window in > another users open area. It is possible to do this if you hack login... I have seem this sort of function on DEC machine for an Internet<->DECnet gateway where you can login as node::user and it makes a connection for you to the remote machine. I don't know anyone who has done this for anything but protocol gateways though because it means that you are providing a way for people to access the Internet without any controls (like an uncontrolled Terminal server) which people could use to hide their identity when hacking machines. Within an orginization, the way many people handle this sort of thing is to have a global account authentication (served by YP/NIS, Hesiod, Apollo/Domain, etc) which does account validation accross the network. You rely on peer pressure (and when necessary threats) to keep people from abusing the prividge of using other people's workstations. --mark
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (05/28/91)
In article <1991May28.135719.13805@cs.utk.edu> woo@ornl.gov (John W. Wooten) writes: >Is there a way to set up workstations so that if a user types > woo@woonext.dsrd.ornl.gov at login, the login procedure would open a telnet >session to the machine described without every giving access to the physical >machine he's standing in front of? I'm looking for a way to allow people to >walk up to a workstation in someone else's office and (with their permission) >allow them to access their own workstation without having to have an account >opened or without letting them use a terminal window in another users open >area. Has this been done? Is it doable? How? Unless telnet has some weird shell escape command, this should be safe: Make a user id called "telnet" or whatever, giving it the login shell of "/usr/ucb/telnet". So, the user "loggs in" as telnet, and then gets a telnet> prompt. (Or rather, a "-telnet" prompt, since login execs the shell like that) He can do: "open woo@woonext.dsrd.ornl.gov", or any other hostname to be connected to, and execute any other normal telnet command. -Kartik -- internet% whoami subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
mwette@csi.jpl.nasa.gov (Matt Wette) (05/29/91)
Here what I can suggest if you're willing to use rlogin instead of telnet. You may be able to cook up something from it. Say the host machine is mach0 and the remote machine is mach1. In the /etc/passwd file on mach0 I put in the following entry: mach1::9999:999:remoteLogin:/usr/local:/usr/local/etc/rxlogin /usr/local has a .hushlogin file so that /etc/motd doesn't get printed. The file /usr/local/etc/rxlogin is the following: #!/bin/sh machine=$USER echo -n "$machine login: "; read username exec /usr/ucb/rlogin $machine -l $username Now I approach mach0 and type "mach1" at the login prompt, get a prompt for a login name on mach1 and type my name (matt), then get the password prompt from the remote machine. Here's what the screen should look like: login mach0: mach1 login mach1: matt Password: Matt -- _________________________________________________________________ Matthew R. Wette | Jet Propulsion Laboratory, 198-326 mwette@csi.jpl.nasa.gov | 4800 Oak Grove Dr, Pasadena,CA 91109 -----------------------------------------------------------------
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (05/29/91)
In article <1991May28.174505.10471@jato.jpl.nasa.gov> mwette@csi.jpl.nasa.gov (Matt Wette) writes: >Here what I can suggest if you're willing to use rlogin instead of >telnet. You may be able to cook up something from it. > >Say the host machine is mach0 and the remote machine is mach1. In >the /etc/passwd file on mach0 I put in the following entry: > > mach1::9999:999:remoteLogin:/usr/local:/usr/local/etc/rxlogin > >/usr/local has a .hushlogin file so that /etc/motd doesn't get >printed. The file /usr/local/etc/rxlogin is the following: > #!/bin/sh > machine=$USER > echo -n "$machine login: "; read username > exec /usr/ucb/rlogin $machine -l $username What's to stop the user from hitting a ^C or something in the middle of this shellscript? Of course, you could do a trap for every signal, but there's really no need for a kludgey shellscript as a login shell. Just make /usr/ucb/telnet the login shell; You don't need anything more than telling the user to type "open" before the host that he wants to connect to... -Kartik -- internet% whoami subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
yedidya@bimacs.BITNET (Yedidya Israel) (05/29/91)
In article <1991May28.174505.10471@jato.jpl.nasa.gov> mwette@csi.jpl.nasa.gov (Matt Wette) writes: >Here what I can suggest if you're willing to use rlogin instead of >telnet. You may be able to cook up something from it. > >Say the host machine is mach0 and the remote machine is mach1. In >the /etc/passwd file on mach0 I put in the following entry: > > mach1::9999:999:remoteLogin:/usr/local:/usr/local/etc/rxlogin > >/usr/local has a .hushlogin file so that /etc/motd doesn't get >printed. The file /usr/local/etc/rxlogin is the following: > #!/bin/sh > machine=$USER > echo -n "$machine login: "; read username > exec /usr/ucb/rlogin $machine -l $username An alternative is mach1::9999:999:remoteLogin:/usr/local:/usr/hosts/mach1 you are saving the scipt but must define "-mach1" as a nickname to "mach1" in hosts database. -- | Israel Yedidya, Math & CS Department, Bar-Ilan U, Ramat-Gan, ISRAEL. | +----------------------------------------------------------------------+ | Internet: yedidya@bimacs.cs.biu.ac.il Bitnet: yedidya@bimacs | | Uucp: ...!uunet!pucc.princeton.edu!bimacs!yedidya | \----------------------------------------------------------------------/ \--- If someone proves there is no God, I'll stop being religious ---/ --------------------------------------------------------------------
craig@attcan.UUCP (Craig Campbell) (05/29/91)
In article <1991May28.135719.13805@cs.utk.edu> woo@ornl.gov (John W. Wooten) writes: >Is there a way to set up workstations so that if a user types > woo@woonext.dsrd.ornl.gov at login, the login procedure would open a telnet >session to the machine described without every giving access to the physical >machine he's standing in front of? I'm looking for a way to allow people to >walk up to a workstation in someone else's office and (with their permission) >allow them to access their own workstation without having to have an account >opened or without letting them use a terminal window in another users open >area. Has this been done? Is it doable? How? Well, you could replace the /bin/login program with a filter program of your own. If the login name is in the form you describe above, then you could exec telnet or rlogin or some other appropriate program, with the proper parameters. You would aslo need to verify that unexpected input did not create a security breach, since at the point of time of the exec, your UID and GID could well be root or sys, or even undefined. If the login name was not of the special form, then pass the parameter(s) to the "real" (original) login program via another exec. Seems simple enough (in theory anyway). Just beware security breaches. craig
peter@ficc.ferranti.com (Peter da Silva) (06/26/91)
In article <1991May28.135719.13805@cs.utk.edu> woo@ornl.gov (John W. Wooten) writes: > Is there a way to set up workstations so that if a user types > woo@woonext.dsrd.ornl.gov at login, the login procedure would open a telnet > session to the machine described without every giving access to the physical > machine he's standing in front of? I'm looking for a way to allow people to > walk up to a workstation in someone else's office and (with their permission) > allow them to access their own workstation without having to have an account > opened or without letting them use a terminal window in another users open > area. Has this been done? Is it doable? How? Sure it's doable. Just set up an account called "telnet", then have a program that's run on login (preferably as the login shell) that asks for a remote system name and establishes a connection to it. We have an account on all our systems called "vt" that does this. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
wjb@cogsci.cog.jhu.edu (06/27/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >woo@ornl.gov (John W. Wooten) writes: >>Is there a way to set up workstations so that if a user types >>woo@woonext.dsrd.ornl.gov at login, the login procedure would open a telnet >>session to the machine described without every giving access to the physical >>machine he's standing in front of?... > >Sure it's doable. Just set up an account called "telnet", then have a program >that's run on login (preferably as the login shell) that asks for a remote >system name and establishes a connection to it. Yes, it is doable, but it isn't always advisible. Ferranti.com seems to only have MX records in the DNS and I don't know whether or not you publish your modem dialup numbers. You can therefore look at your network as a small closed system and not worry to much about people "cracking" your machines. Ornl.gov is ping'able on the Internet and setting up such an account there would allow someone trying to "crack" on the Internet to use their systems as a way to make it harder to track them down. Just imagine the difficulty of trying to determine the physical location of a cracker when they can place an unknown number of machines between their initial entry to the Internet and their current target. This can, of course, be made less useful to crackers by doing such things as having a password on the account, restricting the account to the console or direct wired terminal only (no network or modem access), and restricting the systems to which you can connect. Most sites on the Internet have placed restrictions on their TCP/IP terminal servers such that you can only access machines on the local network, to defend against this kind of activity. It would be nice if concerns about security never affected the services that are made available to users, but sometimes that just isn't possible. Bill Bogstad
peter@Sugar.NeoSoft.com (Peter da Silva) (06/28/91)
In article <26.Jun.91.180755.70@cogsci.cog.jhu.edu> wjb@cogsci.cog.jhu.edu writes: > Yes, it is doable, but it isn't always advisible. Ferranti.com > seems to only have MX records in the DNS and I don't know whether or not you > publish your modem dialup numbers. We don't. But more importantly we have a login front-end that looks at its environment and decides if a user is authorised to log in on a particular port. Thus, we only have a small number of people who can login on the modems. It'd be just as easy to disallow login as the remote login user from a remote login. After all, if you're already logging in over the network you don't need that capability, right? > It would be nice if concerns about security never affected the > services that are made available to users, but sometimes that just isn't > possible. I agree. But I don't think this is that sort of a case. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"