SSH (Secure Shell Connection) is a secure way to login to a Linux server and remotely work with it. However there might be a good margin of further improvements to secure even more this.

1- Substitute password authentication with public key authentication: * Security: Public key authentication is more secure than passwords. Passwords can be brute-forced or guessed, while a cryptographic key pair (public and private keys) is practically impossible to crack with current technology. * No Replay Attacks: Since the private key is never transmitted over the network, there's no risk of interception and replay attacks, unlike passwords. * Automation: Public keys are great for automated processes. You can use SSH without entering a password each time, which is essential for scripts and system administration tasks. * Management: It's easier to manage and revoke access with public keys. Instead of changing a password (which might be shared or used on multiple systems), you just remove the public key from the server. * Phishing Resistant: Users are less susceptible to phishing attacks since they're not entering a password that could be captured.

2- Disable root login from the SSH configuration: * Mitigate Brute Force Attacks: Root is a known username and often targeted by brute force attacks. Disabling root login means attackers can't directly access the most privileged account. * Limit Privilege Escalation: Even if an attacker compromises a regular user account, they still need to find a way to escalate privileges to root, adding an extra layer of security. * Audit Trails: Using sudo from a regular account to perform administrative tasks leaves a trail, helping in auditing and monitoring activities. * Reduced Risk of Accidental Damage: Preventing direct root access reduces the risk of accidental high-impact changes by system administrators. * Compliance: Many security standards and best practices advise against using root accounts for routine administration.

3- Force 2FA authentication with TOTP: Adding Time-based One-Time Password (TOTP) as an additional layer to SSH authentication significantly boosts security: * Two-Factor Authentication: TOTP introduces a second factor of authentication. Even if an attacker steals a user's SSH key or password, they still need the TOTP, which is typically generated on a device the user possesses. * Dynamic Codes: TOTPs change every 30-60 seconds. This makes stolen codes useless after a very short time, countering replay attacks. * Mitigates Phishing: TOTPs are harder to phish than static passwords because they are constantly changing and are only valid for a short period. * No Network Dependency: TOTPs are generated by an algorithm based on time and a secret key, so they don't require network connectivity, making them reliable and efficient. * Harder to Intercept: Unlike static passwords, intercepting a TOTP doesn't compromise future logins, as each password is valid for only one login session.

4- Change SSH server port from default 22 to a less common port number * Reduce Automated Attacks: Many bots and scripts target port 22 for SSH attacks. Changing the port can reduce the volume of these automated attacks. * Lower Profile: By not using the default port, your server becomes less obvious to casual scanners who are looking for easy targets. * Filter Out Noise: Changing the port can reduce log noise from repeated login attempts, making it easier to spot genuine security threats.

Configuring your local machine

1- Setup Public Key Authentication: * Generate Key Pair: To make the public key authentication work, we need to generate the called "key-pair": the public key which you share with the remote server, and the private key which must be kept private and secure on your local machine. For enhancing even more security, you can add a passphrase to your private key so that is won't be possible to use it until the passphrase is entered. Thanks some commonly used tools you can achieve all the burden above with the simple commands below:

# replace my_server_name here eventually
# when prompted with passphrase, enter it with keyboard
ssh-keygen -t ed25519 -f ~/.ssh/my_server_name

# replace my_server_name here eventually
ssh-copy-id -i ~/.ssh/my_server_name.pub user@remote_host

If ssh-copy-id is not an option, you still can manually copy the public key to the remote server. First display and copy your public key: (should be available after the generation steps above)

cat ~/.ssh/my_server_name.pub

Then open the authorized_keys file on the remote server and paste the copied key to its end.

nano ~/.ssh/authorized_keys

Now an important step, do not forget to apply necessary permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

2- Add SSH configuration (optional): This will improve the UX while logging into your remote server making it more convenient. For this we suppose that your remote host IP is 192.168.12.34 and we will suppose the SSH port has been set on the remote server to, for example, 4898. Based on these parameters, you should add this section to your ~/.ssh/config file.

#~/.ssh/config
Host my_server_name
    HostName 192.168.12.34
    User my_username
    IdentityFile /home/my_username/.ssh/my_server_name
    Port 4898

