Very Computer

After re-building a server,
I can no longer rlogin as root.

I get the message in the subject line.

Seems the cure used to be in the inittab file but
running Solaris 2.6 now.

Any tips greatly appreciated.

vi /etc/default/login
comment out
CONSOLE=/dev/console

From /etc/login:

# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
CONSOLE=/dev/console

See also man login.

Charles

--

Charles Soto - Austin, TX *** REMOVE "_ihatespam" from email address!
[insert annoyingly large ASCII art .sig here, and please, god, oh
please put an end to HTML in email and multi-part MIME!]

"man login" should put you on the right track. You might also check
/etc/default/login. Details escape me, but I see no reason to do your
research for you, when the resources you need areon your machine
waiting. The man pages are your friend.

In /etc/default/login, find the line

CONSOLE=/dev/console

and comment it out

#CONSOLE=/dev/console

Jay

uuhhh....  but why?

maybe i don't understand the nature of the question since
my service provider rolls over news groups much too quickly
and i didn't see the original post.

essentially, by allowing root logins directly without being
on the system console or being some other validated user, you
really leave your system open to attacks.  if you're going to
kick the 'security door' wide open then this is one of the
best ways to do it.  especially (primarily?) if you're going
to hit the system as root across the bigger Internet.

if you insist on allowing root logins from anywhere then i
would strongly suggest the use of the ssh.  at least that way
your root password doesn't transit the net 'in the clear'.
at any rate, i don't find logging in on my user account and
the su'ing to root that inconvenient.  in fact, i *never* log
in as root (other than in system maintainance mode) directly.
think about what you're doing and for what reason - is it just
plain laziness?  if so, you'll probably get what you ask for.

just a word of caution.
be careful,
dp

Because no matter how much you tell them not to do it some people still want
to shoot themselves in the foot.  The original poster asked a question, the
second poster answered it.  Is actually making the change stupid, yes but
not matter how many times the reason for the security restriction is
explained some people still insist on doing it.  Same as some users still
insist on editing /etc/passwd by hand and changing the root shell.  People
just get tired of telling them why not to do it.

That doesn't work too well if root is in /etc/ftpusers

Quote:>if someone has the root password, then /etc/default/login is NOT gonna
>stop him (her).

If root is also in /etc/ftpusers and the system is otherwise properly
secured, including physically, the system will be significantly safer.

Note: Newsgroups seriously trimmed - I believe this is Solaris (and/or
SunOS) specific, as at least several other versions of Unix don't have
the same type of /etc/default/login mechanism - although many of them
have other, often similar ways, to implement effectively the same thing.

--

No but emacs does at least notice that the file has changed on disk, and
question if you want to save your version.

Adam

PS: No I do not want an editor war, the correct way to change password files
is to make the PFY do it.

Password changes are reflected in the /etc/shadow file, not the /etc/passwd
file.  A user would have to change their login shell (which is often
disallowed)
or something like that to trigger a change to the /etc/passwd file.

Quote:>Whatever the odds, why run the risk at all, when use of proper utilities
>to change password files will reduce the risk of colliding writes to
>approaching zero in any case?

Or copy the original passwd file off, make the changes to the bottom of the
file and save it.  That way, if you've screwed up something it's at the
bottom
and you can still get into the system as root.

Quote:>> If someone is  so concerned over syntax checking and typos in their
passwd file,
>> you may want to
>> purchase Microsoft products instead of UNIX.

>I'm not entirely sure what you mean by this.  Assuming the Unix machine
>is actually doing real work, and supporting a community of real users, I
>would submit that *any* system operator should be "so concerned" about
>the state of their password file!

That's true -- the passwd & shadow files are extremely important in
production systems.

Quote:>Personally I don't care if my password file is completely hosed - I'm
>the only user on the machine on my desktop, I can easily boot from a
>network to repair it if I do hose it, most user information lives in
>NIS+ tables round here anyway, and at the worst I can always find a
>spare machine to use since my home directory lives on the network.

>The situation might well be different if the machine in question was a
>server supplying CPU to several hundred users, with no network booting
>available, no chance of downtime due to the thousands of dollars a
>minute lost by the business if the machine is down and no way to get
>into the machine as root because someone hamfisted hosed the password
>file.

That's why you save a copy of your passwd file.  And back it up.  And apply
your edits only to the end.  And probably give yourself another way to get
in as root (rsh, ssh, etc.).

In a well-run production environment, you'd undoubtedly have even more
safeguards.
You probably have a global passwd file anyway -- periodically pushed out via
rdist or
NIS or Tivoli or ...  You keep that passwd file on a machine where it can be
tested
before it's pushed out.

