[TAG] lpr works for user not root in Basiclinux 2.1
ben at linuxgazette.net
Thu Mar 1 06:28:30 MSK 2007
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.
> 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".
2) Copy the *public* key (the contents of /home/keesan/.ssh/id_dsa.pub)
from host1 into /home/keesan/.ssh/authorized_keys on host2.
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.
> ssh keesan at xxxx
> Permission denied (publickey,password,keyboard-interactive).
> Same permissions on ssh and on the .ssh files in both computers.
> Same problem whether or not I copy over known_hosts from /root/.ssh .
'known_hosts' will not help you; "ssh" will update it as required.
> ssh -v keesan at xxxx generates a long message ending in
> debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT_REPLY
> Host key verification failed.
That "long message" is the one you should read carefully to figure out
what problem it's reporting. However, following the above procedure
should obviate the problem.
> First it received one expected string but not another one.
> ssh -v keesan at xxx > 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 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.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
More information about the TAG