3- Have a TOTP client: You will need this to be able to generate the TOTP number once prompted from the remote server. You have couple options here: Mobile apps like Google Authenticator or Authy, Desktop applications like Keepass TOTP or even more advanced tools like YubiKey

Configuring your remote server

Instructions here are tested on Debian based Linux distributions, but should work on other distros as well without "big" differences. 1- Install google authenticator: Here you run the authenticator installation then you execute it, and we will answer "y" for all the prompts.

sudo apt install libpam-google-authenticator
...
...
...

google-authenticator
Do you want authentication tokens to be time-based (y/n) y
█████████████████████████
██ ▄▄▄▄▄ █▀▄█▄█ █ ▄▄▄▄▄ ██
██ █   █ █▀▄▀█▄█ █   █ ██
██ █▄▄▄█ █ ▀ ▀ ▄ █▄▄▄█ ██
██▄▄▄▄▄▄▄█▄█ ▀ █▄▄▄▄▄▄▄██
██▄▀▄▀▄█ ▀▄█▀▄█▄█▀█▀██▀██
██▄█▄██▄▀▄▄▀█▄▀ ▀▄█▄▀▀▄██
██▄▄▄▄▄▄▄█▄▄█▄▄███▄█▄▄▄███
█████████████████████████

Your new secret key is: 4D3FPZ2W6Y7IOMV 
Your verification code is 123456
Your emergency scratch codes are:
81234567
89123456
78123456
69123456
58123456

Here, pay attention to the generated codes: Use The ASCII made QR code (yay, terminal!) to add the TOTP to your smartphone app by adding new entry and scanning the picture. And use the secret key to add a TOTP setup to your keepass application and/or YubiKey. The backup codes should be saved for eventual emergency cases.

2- Configure SSH server: Here we will act on two configs: the SSHD and the PAM. As we explained in the first section, we will edit the SSH daemon config file to disable password authentication and root user, keep interactive keyboard for TOTP prompting, enable the Public Key authentication and change the SSH port number. The resulting config file /etc/ssh/sshd_config should look like this:

sudo nano /etc/ssh/sshd_config

# This one we changed from default Port 22
Port 4898

# Add this entry or edit it if it is already existing
PermitRootLogin no

# We can explicitly set this although it should be the default value even if omitted. 
PubkeyAuthentication yes

# This setting will disable the password based authentication. 
PasswordAuthentication no

# This entry will allow both publickey authentication and keyboard-interactive which # we need to enter our TOTP code
AuthenticationMethods publickey,keyboard-interactive

# PAM (Pluggable Authentication Modules) is also required to allow google 
# authenticator #integration
UsePAM yes

# Depending on your Debian version, if you find the entry 
# KbdInteractiveAuthentication existing in the config file, then use it, otherwise you 
# might find the deprecated entry which is ChallengeResponseAuthentication which
# in that case should be set to yes instead.
KbdInteractiveAuthentication yes

3- Configure PAM: for this we need to enter some changes to the /etc/pam.d/sshd file:

sudo nano /etc/pam.d/sshd

First, find the following three lines and comment them out

#@include common-auth
# account  required     pam_access.so
#@include common-password

Then add the following line to the end of the file:

# two-factor authentication via Google Authenticator
auth required pam_google_authenticator.so

Now we only have one last step to go: reststart the SSH server

 sudo systemctl restart sshd

Server setup should be complete.

SSH like a boss

• Given all the steps above correctly achieved, you should by now be able to ssh to your remote server as easy as the following:

 ssh my_server_name
(my_username@192.168.12.34) Verification code: 
Linux raspberrypi 6.1.0-rpi6-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.58-1+rpt2 (2023-10-27) aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec  6 01:16:51 2023 from 192.168.12.33
my_username@my_server_name:~ $

You will be of course prompted for the TOTP code (4 digits) which you should use your smartphone, keepass or YubiKey to get them. So that was pretty match it. I will be happy to support for any further questions, rectifications or simple likes :)

Ok, I personally only see it much like an x86 programmer in the 70's astonished by a C compiler turning his "human words C code" into a working x86 ASM instructions..