I think the biggest reason to hand-edit the passwd file is that it works on
Solaris, Linux, HP-UX, etc.  Otherwise, you have to remember the syntax
& flags on how to add users on each platform in your business.

Spike

It really doesn't matter whether you comment out the console entry in
/etc/default/login or not.  If I know the root password, it's simple
to log on as root:
1. ftp to the box, cd to /etc/default, get the login file.
2. locally comment out the line.  put the file back.
3. telnet in as root.
4. vi /etc/default/login (to put things back like they were)
5. do whatever else you need to do as root.

Bottom line:
if someone has the root password, then /etc/default/login is NOT gonna
stop him (her).

regards,
Dave

Quote:

>uuhhh....  but why?

>maybe i don't understand the nature of the question since
>my service provider rolls over news groups much too quickly
>and i didn't see the original post.

>essentially, by allowing root logins directly without being
>on the system console or being some other validated user, you
>really leave your system open to attacks.  if you're going to
>kick the 'security door' wide open then this is one of the
>best ways to do it.  especially (primarily?) if you're going
>to hit the system as root across the bigger Internet.

>if you insist on allowing root logins from anywhere then i
>would strongly suggest the use of the ssh.  at least that way
>your root password doesn't transit the net 'in the clear'.
>at any rate, i don't find logging in on my user account and
>the su'ing to root that inconvenient.  in fact, i *never* log
>in as root (other than in system maintainance mode) directly.
>think about what you're doing and for what reason - is it just
>plain laziness?  if so, you'll probably get what you ask for.

>just a word of caution.
>be careful,
>dp

+-----------------------------+----------------+


+-----------------------------+----------------+

If security is in any way a concern then don't let root use ftp.
Hope this helps
Adam

Hi!

On Mon, 17 May 1999 08:09:20 -0400,

uuhhh.... why not editing /etc/passwd by hand?
This is what I always do. I just cannot remember if it's "useradd", or
"adduser" or "addUserAccount" or whatever on a certain flavour of Unix
when I want to add a user. Isn't editing /etc/passwd by hand more consistent?
(Perhaps I am making a fool out of myself now, but I've never read I shouldn't
do this anywhere.)

              Kai.

Kai wrote

uuhhh.... why not editing /etc/passwd by hand?
This is what I always do. I just cannot remember if it's "useradd", or
"adduser" or "addUserAccount" or whatever on a certain flavour of Unix when
I want to add a
user. Isn't editing /etc/passwd by hand more consistent? (Perhaps I am
making a fool out of myself now, but I've never read I shouldn't do this
anywhere.)

Kai.

On some variants of 5.4.2 you can do what you like in the passwd file
andnothing happens until the next reboot or until you run the creatiadb
program, as passwd and shadow
info is held in the /etc/security/tcb master and index files, if you are
going to change things by hand then ,mae sure you do not leave yourself with
a duff passwd file!

Veltror

**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****

"Consistent" isn't necessarily the word I would have chosen - perhaps
"risky" might be nearer the mark.  If you aren't bothered about
potentially losing password changes and/or completely screwing up your
password file, then yes, hand editing is fine.

Potential problems (replacing "vi" with just about any hand editor, by
the way):

1) vi doesn't lock the password file.  Consider the following scenario:

        root does "vi /etc/passwd"

                a user somewhere on the system changes their password using
                "passwd"

        root completes their changes and hits :wq

the user's changes will have been lost, since root has just overwritten
the
changed version of /etc/passwd with the version read in by vi before the
changes.

Even more interesting results will be obtained if the rewrite from
root's "vi" actually coincides with the rewrite from the user's "passwd"
invocation.  At the worst the passwd file will be completely scrambled.

2) vi doesn't do any syntax or consistency checking. If you happen to
make a typo (one too many colons in a passwd file entry, for example),
nothing will pick it up until it's found that people can't log in.

I'd say you should at least use /usr/ucb/vipw instead of vi as vipw does
some syntax checking (it won't allow a garbled root passwd entry, for
example) and tries to lock the password file on entry to the editor.
Following a hand edit of the password file it's also a very good idea to
run pwck to check whether the file has been garbled.  Do this BEFORE
exiting the root shell (as you might have problems su-ing to fix any
problems if the password file has, in fact, been damaged.  

Preferably, however, you should use a utility that locks the password
file (and takes account of any locks that are already active on it),
syntax checks the password and shadow files, keeps passwd and shadow in
sync automatically, and checks consistency with other things such as
groups entries, existence of home directories, etc.  The password file
is too important to take risks with, IMHO.

Regards

--
Tony

This posting is my own opinion and does not necessarily coincide with
the policy of Sun Microsystems.  It does not constitute official support
from Sun Microsystems