[TAG] lpr works for user not root in Basiclinux 2.1

[Sindi Keesan]

On Thu, 1 Mar 2007, Ben Okopnik wrote:
>>>>
>>>> My remaining problem is that ssh is working on one computer

but was not on three others.

>It was a permissions problem.
rxvt needed ttyp* and ptyp*.
ssh needed tty.

I made all the tty's rw for other, root tty.  Is this okay?

> The 'root' account is *made* to operate with literally no security
> restrictions. Have you not heard what all of us here have been telling
> you? This is precisely why it's so dangerous.

Root was ssh'ing with known_hosts and password.

> Since I have no idea what the configuration for the other user is, I
> can't tell you why it works: you've only shown me these two log reports.

Wrong permissions for accessing tty.
Do you want to explain what ssh does with tty?

>
>> My neighbor's Fedora installation, when I typed set from an xterm (we were
>> looking for the path when his realplayer.bin file would not run, because
>> it was in /root/Desktop), listed the location of ssh-askpass, which I do
>> not have.  Root on my system can ssh without it. The above looks like a
>> default for some other linux.  Does ssh-askpass contain the password?

Not needed here once I got permissions correct.

>

I will study your explanation of 'how things work'.

>> Here is the output for ssh -v keesan at xxxx.org as root.
>>
>> debug1: identity file /root/.ssh/identity type -1
>> debug1: identity file /root/.ssh/id_rsa type -1
>> debug1: identity file /root/.ssh/id_dsa type -1
>
> This would be part of the problem. It says that it's not finding any of
> the above private keys in /root/.ssh - so, no key-based authentication
> for you!

Not needed, uses interactive keyboard password entry.

>
>> debug1: Host 'xxxx.org' is known and matches the RSA host key.
>> debug1: Found key in /root/.ssh/known_hosts:6
>> debug1: bits set: 1037/2048
>> debug1: ssh_rsa_verify: signature correct
>
> This _identifies_ the remote host as a known one, but there's still no
> authentication.

I also had to get the owner and group correct for 
/home/user/.ssh/known-hosts (after copying from /root/.ssh).
The computers set different bits, probably each time I connect.

>
>> debug1: authentications that can continue:
>> publickey,password,keyboard-interactive
>> debug1: next auth method to try is publickey
>
> First thing it'll try is the 'key_auth' method...
>
>> debug1: try privkey: /root/.ssh/identity
>> debug1: try privkey: /root/.ssh/id_rsa
>> debug1: try privkey: /root/.ssh/id_dsa
>
> ...which failed, since the private key files don't exist.

But I could generate them with puttygen if needed.

>> debug1: next auth method to try is keyboard-interactive
>> debug1: authentications that can continue:
>> publickey,password,keyboard-interactive
>> debug1: next auth method to try is password
>> debug1: ssh-userauth2 successful: method password
>
> And here is the auth method that succeeds: kb-interactive (i.e., you
> typed in the password) and system password auth based on that.

It required user access to tty to do that.


>> debug1: fd 7 setting O_NONBLOCK
>> debug1: channel 0: new [client-session]
>> debug1: send channel open 0
>> debug1: Entering interactive session.
>> (and much more)
>>
>> Root connects, without using id_dsa.  It asks me for my password and I
>> give it and connect.  It does not ask user for password, on this computer.
>> It does on one other computer.  Maybe I got permissions correct on some
>> file there?.
>
> It's not about permissions. It's about missing necessary parts of the
> package.

It was wrong permissions in this case.   The keyboard-interactive part 
works now for 'user'.  The error message was about permission.

>> I used strace when realplayer would not install on most of my computers
>> but could not figure out the output.
>
> Hint: a non-broken distro will include 'man strace'.
I don't understand the vocab and syntax of most man pages.  My list 
members suggested it but nobody figured out what went wrong.  Again,
something worked on only one computer. Mplayer is better anyway.

>
> The fact that your neighbor doesn't know anything about Linux - and
> having multiple copies of uninstalled binaries sitting on his "desktop",
> as well as not knowing how to tell if a program is installed argues for
> a deep level of ignorance - implies absolutely nothing about small or
> large distros.
>
> To continue the car analogy, what you're doing is equivalent to grabbing
> a random hunk of metal out of a junkyard full of old trucks, trying to
> fit it to a stripped race-car frame, and trying to see if you can run
> the resulting gadget at a hundred miles an hour - all before installing
> the brakes, and without any knowledge of mechanics. What all of us have
> been telling you to do is to use an *existing* car, and carefully remove
> the parts that you decide you don't need (at least the brakes are
> guaranteed to be there, and you'll *know* that you removed them if you
> decide to do so.)
>

I don't drive, I bike ;=)  It gets me places at the speed I want, seeing 
much more along the way and meeting nice people, and without wasting 
resources. Our bikes are put together out of parts from abandoned ones. 
We know how they work and how to maintain them.


I would have no idea what parts could be safely removed off anything as 
large and unwieldy as a car.  I know what most of the bike parts do.  We 
might spend more time working on our bikes than the average car owner does 
on a car, but we enjoy it.  And we don't spend time making money to buy 
the car, insure, or feed it.  Bikes start instantly without warmup and 
work in all temperatures. They exercise body and mind.  (I do avoid ice).

The author of our distribution also bikes and does not drive.  It attracts 
the do-it-yourselfers.

I think with your help I either have everything working for user, or have 
a better idea how to attack it by changing permissions and making sure 
things are on the path.  I would not have learned this from Fedora.

> -- 
> * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
>

Sindi Keesan