So at the end of the day, nothing changes.. still the same game.. just re-arrangement of what the human should manage and what the machine should manage.

People often think if the machine becomes able to fully accomplish one of their tasks, it means they are becoming jobless.. false.. it means they have more new kind of jobs and problems to solve.

And even if we take apart the story of skills adaption, and assume you wanna stay at your exact current field of expertise, do you really think tools like copilot will "kill" the need for developers who know how to write high quality code? I really really doubt it, I rather think it will force them to fasten the belts and grow a bit more towards their best level of expertise.. and, ok, I would agree it will eliminate those with low capabilities who refuse to grow and stay at their mediocre level.

Back to our assembly example (sorry that was my first love and will apparently stay forever), although compilers almost killed hundred of thousands of job positions requiring x86 programmers, look how rare it is today to fall on a skilled developer who masters the art of writing, debugging, or optimizing a compiler.. or reverse engineering malicious code..

Very very few ones right ? because they all rely on compilers and automated tools to do the stuff. Probably half of developers nowadays might not even know what happens to their source code when they press the "run" button.

So, do you think those highly skilled x86 programmers are today jobless.. or rather being spammed day and night by recruiters of giant IT companies?

Embrace the change and don't oppose it. “The Only Constant in Life Is Change.”- Heraclitus

#github #copilot #javascript #career #people #php

So let's go for a quick blogpost and as usual I'll try to bring something useful (I hope) with as few words as I can (I hope as well).

The goal:

• Turning any class in your project "logging-able", yet with the least possible changes and boilerplate verbosity.

The classical way:

• So knowing that monolog's logger (however you configure it) is a tagged service at the end, the "only" way to "cleanly" use it is to DI/inject it to the needed service

• Injecting services in Symfony can be done with multiple approaches and strategies. But in best cases you'll have at least to touch two things:

  • The class needing the logger by defining a private property to receive the logger service instance, and an assignement in the constructor to actually receive the service.

  • The services.yaml if you choose to go with setter injection rather than constructor injection (as the latter can benefit from autowiring)

• Now as logging is a "nice and wanted" feature, your urge to log stuff here and there can grow over and over, and you might feel silly polluting your code with one more line of properties and one other in the constructor. Sometimes you'd only write a constructor for the sake eyes of the DI injection of the logger. Having this exact snippet copy/pasted over a dozen of classes might really make you feel unhappy.

The shortcut:

• If you use the autocomplete feature of PHPStorm, you'd notice a pair of interface/trait having the same prefix.

  • Psr\Log\LoggerAwareInterface

  • Psr\Log\LoggerAwareTrait

• Can we use them altogether to solve the issue above? → yes.
• In general the SomethingAwareInterface naming pattern, means the class is supposed to have a method named "setSomething()".
• And following conventions as well, having that setter means your class should have a "something" property that setter will modify, and here comes the SomethingAwareTrait to define that property for you.
• Now implementing/using that interface/trait makes your class having a property named "something" and a setter for it. Nice thing here is that all that code verbosity is totally hidden in the backyard.
• Still one single obstacle: How will the trait actually get the service instance.
• One solution we might think about is the "@required" annotation above the setLogger() method, but in our case the setter is defined in the used trait, and we can't modify it.

• A once and for all solution is to slightly modify the application's kernel, so that it loops over all services before the container is built, and check if any service is a "somethingAware", then make him really aware of it by explicitly injecting the service. Here is a showcase to make any class of your project that implement/use the pair above, being able to use the logger straight away without any further overhead:

<?php

// src/Kernel.php

namespace App;

use DateTime;
use Psr\Log\LoggerAwareInterface;
use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Definition;
use Symfony\Component\HttpKernel\Kernel as BaseKernel;

class Kernel extends BaseKernel implements CompilerPassInterface
{
    use MicroKernelTrait;

    public function process(ContainerBuilder $container): void
    {
        $definitions = $container->getDefinitions();
        foreach ($definitions as $definition) {
            if (!$this->isAware($definition, LoggerAwareInterface::class)) {
                continue;
            }
            $definition->addMethodCall(
                 'setLogger',
                [$container->getDefinition('monolog.logger')]
             );
        }
    }

