[aklug] Re: NetBSD on Cobalts

On Sun, 2010-09-05 at 07:53 -0800, Royce Williams wrote:
> Jim Gribbin said, on 09/04/2010 11:32 PM:
> >
> > On Sat, 2010-09-04 at 17:17 -0800, Royce Williams wrote:
> > Well, the recommendation is to login as user and su to root. Would
> > marking these insecure stop me from doing that? There was a long list of
> > ttys in /etc/ttys, how would I recognize the real ones?
>
> Nope, insecure has no effect on non-root users. I'm not as familiar
> with NetBSD, but usually, the type of TTY is in the prefix. On FreeBSD,
> ttyv* are virtual terminals (what I was colloquially calling "real" in
> that they are accessible physically), ttyd* are serial ports, ttyp* are
> pseudo-terminals (for SSH, etc.).
<snip>

What I have is:

console "/usr/libexec/getty Pc" vt100 on secure
constty "/usr/libexec/getty Pc" vt100 off secure
ttyE0 "/usr/libexec/getty Pc" vt220 off secure
ttyE1 "/usr/libexec/getty Pc" vt220 on secure
ttyE2 "/usr/libexec/getty Pc" vt220 on secure
ttyE3 "/usr/libexec/getty Pc" vt220 on secure
tty00 "/usr/libexec/getty std.9600" unknown off secure
tty01 "/usr/libexec/getty std.9600" unknown off secure
tty02 "/usr/libexec/getty std.9600" unknown off secure
tty03 "/usr/libexec/getty std.9600" unknown off secure
tty04 "/usr/libexec/getty std.9600" unknown off secure
tty05 "/usr/libexec/getty std.9600" unknown off secure
tty06 "/usr/libexec/getty std.9600" unknown off secure
tty07 "/usr/libexec/getty std.9600" unknown off secure

I am going to venture a guess that tty0* (the last 8) would be
considered "real" and a moot point on the Qube I'm working on as it has
no physical serial connections. From a practical standpoint anyway.

I'm thinking I can keep the first 6 and just delete the last 8. Mark
the remaining all "off", except the first. Mark them all "insecure".

I'm thinking this should let me login in remotely as a user. Then I
should be able to su to root.

Any serious problems with my train of thought yet?

Jim G

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sun Sep 5 16:23:42 2010