full-disclosure - Re: Any update on SSH brute force attempts?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: raju at linux-delhi.org (Raj Mathur)
Subject: Re: Any update on SSH brute force attempts?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Barrie" == Barrie Dempster <barrie@...oot-robot.net> writes:

    Barrie> On Mon, 2004-10-18 at 06:41 -0500, Ron DuFresne wrote:
    >> Why not just disallow root logins directly, and force someone
    >> with a valid user account to su after getting a shell?  It was
    >> my impression that was more standard, and if one has to allow
    >> remote root directly, at least restrict it to specific systems
    >> and users.  All the places I have worked for forced the su
    >> after shell to root..

    Barrie> I'm in agreement with this, as well as combining this with
    Barrie> use of sudo for common functions requiring root privs
    Barrie> (such as using tools requiring raw socks support for
    Barrie> instance) meaning you rarely have to become root and the
    Barrie> root account becomes slightly more difficult to
    Barrie> compromise.

Using su forces the use of passwords, which are difficult to manage in
a multi-admin scenario.  For instance, you may have to give the root
password to 3 different people (1 in each 8-hour shift).  What happens
when one of these people leaves the organisation?  You change the root
password and intimate the remaining two, as well as the replacement,
of the new root password.

Multiply this by 100 or 1000 machines and it becomes hell.

Use key-based login instead, then all you need to do is add/delete
keys to authorized_keys when people join/leave the group of
administrators.  Heck, you can even use cfengine or equivalent with
appropriate classes to automate the whole procedure -- define admin
groups on the central server and roll out public keys to all systems
automatically.

Next, how do you manage passwords?  The options are different password
for each system (which means pieces of paper in wallets with the
passwords scribbled on them) or use the same password for multiple
machines (security nightmare).  Keys are so much simpler -- just
remember the pass phrase of your own key and you're through.

Regards,

- -- Raju
- -- 
Raj Mathur                raju@...dalaya.org      http://kandalaya.org/
       GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
                      It is the mind that moves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD4DBQFBc92iyWjQ78xo0X8RAp1uAJiV+aZ+Lc9b+poBT99fhjZ5I22vAJ4y6cqR
MHrqYQyF4f8eHhWH9jAJdg==
=HtuA
-----END PGP SIGNATURE-----