 private function isAware(Definition $definition, string $awarenessClass): bool
 {
     $serviceClass = $definition->getClass();
     if ($serviceClass === null) {
         return false;
     }
     $implementedClasses = @class_implements($serviceClass, false);
     if (empty($implementedClasses)) {
         return false;
     }
     if (\array_key_exists($awarenessClass, $implementedClasses)) {
         return true;
     }

     return false;
 }

}

Now Just use implement the interface and use the trait in your command, for example, and you are ready to go!

<?php

// src/Command/MyCommand.php

declare(strict_types=1);

namespace App\Command;

use Psr\Log\LoggerAwareInterface;
use Psr\Log\LoggerAwareTrait;
use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

#[AsCommand(
    name: 'app:my-command',
    description: 'test!',
)]
class MyCommand extends Command implements LoggerAwareInterface
{
    use LoggerAwareTrait;

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $this->logger->info('I can log!');

        return Command::SUCCESS;
    }
}

• You can clone/download the code snippets above from this gist on github as well

Enough talk for today, hope it helped and see you soon!

You have a container under a docker-compose project, that you want to communicate or access another container which exists under a second docker-compose project

A real-life situation?

• For some security policy, your SysOp or hosting provider blocks all external traffic, except those for port 80 (HTTP) or port 443 (HTTPS). However, you want to set up and manage several web (or non-web) services on your machine, basically using docker containers and managed by docker-compose.

• To handle this you set-up a reverse-proxy using a dedicated docker-compose project and container, called proxy.

• The proxy container/project listens on port 80, for all incoming external requests. (The nginx config can distinguish the called domain with the server_name directive)

• On the other side, on another docker-compose project, you have a Kibana service that serves request on kibana.exemple.com, but under port 5601 (still HTTP traffic).

• The Kibana service is on a dedicated container called kibana, among three other containers in the ELK docker-compose porject (different from the reverse-proxy project).

• The solution as you would guess, is that the reverse-proxy forwards the external http://kibana.exemple.com:80 to an internal http://kibana:5601, to solve the port restriction issue.

• The kibana domain name used when we want to hit the http://kibana:5601 endpoint, is actually unknown to the outside, or even to the host machine (in principle), it is only internally resolvable by docker built-in DNS to map it to the kibana container. The problem here is, the network to which the kibana container belongs to is internal and only visible within the ELK docker compose projcet, to which kibana container belongs.

• Yet, we want the reverse-proxy container that lives in a separated project to be able to hit that endpoint without much boilerplate work.

A solution?

• Fortunately, docker-compose provides an easy way to solve this kind of situations, which is the external networks.

• An external network must be defined, outside from the docker-compose config (one way through a docker-compose command)

• Both networks should join this network, and, that's all.

• Now you can just refer the container by its name from one or the other side as if they were on the same project

• Here it how the official docker-compose defines the feature:

How to make it work?

• Create an external network from command line, here we suppose you name it proxy_external

$ docker network create proxy_external

• Add the proxy_external under the services → proxy→ networks level of docker-compose.yml of the reverse-proxy project
• Add the proxy_external straight under the networks level of docker-compose.yml of the elk project . Define this as an external network

# reverse-proxy project

version: "3.8"
services:
  proxy:
       # ..
    networks:

      # This is the internal network for the reverse-proxy project
      - proxy

      # This is the external proxy
      - proxy_external
networks:

  # This is the server's network, defined by the service
  proxy: ~

  # This is an external network. It serves as a bridge between reverse-proxy and other projects.
  proxy_external:
    external:
      name: proxy_external

• Add the proxy_external under the services → kibana→ networks level of docker-compose.yml of the reverse-proxy project

• Add the proxy_external straight under the networks level of docker-compose.yml of the elk project . Define this as an external network

# elk project

version: "3.8"
services:
  elk
       # ..
    networks:

      # This is the internal network for the elk project
      - elk

      # This is the external proxy
      - proxy_external
networks:

  # This is the server's network, defined by the service
  elk: ~

  # This is an external network. It serves as a bridge between reverse-proxy and other projects.
  proxy_external:
    external:
      name: proxy_external

Further readings:

