ssh: Permission denied

[Phil Meyer]

Simon Wu wrote:
> Hello,
>
> I tried ssh between two Fedora 3 PCs. It only works one way, the other
> way, I got the following error:
>
> root at pcary21j's password:
> Permission denied, please try again.
> root at pcary21j's password:
> Permission denied, please try again.
> root at pcary21j's password:
> Permission denied (publickey,gssapi-with-mic,password).
> [root at pcary631 ~]# cd /etc/udev
>
> I'd appreciate if any one can help.
>
> Thanks,
>
> Simon
>

It is common, and appropriate to turn off root access to ssh.  This is 
done in the /etc/ssh/sshd_config file.

All comments in this file are the default values, and several should be 
changed:

#Protocol 2,1
should read:
Protocol 2

#PermitRootLogin yes
should read
PermitRootLogin no

and this is probably your case on one system.

Also, it is common and appropriate to ADD a line to this file like:

AllowUsers fred wilma barney betty

This will prevent any mischief on user ids that get installed from 
broken rpms, or other software installs, that may leave system accounts 
open to attacks.

sudo is your friend.

Learn to NEVER remote login as root.

For all the UNIX/Linux administrators that I have worked with over the 
years since ssh became available (yes, there was a time before that!), 
the preferred practice is:

1.  generate keys on your desktop --  Don't use passcodes if you want 
easy logins.  Consult your corporate security guru if you have one.
    ssh-keygen -t rsa
    ssh-keygen -t dsa
    cd ~/.ssh
    cp id_rsa.pub authorized_keys
    cat id_dsa.pub >> authorized_keys

2.   Copy those keys to all systems that you manage.
    cd ~
    scp -rp .tcshrc .login .ssh target_host:
       (or whatever shell startups you might like, ie: .profile, 
.bashrc, etc.)
    enter your password for the remote system when asked for

 From now on you can ssh to and scp to target_host without entering a 
passwd.

When the need arises to to manage target_host:
    ssh target_host
    sudo vi /etc/ssh/sshd_conf (for example)

This will leave a trace in the log files, and will be reported on that 
day's Logwatch.  A very good thing when you have unexpected problems and 
notice a typo in the command on Logwatch reports. :)

It is a very rare occasion that requires root login to a remote system.

Good luck!