ok, heres my problem I have new servers with the standard version of ssh on it, with ssh contents located in /root/.ssh and I'm needing them to talk via ssh to some dying old sunos servers, running an earlier kernel and version of ssh, with the ssh contents located in /.ssh2, I need all these machines to all have an authorized_keys file with all the public keys; at first I thought I'd just need to rename the /.ssh2 folder to /.ssh to make it uniform but I still cant get the machines to talk smoothly, also the older servers public keys generated look different to the new machines public keys. Do i need to update the older suns version of ssh in order to get it working or am I missing something, thanks.

with ssh contents located in /root/.ssh
Don't allow root account logins over the network for any service, LAN or not. Period.


and I'm needing them to talk via ssh to some dying old sunos servers
So this thread belongs in the Solaris forum, right? Do they only use protocol v1?


I thought I'd just need to rename the /.ssh2 folder to /.ssh
OpenSSH reads info from ~/.ssh by default and only uses ~/.ssh2 if it exists.
It's not necessary to split that up.


I still cant get the machines to talk smoothly
Post exact and verbose output of both ends please.
If you don't want to mess with your running daemons start one with tripple debug flags on another port and pipe the output to file. The daemon will die when disconnected.

I disagree. Allowing root access via Password authentication and using a weak root password is a big risk, since an attacker can easily mount a dictionary attack. Disabling root login prevents that.
However, when properly secured, root login is no more vulnerable than using a user account to log in and suto gain root privileges. Especially when one needs regular root access (maybe even by automated scripts), remote root login maybe the only option.
Of course, one should be careful to secure the SSH server. The best thing would be to disable password authetication and use public-key authetication.

However, when properly secured, root login is no more vulnerable than using a user account to log in and suto gain root privileges.
Generally speaking allowing direct root account access to any networked service just is not accepted procedure, it exposes the root account, it makes managing access and accounting harder and it's also a discipline thing. In essence it's not a question of a SSHv2+pubkeyauth root login being "good" but it's one about avoiding unnecessary risks. Allowing direct root account access just isn't best practice.


Especially when one needs regular root access (maybe even by automated scripts), remote root login maybe the only option
Frequency is IMNSHO no excuse for direct root account access. Please name one task for which there are no alternatives and direct root account access is the only option.

I think this root account restriction highly depends on your setup.
Disabling root account would mean that to gain root access you would first need to crack a user account. So you need to crack one more account and be logged in locally.
The thing is, as soon as you have entered a system, priviledge escalation is in general not to complicated (its here that it depends on your setup). At least its a known general rule.

I agree for the increased logging in case of priviledge escalation and my system all have root account disable but its not THAT clear to me what the consequences are but I'm interested in knowing more.

I don't mention people who use sudo without thinking, this option doesn't help them.