Telnet Auto Login
Serge Bromow
The systems I am using are SCO5.0.5 and
Linux RH7.1.
I am trying to telnet between systems without
the need to enter a logon/password pair.
I have looked at Tony's pages and SCO's
(oops Caldera) pages without success.
I have tried "telnet -a -l NAME" but I
am always asked for a password in SCO and
RedHat also asks for a Logon.
The user "NAME" exists on both machines and
share the same password.
What am I missing?
Advice appreciated
Serge
--
Posted from port-14.ottawa4.achilles.net [209.151.2.113]
via Mailgate.ORG Server - http://www.Mailgate.ORG
Brian K. White
"Serge Bromow" <se...@omensys.com> wrote in message
news:8aad59042bf9f13faff...@mygate.mailgate.org...
> Hi All,
>
> The systems I am using are SCO5.0.5 and
> Linux RH7.1.
>
> I am trying to telnet between systems without
> the need to enter a logon/password pair.
> I have looked at Tony's pages and SCO's
> (oops Caldera) pages without success.
>
> I have tried "telnet -a -l NAME" but I
> am always asked for a password in SCO and
> RedHat also asks for a Logon.
>
> The user "NAME" exists on both machines and
> share the same password.
>
> What am I missing?
try setting up user-equivalency and then using rlogin instead of telnet.
for user-equivalency:
make sure both boxes have a user account of the same name (like "root"
already exists on both)
make sure both hosts have hostnames, if necessary just invent names and
define in /etc/hosts, then put the names in /etc/hosts.equiv and ~/.rhosts,
then rlogin other-host.
on boxa and boxb edit the following files...
/etc/hosts:
127.0.0.1 localhost
10.0.0.200 boxa
10.0.0.202 boxb
/etc/hosts.equiv
localhost
boxa
boxb
~/.rhosts (do this for each user who needs it)
localhost
boxa
boxb
also chmod 600 ~/.rhosts
then to login from boxa to boxb without a password, login to boxa as one of
the users who has a .rhosts on boxb, then:
rlogin boxb
this works between a sco box and a linux box too and probably any unix.
you might need to verify that rlogin is present in /etc/inetd.conf of the
box you are logging in to before it works. It comes setup and enabled out of
the box, but some security-conscious admin or consultant may have disabled
it at some point.
as far as I can tell from the docs, you're not supposed to need both .rhosts
and /etc/hosts.equiv. .rhosts applies to a user, hosts.equiv applies to all
users, but so far I always need .rhosts in order for it to work. this is a
gaping crater of a security hole so I don't set it up very often.
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Bill Vermillion
Brian K. White <br...@aljex.com> wrote:
>as far as I can tell from the docs, you're not supposed to need
>both .rhosts and /etc/hosts.equiv. .rhosts applies to a user,
>hosts.equiv applies to all users, but so far I always need .rhosts
>in order for it to work. this is a gaping crater of a security hole
>so I don't set it up very often.
You always have to watch out any time you use the word 'all',
particularly when used in conjunctions with comptuers as
in "all users" above.
In at least one system I've used in the past I've seen
doucmentation that indicates that for root only .rhosts is used.
This prevents a cracking of a remote system from compromosing root
on other systems.
The closest I can see here is for the ruserok() used by rcmd
----
The iruserok() and ruserok() functions take a remote host's IP
address or name, as returned by the gethostbyname(3) routines,
two user names and a flag indicating whether the local user's
name is that of the super-user. Then, if the user is NOT the
super-user, it checks the /etc/hosts.equiv file. If that lookup
is not done, or is unsuccessful, the .rhosts in the local
user's home directory is checked to see if the request for
service is allowed.
--
Bill Vermillion - bv @ wjv . com
Matt Schalit
There's a bit more to user equivalence then you mentioned.
If you fail to take into account the other aspects, your
users aren't equivalent. Symptoms of this would be the "r"
commands like rlogin, and rdist not working as you'd
expect.
I wrote it up in the Uw7 FAQ,
--------------------------------------------------------------
2.5 What is User Equivalence and why is it important?
18 Sept 1999
----------------------------------------
User equivalence exists on a network when the following
occurs on _all_ computers on that network:
a given user has the same username, UID, and password
a given user belongs to the same groups
a given group has the same GID
This enables all users to have transparent access no matter
what terminal they sit down at. It also enables users to
utilize commands such as 'rlogin.'
----------------------------------------------------------------
I didn't include any discussion of how to set up rhosts and
host.equiv, which are needed for the 'r' commands, but I trust
that you gave it the old college try :)
Matt
Brian K. White
"Bill Vermillion" <bi...@wjv.com> wrote in message
news:GKJ32...@wjv.com...
Nice.
That sure explains it, since I usually only set this up for root to do rsync
backups from cron, from a "new" to an "old" server.
Bill Vermillion
>Nice.
Ah - different philosophies here. When I move files via cron
from one system to another - quite often an scp - I never use
root but deposit the file to be moved into a special user I created
which also exists on the other machine.
To me having transfers by cron in a root mode could be a suprise.
If a person managed to break one machine then this could give them
access to more than one.
I can't move from one machine to another as root on any I take care
of. Any root access is done in real time after an su to the account.
Maybe I'm more paranoid than most, but in this day and age you
can't be too careful.
Bill Vermillion
Matt Schalit <msch...@pacbell.net> wrote:
>On Mon, 01 Oct 2001 08:27:12 GMT, "Brian K. White" <br...@aljex.com> wrote:
>>try setting up user-equivalency and then using rlogin instead of telnet.
>>
>>for user-equivalency:
>>make sure both boxes have a user account of the same name (like "root"
>>already exists on both)
>>make sure both hosts have hostnames, if necessary just invent names and
>>define in /etc/hosts, then put the names in /etc/hosts.equiv and ~/.rhosts,
>>then rlogin other-host.
>>on boxa and boxb edit the following files...
[stuff deleted]
>>as far as I can tell from the docs, you're not supposed to need both .rhosts
>>and /etc/hosts.equiv. .rhosts applies to a user, hosts.equiv applies to all
>>users, but so far I always need .rhosts in order for it to work. this is a
>>gaping crater of a security hole so I don't set it up very often.
>
>There's a bit more to user equivalence then you mentioned.
>If you fail to take into account the other aspects, your
>users aren't equivalent. Symptoms of this would be the "r"
>commands like rlogin, and rdist not working as you'd
>expect.
>
>I wrote it up in the Uw7 FAQ,
>
>--------------------------------------------------------------
> 2.5 What is User Equivalence and why is it important?
> 18 Sept 1999
> ----------------------------------------
> User equivalence exists on a network when the following
> occurs on _all_ computers on that network:
>
> a given user has the same username, UID, and password
> a given user belongs to the same groups
> a given group has the same GID
>
> This enables all users to have transparent access no matter
> what terminal they sit down at. It also enables users to
> utilize commands such as 'rlogin.'
That might explain a strange occurance I had once. As root on my
machine I telneted to the nameserver of a small local ISP so that
I could see the display and find out which OS and version they had
changed to. [I always turn the display from telnet off]
I was logged in directly - no user name prompt - no password.
Just staring at a # on my screen and pwd show / and ls show
a listing of the root directory.
Two different OS'es both SysV based - and they matched
in user names - as all systems have root, matched in user ID
as all system use ID 0 for root, same group and same group ID.
The only think that woudlnt' match is the password.
So someone screwed somthing up. Having all the use equivalences
in so many systems match root - except for password - would be
a good reason to be extremely careful.
Spooky.
Matt Schalit
>In article <3bb8a307...@news.sf.sbcglobal.net>,
>Matt Schalit <msch...@pacbell.net> wrote:
>>On Mon, 01 Oct 2001 08:27:12 GMT, "Brian K. White" <br...@aljex.com> wrote:
[...snipage]
>Two different OS'es both SysV based - and they matched
>in user names - as all systems have root, matched in user ID
>as all system use ID 0 for root, same group and same group ID.
>The only think that woudlnt' match is the password.
>
>So someone screwed somthing up. Having all the use equivalences
>in so many systems match root - except for password - would be
>a good reason to be extremely careful.
>
>Spooky.
>
>--
>Bill Vermillion - bv @ wjv . com
I think that way, pretty much. Root is an abused account,
traditionally the easiest way to get around some security
I don't understand and feel I have too little time to analyze.
It's only later that I find those issues are fundamental.
So once I was tackling the issue of root's account and
root's groups. On Uw7, root belongs to 14 groups:
gid=3(sys) groups=2(bin),4(adm),5(uucp),6(mail),7(tty),
8(audit),10(nuucp),12(daemon),23(cron),
25(dtadmin),47(priv),9(lp)
But I wanted root to belong to some other group I was
creating, so I tried to add them. Bang - I hit a group
limit. Seems like you can't just add more groups to root's
account. I think the limit was 16.
I couldn't raise it. I think I tried and tuned it
into the kernel, but root's account still wouldn't
accept more than 16 groups.
And because root can get into any file regardless,
I just left it at that.
So my point, I guess, is that on Uw7, root equivalence
is built in by default, and hard to break. All those
groups and gid's get set during install.
Regards,
Matt
Bill Vermillion
Matt Schalit <msch...@pacbell.net> wrote:
>On Mon, 1 Oct 2001 22:06:30 GMT, bi...@wjv.com (Bill Vermillion) wrote:
>
>>In article <3bb8a307...@news.sf.sbcglobal.net>,
>>Matt Schalit <msch...@pacbell.net> wrote:
>>>On Mon, 01 Oct 2001 08:27:12 GMT, "Brian K. White" <br...@aljex.com> wrote:
>
>[...snipage]
>>Two different OS'es both SysV based - and they matched
>>in user names - as all systems have root, matched in user ID
>>as all system use ID 0 for root, same group and same group ID.
>>The only think that woudlnt' match is the password.
>>
>>So someone screwed somthing up. Having all the use equivalences
>>in so many systems match root - except for password - would be
>>a good reason to be extremely careful.
>I think that way, pretty much. Root is an abused account,
>traditionally the easiest way to get around some security
>I don't understand and feel I have too little time to analyze.
>It's only later that I find those issues are fundamental.
'root is an abused account' is a classic understatement.
>So once I was tackling the issue of root's account and
>root's groups. On Uw7, root belongs to 14 groups:
> gid=3(sys) groups=2(bin),4(adm),5(uucp),6(mail),7(tty),
> 8(audit),10(nuucp),12(daemon),23(cron),
> 25(dtadmin),47(priv),9(lp)
>But I wanted root to belong to some other group I was
>creating, so I tried to add them. Bang - I hit a group
>limit. Seems like you can't just add more groups to root's
>account. I think the limit was 16.
>I couldn't raise it. I think I tried and tuned it
>into the kernel, but root's account still wouldn't
>accept more than 16 groups.
I would hope that would get fixed someday. It's been around a long
time and it's not limited to SCO as I ran into on a V.3 before SCO
moved that way.
I recall the way around that is just to define another group name
so that the other names have the same GID. It has been awhile.
I'm admining a growing number of FreeBSD servers - local and
remotely - and I've grown to like it's handling which is different
than Sys V based systems. There you can NOT su to root even if you
have the password unless you are in the 'wheel' group [GID 0 - just
a different name]. That's a default mode and you can restrict
access in more secure Sys V modes but it's not that way by default.
Perhaps it will become standard as more and more systems
interconnect.
>And because root can get into any file regardless,
>I just left it at that.
>So my point, I guess, is that on Uw7, root equivalence
>is built in by default, and hard to break. All those
>groups and gid's get set during install.
UW7 was a major step forward [even UW2 but the interfaces from the
AT&T heritage were so crude compared to the smoothness of SCO's
adminstration system]. For the OSR5 users who complain about UW7
they should have to live with UW 1.x for awhile :-)
Bill
Serge Bromow
I followed your suggestions and I am able to
auto rlogin to the Linux box from SCO, but from the Linux
box I am still required to enter a password.
May be something in Linux. I will hunt down the problem.
This brings me back to my original post.
My intention (wich I failed to mention)
was to have a number of Linux machines auto logon onto the
OSR server and start an X-Application. It appears the rlogin does not
support X-sessions across its interface.
A) If this is true is there a way to auto logon through telnet,
B) enable X-sessions over rlogin.
Thanks
Serge
--
Posted from port-24.ottawa2.achilles.net [209.151.2.31]
Serge Bromow
news:3bb8a307...@news.sf.sbcglobal.net...
> User equivalence exists on a network when the following
> occurs on _all_ computers on that network:
>
> a given user has the same username, UID, and password
> a given user belongs to the same groups
> a given group has the same GID
>
> This enables all users to have transparent access no matter
> what terminal they sit down at. It also enables users to
> utilize commands such as 'rlogin.'
> ----------------------------------------------------------------
This may be part of my problem.
Since I am talking between SCO & Linux
the UID & GID are unlikely to be the same
for an equiv user name and password.
SCO accounts start and 200:50, while I have
seen a variety of start uids and gids in Linux.
(500:100, 1000:100)
Is there a way around this problem other than changing
the the Linux uid:gid defaults?
Serge
--
Posted from port-36.ottawa2.achilles.net [209.151.2.43]
James R. Sullivan
Serge Bromow wrote:
>
> "Matt Schalit" <msch...@pacbell.net> wrote in message
> news:3bb8a307...@news.sf.sbcglobal.net...
>
> > User equivalence exists on a network when the following
> > occurs on _all_ computers on that network:
> >
> > a given user has the same username, UID, and password
> > a given user belongs to the same groups
> > a given group has the same GID
> >
> > This enables all users to have transparent access no matter
> > what terminal they sit down at. It also enables users to
> > utilize commands such as 'rlogin.'
> > ----------------------------------------------------------------
>
> This may be part of my problem.
> Since I am talking between SCO & Linux
> the UID & GID are unlikely to be the same
> for an equiv user name and password.
Don't think the user's uid/gid matter. Make sure you have
both the short machine name and the FQDN in the .rhosts file.
For instance, coming from a SUN machine (carmel.sclab.tarantella.com)
to a OSR5 machine (jupiter.beyond.tarantella.com), the .rhost file:
carmel
carmel.sclab.tarantella.com
works (no password prompt), while an .rhost file with just "carmel"
doesn't. I've always included both forms of machine names in my
.rhost files, cause sometimes you need them :-)
oh, my uid/gid on the two systems is completely different.
--
Jim Sullivan
Director, North American System Engineers
Tarantella! http://www.tarantella.com
831 427 7384 - j...@tarantella.com
Brian K. White
> Thanks Brian,
>
> I followed your suggestions and I am able to
> auto rlogin to the Linux box from SCO, but from the Linux
> box I am still required to enter a password.
>
> May be something in Linux. I will hunt down the problem.
>
> This brings me back to my original post.
> My intention (wich I failed to mention)
> was to have a number of Linux machines auto logon onto the
> OSR server and start an X-Application. It appears the rlogin does not
> support X-sessions across its interface.
rlogin/telnet has nothing to do with X
start X on the linux box
tell X to accept connections with "xhosts +" (this allows connections from
anywhere, but you can tell xhosts to only accept from the unix box instead)
rlogin to the unix box
in the rlogin session, see if $DISPLAY is set, maybe rlogin doesn't set it
for you. if echo $DISPLAY shows nothing, then do a set DISPLAY=<linux box>:0
; export DISPLAY
then start your X program. the x session does not use rlogin or telnet at
all, other than that is how you get to start the program on the other
system, but it's not necessarily the only way. you could put a job in cron
and not have any kind of login, so long as DISPLAY is set to the linuxbox
ip:0 and the linux box x server is up & running and set to allow connections
from the unix box, it will start up and display itself on the linux box.
you could write a script on the unix box that sets DISPLAY and runs the app,
and on linux you could configure a menu entry in the linux window manager to
use rcmd to run the script on the unix box without actually logging in to
the unix box.
(that's how I would do this actually)
note rcmd (remote command) is called rsh or rexec on linux, I forget which)
...mmm I see it's kind of either/both
the command to run on linux would be simply
rsh unixbox script
where "unixbox" is the hostname of the unix box as listed in .rhosts
and "script" is a script on the unix box that looks like:
#!/bin/sh
DISPLAY=linuxbox:0
/usr/bin/X11/scohelp (just as an example)
prefferably in the users home directory, since the display is hard-coded
actually that's a bad choice of example program, since it tries to use
colors that are not defined in the linux rgb.txt, but, that can be fixed by
adding this to the bottom of /usr/X11R6/lib/X11/rgb.txt
!
! Special rgb.txt entries for SCO OSR 5.0.5 gui administration utilities
!
0 0 0 scoForeground
210 70 70 scoHighlight
220 220 220 scoTopShadow
180 180 190 scoBackground
200 200 210 scoActiveBackground
0 0 64 scoActiveForeground
230 230 230 scoActiveTopShadow
190 210 190 scoAltBackground
I just verified, rsh does not propogate environment variables like DISPLAY,
so you would need to put it in the script like I showed.
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Serge Bromow
news:1oKu7.31596$c8.46...@news1.rdc1.nj.home.com...
>
> "Serge Bromow" <se...@omensys.com> wrote in message
> news:32814c10676910f9ec7...@mygate.mailgate.org...
Thanks Brian.
Setting the DISPLAY variable did the trick.
As you suggested, a small script to init the
variable and launch the appplication got the
system up and running.
Serge
--
Posted from port-14.ottawa2.achilles.net [209.151.2.21]
Serge Bromow
news:3BBB2F3E...@tarantella.com...
> Jim Sullivan
> Director, North American System Engineers
> Tarantella! http://www.tarantella.com
> 831 427 7384 - j...@tarantella.com
Thanks Jim
Setting the .rhosts and hosts.equiv to include
all variants of host and domain name i.e;
Allowed the Linux beast to auto rlogin.
Who would have thunk!
Serge
--
Posted from port-14.ottawa2.achilles.net [209.151.2.21]
Brian K. White
> "Brian K. White" <br...@aljex.com> wrote in message
> news:1oKu7.31596$c8.46...@news1.rdc1.nj.home.com...
>
> >
> > "Serge Bromow" <se...@omensys.com> wrote in message
> > news:32814c10676910f9ec7...@mygate.mailgate.org...
>
> Thanks Brian.
>
> Setting the DISPLAY variable did the trick.
> As you suggested, a small script to init the
> variable and launch the appplication got the
> system up and running.
>
> Serge
I just thought of a better script to put on the unix box than the one I
posted before.
on the unix box, in some public path like /usr/local/bin:
vi /usr/local/bin/xrsh
#!/bin/sh
DISPLAY="$1" ; export DISPLAY ; shift
exec "$@"
on the linux box in the window manager, configure a button with this
command:
rsh unixbox xrsh thislinuxbox:0 yourapp -opt -opt -opt...
example: how about a sco utils menu...
unix box hostname is gillespe, and this goes in the window manager on the
linux box named phlebotomy:
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/scoterm
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/xterm
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/scohelp
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/scoadmin
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/scopaint
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/scoedit
this way,
* you only have one single script on the unix box
* it can be used by all the linux boxes at once
* and it can be used to run any program on the unix box.
* you can install the same script on more/other unix boxes without changing
it every time.
you could even define something like this command in your linux box
~/.xinitrc and start up X with the SCO desktop instead of the linux desktop.
(this might not be exactly correct, as I can't test it this minute, but I
have done this before, manually. using rsh and sticking it right in .xinitrc
is just another twist on something that I do know works.
rsh gillespe /usr/local/bin/xrsh phlebotomy:0 /usr/bin/X11/xdt3
Another favorite tool of mine for displaying remote sco x destops and apps
on local linux boxes is xnest.
I happen to have a linux box, with X installed for a nat router for my
office. if I need to run internet configuration manager on some customers
sco box, I start xnest on the router with it's display set to the linux box
at my desk. I then start scoadmin on the remote sco box with *it's* display
set for the xnest that is running on my router. End result, I have a window
on my regular linux x desktop, and in that window is a full sco desktop, or
a blank X background and some bare x apps running on the remote sco box.
too cool
Serge Bromow
> too cool
>
That is cool! Good general solution
to my problem. I was working on the
Linux side today so the machine boots
and Log's into the SCO box and presents
my xapp without human intervention.
This is great solution for the SCO side.
Thanks a lot Brian,
Regards
Serge
--
Posted from port-28.ottawa4.achilles.net [209.151.2.127]