Security/Hacked System - Now what?!!

[bruce]

Wolfgang,

Right in what you wrote. And what you wrote allows for ssh commands to
be used where you specify the keyFile.

However you can also mod the ssh_config (i believe) to have it auto
use the keyFile with the pub/private key to negotiate the user/passwd
process for the ssh cmd. This is useful when remotely/programatically
accessing the ssh cmdline process for running remote apps, xferring
files, etc.

But, and in my case, once all of this is setup, and working. If hacker
guy gets in Sys1, (where Sys1/Sys2 have been setup to do pub/private
key, and the underlying Sys1/Sys2 keyfiles have been created) then
hacker guy can easily get into/access Sys2, provided they "know" the
username.

And this is where I'm trying to determine if there's any kind of
approach/process to allow for the programmatic use via ssh, but at the
same time be secure if the initial system is hacked.

Thanks

-bruce



On Sun, Dec 22, 2013 at 8:31 AM, Wolfgang S. Rupprecht
<wolfgang.rupprecht at gmail.com> wrote:
> bruce <badouglas at gmail.com> writes:
>> And regarding the ssh/remote access, you specify public/private keys,
>> and you have the key process run from the key file. This allows a user
>> to be able to ssh into the box without having to use the ssh passwd,
>> but only from the corresponding box that has the associated public
>> (master/client) passwd/key setup to permit the login access.
>
> You should set up the RSA or ECDHE private keys with a password.
> ssh-keygen prompts you for a password when it cranks out the key for
> you.
>
>> But in this situation, if a user hacks into the 1st system, then they
>> have access to the 2nd system, assuming they know the 2nd system's
>> username. This would happen as the private/public key access file has
>> been setup!
>
> Without the decryption password for the RSA or ECDHE keys, they are
> going nowhere.
>
> On the other hand, you want *all* of your systems up to snuff with
> all forms of unix password logins turned off.  Seems like you are
> implying that some systems are easier to break into than others.  That's
> not good.
>
> /etc/ssh/sshd_config:
>
> Protocol 2
>
> # reset the host keys to only rsa or ecdsa
> HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_ecdsa_key
>
> # rekey every hour or default data (1G - 4G depending on cipher)
> RekeyLimit default 1h
>
> SyslogFacility AUTHPRIV
>
> # We use RSA/ECDSA.  If it hasn't completed in 10 seconds, there is a
> # big problem.
> LoginGraceTime 10
>
> # Unlike what this looks like, it says that root may not use the unix
> # password for authentication.  Root *must* use public-key. -wsr
> PermitRootLogin without-password
>
> AuthorizedKeysFile      .ssh/authorized_keys
>
> # no unix passwords any more.  RSA or ECDSA only.
> PasswordAuthentication no
> ChallengeResponseAuthentication no
> KerberosAuthentication no
> GSSAPIAuthentication no
> UsePAM no
>
> X11Forwarding yes
> UsePrivilegeSeparation sandbox          # Default for new installations.
>
> # Set the keep-alive for a heartbeat every 60 seconds and a connection
> # close after 30 minutes. -wsr 2003/11/26
> ClientAliveInterval  60
> ClientAliveCountMax  30
>
> # Accept locale-related environment variables
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
> AcceptEnv XMODIFIERS
>
> # Cut down on the number of user accounts that can ssh in just in case
> # some bug allows .ssh/authorized_keys files to be written.
> AllowUsers root user1 user2 usern
>
> # --- end ----
>
>
> -wolfgang
> --
> users mailing list
> users at lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org