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@pcary21j's password:
Permission denied, please try again.
root@pcary21j's password:
Permission denied, please try again.
root@pcary21j's password:
Permission denied (publickey,gssapi-with-mic,password).
[root@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!