• https://docs.docker.com/compose/compose-file/compose-file-v3/#network-configuration-reference

• https://odysee.com/@the-digital-life:a/docker-networking-tutorial-all-network:1

"SOLID of uncle Bob, How I see them?"

And got a nice like from Uncle Bob :)

I am a big fan of SOLID! Not only that, time after time, I elaborated my own words to express SOLID principles. And as you can see below, I noticed it is almost all about embracing the #change, mastering the #change and anticipating the #change..

[S]: a Unique decider of #change!

Whenever you pack some of your code into a module (i.e: function, class, package..), there must be a unique thing(often a business department or tech dependency), that will force you to #change the code of that module.

One, and not two, or twenty, only one!

[O]: Minimize touched code if you HAVE to #change

"Open for extension / closed for modification", right?

Well, there is nothing which is open AND closed at the same time, you know! Your code will be ALWAYS open for modification, otherwise, let's apply TripleDES encryption on each of our classes and then delete the key. Thus we have a really closed module.

That's why I believe "closed to modification" should be suffixed with: "except the very tiny piece that will be used to connect the old code with the newly added one"

[L]:Your problem is not mine

Ok this principle has the scariest words, but from my point of view what it wants us to avoid is writing subclasses which add rules to the ones it inherits. (that's rude right?)

Hence my way to see it as a "Your problem is not mine".

Suppose you ship a package to your customers, who are developers in this case. And one day you provide them a new version consisting of a submodule of the old one, but with a bunch of silent restrictions and rules. You only did that to solve some of your own code problems some where..

How would you imagine the face of that poor developer trying to figure out WHY are you doing this? Don't you think that "Your problem is not his problem" ?

[I]: Don't pull all your eggs in one basket

The official version of the principle is: “Clients should not be forced to depend upon interfaces that they do not use.” Again, my intuitive question here is: Nice, but why? or, what does it try to troubleshoot?

And my answer is: it clearly fights those hasty guys (including me sometimes :)) who write those allknowing interfaces having a dozen of methods. Some ultimate interface and called IReadWriteCompress or ReadWriteCompressInterface..

Without even looking into the code, we feel the instinct and the urge to split that BigTank into three small speed-boats, for instance: WriteInterface, ReadInterface and CompressInterface.

So one should not pull all his eggs in one basket, or all his methods in one interface!

[D]: Rely on the least #changing dependency

"High-level modules should not depend on low-level modules. Both should depend on abstractions"

Ok, but why? The answer I could come up with is: "no one wants to depend on loosely changing element right?"

And this makes it obvious to go for dependency on abstractions rather than dependency on implementations (aka low-level modules).

Low-Level usually has way more details and information to tell than abstractions. Abstractions only expose the big picture which is supposed to last.

Abstractions have less details, which means adapting to their #changes is always easier.

So, that was it, and I would be glad if you could also share your own SOLID versions with me :) Happy coding!

To follow the path, look to the master, follow the master, walk with the master, see through the master, become the master. ~Zen Proverb.

I believe these are relative and probably subjective estimations, that might specially change from an environment to another and from an ecosystem to another.

But If we want to gather the common aspects that might depict a senior developer regardless their stack or professional surroundings, we might come up with the following hints:

1. Never argues this language is STRONGER than this or this framework is BETTER than this. He knows they are tools to achieve goals depending on the context.

2. Spends MORE time on analysing the problem and discussing it with the client than time on implementing the feature.

3. Has the reflex to check as much as possible if the problem can be solved without writing a line of code.

4. Is able to estimate in which direction the code will evolve in the future and writes code accordingly.

5. Strongly believes development is about solving problems and not writing code that runs.

6. Can switch between languages and frameworks without needing months to learn everything, just the needed knowledge to implement the feature.

7. Knows his stack PERFECTLY, keeps up-to-date with releases, best practices, bug fixes, tools, and so on. For the rest of stacks, he doesn't sink into details.

8. Knows about different point of views in code design, but doesn't spend much time in worthless battles.

9. Courageous enough to write his own package, and humble enough to use other developer's packages. Also has the ability to estimate which alternative is more relevant.

10. Optionally, in his free time, writes & ships code that people really use.