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

[Sindi Keesan]

On Wed, 28 Feb 2007, Ben Okopnik wrote:

> On Wed, Feb 28, 2007 at 06:39:34PM -0500, Sindi Keesan wrote:
>>
>> My remaining problem is that ssh is working on one computer (with a
>> standard hardware modem) but not on the two with internal lucent modems
>> (where pppd for some reason is accessing ttyS1 and also ttyLT0).
>
> SSH is an application; it doesn't (can't) care about the kind of
> hardware you use for networking.

It is not working on another computer with hardware modem.

>> Host key verification failed if I ssh without the login.
>
> Quick guide to SSH "key auth" configuration, assuming "host1" as your
> computer, "host2" as the remote machine, and "keesan" as the name of the
> user on both hosts:
>
> 1) Create the public/private keypair on host1 by running "ssh-keygen -t dsa".

I compiled a putty version puttygen and will try it later.  It is on a 
computer at another location. Root does not seem to use this method.

> 2) Copy the *public* key (the contents of /home/keesan/.ssh/id_dsa.pub)
> from host1 into /home/keesan/.ssh/authorized_keys on host2.

Will try this later.  Maybe there is some easier method.
Below are the log files.

I managed to copy the verbose output to a file.  I don't have gpm 
installed here.  splitvt says it needs VT100 (when run as user) and 
screen complained about no PTTYs (which I think is related to the rxvt 
problem).

What I did was make two xterms (as user) and then edit my alias for using 
Xvesa to add -2button (rather than using the standard X server, which says 
not to run it as SUID, whereas Xvesa says to run it SUID), and use the 
right button to copy and both buttons to paste.  I normally use X only for 
Opera and xpdf.

I uploaded ssh.log (to my shell account at the bbs where I am getting TAG 
mail) via kermit because various permissions are broken at the bbs I am 
using for mail since the volunteer staff did an emergency disk removal 
(ftp appears to be dead even for root, which could be why psftp won't 
work for user today).  Here it is for 'user':


---------------------------------
ssh keesan at xxxx.org -v produces:


OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
ssh: ssh: unknown host


Why it is an unknown host for user but not for root?

ssh www.xxxx.org produces:


OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to www.xxxx.org [216.86.77.194] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 124/256
debug1: bits set: 1030/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
ssh_askpass: exec(/opt/diet/libexec/ssh-askpass): No such file or
directory
debug1: Calling cleanup 0x805deb0(0x0)
Host key verification failed.
debug1: Calling cleanup 0x805deb0(0x0)

---------------------------------

ssh as root works without ssh-askpass, and as user on one computer.

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?
I enter it manually.  I have several logins and paswords.

> 3) Execute "ssh keesan at host2" on host1 to log into host2.
>
> If you suspect that you messed up anywhere along the way, wipe out all
> the files in ~/.ssh on both machines and restart from scratch.

I have done that before without it helping, but not with the above method.


......
>
>> ssh -v keesan at xxxx.org > ssh.log saves a zero-length file.
>
> Yep. Try "ssh -v keesan at xxx 2> ssh.log" instead (the error messages
> are printed to STDERR, a.k.a. file descriptor 2.)

I should read your whole mail before replying.  At least I got the X mouse 
copying and found some other problems.

Here is the output for ssh -v keesan at xxxx.org as root.

OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to xxxx.org [216.86.77.194] port 22.
debug1: Connection established.
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
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 130/256
debug1: bits set: 1020/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
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
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /root/.ssh/identity
debug1: try privkey: /root/.ssh/id_rsa
debug1: try privkey: /root/.ssh/id_dsa
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
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?.

>> I am happy dialing as user and ssh'ing as root, and my friends are
>> unlikely to ssh at all, but I would like to understand what is going on
>> with ssh.  This continues to be educational.
>
> As Kapil pointed out, if you _really_ want to know what's going on, use
> a non-broken distro and run 'strace'. You'll see all the system calls,
> failed file requests, etc.

I used strace when realplayer would not install on most of my computers 
but could not figure out the output.

I have a shell account at the Slackware 10.2 computer of one of our list 
members (also a TAG member).  I will try ssh there and look at the verbose 
output later.  I suspect I missed changing some permissions on three 
computers.

I looked at my neighbor's Fedora installation last night.  It would not 
play MP3s from an ipod and wanted Realplayer, which he had two copies of 
on his desktop, neither installed.  I showed him how to find their 
locations (no 'locatedb' but he had 'find' and we also could click on 
Properties) and run them when not on the path with './' and it wanted a 
library he did not have.  He did not know if he has mpg123.  He has been 
using linux much longer than me.  He spent 1/2 hour updating a bunch of 
programs online, most of which he has never used.  He rebooted several 
times at a few minutes per boot, loading things he did not know if he used 
such as crontab.  I would rather start small and add things I need.

Thanks for all the help.

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

Sindi Keesan