Recent revelations from the maker of networking gear Juniper Networks have shaken the industry: Juniper has identified unauthorized code in ScreenOS, its operating system that powers the NetScreen line of Juniper firewalls. Then last Friday, cryptography researchers revealed that Juniper has allowed changes to its code that could enable eavesdropping on encrypted virtual private network sessions of its customers.
If you are having trouble getting your web server to work or starting services on the system, SELinux could be at fault.
The traditional perimeter-focused security model has outlived its active usefulness as evidenced by the never-ending array of security breaches that constantly push the envelope on our tolerance for administrative “malpractice” in IT.
From the various security breaches in the private sector that are by now too plentiful to enumerate, through the fingerprint-stained OPM disaster, to the recently leaked database of personally identifiable information on over 191 million registered voters (in other words: all of them): no vulnerability seems too obscure, no exploit too impractical, no hack too audacious for some keyboard-toting mercenary to take advantage of the collective naiveté–or is it sheer incompetence?–of those who are paid to protect and defend access to sensitive information. How in the world did these people get their jobs, how dare they draw a salary, and how can they sleep at night? And, even more importantly: are you, by any chance, one of them?
Have you locked yourself out of WordPress due to some upgrade or restore mishap in combination with the lack of a valid email address to restore it to? Welcome to the Club of lucky administrators! There is a solution to this particular problem that just begs to be shouted from the rooftops: why don’t you reset your WordPress password using MySQL (or MariaDB). Let’s get right to it.
In order to transfer files from one server to another you can use Unix tools such as rsync with key pairs. Setting up the connection is rather easy once you know how to do it.
How keys work in public key cryptography
Public key cryptography relies on the use of a key pair that consists of a private and a public key. These two text strings can be compared against one another using a cryptographic algorithm. If the verification succeeds, access is granted.
Think of the public key as the lock on a door. It is technically available to everyone, but can only be opened with the corresponding private key.
In public key cryptography, your private key is like the master key of an apartment house in the real world: it can open all the locks on any door anywhere (for one and only private key, it is possible to generate many public keys).
In order for the origin host (ec-instance-01) to be able to connect to the target host (ec-instance-02), you need to follow these steps:
- create a key pair in the .ssh directory on the origin host (the one that will be initiating the connection); the private key of this key pair should never leave this host!
- append only(!) the public key from this pair to the authorized_keys file of your user on the destination host.
Here is how to do this in more detail.