Re: port forwarding timeouts

"JB" == Jeff B <jbeard_No-SpAm_1185@xxxxxxxxxxxx> writes:

JB> Richard E. Silverman wrote:
>>>>>>> "JB" == Jeff B <jbeard_No-SpAm_1185@xxxxxxxxxxxx> writes:
JB> fundament concept: *never* allow root access remotely. As it
>> happens, I'm fairly conversant with fundamental concepts of Unix
>> systems administration, as well as SSH JB> If it's truely
>> necessary, login as joe_user and then use SU or SUDO Automated jobs
>> frequently require remote root access,

JB> hum; automated remote access. Another (imo) conceptual error.

So, no cron job should ever communicate with another host? I don't
understand: how do you manage a large number of machines? Do you
personally sit 24 hours per day at a terminal running all jobs by hand
under your personal credentials (ssh-agent, Kerberos, hostbased,
whatever)? How about backups; do we need to attach a tape drive to every
computer on Earth? Please explain.

Btw, another good reason for remote root access has nothing to do with
automation, if that disturbs you generally. Say you need to restart a
daemon on 100 machines, and it requires root access to do so. You type
something like:

$ for host in `netgroup foo-hosts` do; ssh root@$host /etc/init.d/foo restart; done

If I understand you, you would prefer:

ssh $host sudo /etc/init.d/foo restart

.... meaning you will have to type your password 100 times. That is not
workable. Nor can you reasonably anticipate every possible remote command
sequence you might need to execute as some other uid and create specific,
locked-down, NOPASSWD sudo rules for them. How would you deal with this
frequent need in the life of a sysadmin?

Note that Kerberos can solve this problem nicely, by providing securely
forwarded, session-limited credentials you can use to authorize changing
uid on the remote host. However, I haven't seen you suggest this or a
similar mechanism yet.

JB> I'm not going to engage in a p***ing contest with you. There are
JB> a great too many predisposed to that game already.

There is no contest. In any event, I am merely pointing out that you
repeatedly make factually inaccurate statements regarding SSH, in an SSH
newsgroup, and do not acknowledge when you've been corrected -- indeed,
you sometimes continue to make the same mistakes in subsequent posts.
Which suggests you might do well to spend more time learning from others'
posts and less time writing misleading ones.

--
Richard Silverman
res@xxxxxxxx

.

Relevant Pages

  • Re: Question on blocking remote root access via SSH
    ... You don't need to permit root login in sshd to gain root access. ... >> I have set up SSH service on my remote linux server. ... >> Does anyone know how to turn off remote root access for SSH on Linux? ...
    (comp.security.ssh)
  • RE: redhat-list Digest, Vol 23, Issue 9
    ... encrypt password for Kickstart ... I would be careful of using the wheel group to allow ssh logins, as admins typically use this group in sudoers file to grant root access for non-root users; granting the wheel group ssh logins as well as root access is essentially allowing root access over ssh anyway; although an outside attacker would at least have to guess the non-root user's id and password. ...
    (RedHat)
  • RE: is this an intruder?
    ... granting the wheel group ssh logins as well as root access is ...
    (RedHat)
  • Re: Is OpenSSH 3.5p1 secure?
    ... Do not allow root access over ssh. ... Do allow access over ssh for one and only one user. ... NOTHING is perfectly secure. ...
    (comp.security.ssh)
  • Re: Rsync, ssh and using root.
    ... On 10 Dez, Randy Smith wrote: ... > This avoids the problems with SSH and root access but may lead to other ...
    (FreeBSD-Security)