FerociousButterfly.com

/ SprUng, KEEPERS, CODE-NOW-NOW-NOW, CODING / 1 minute of reading
overviewdisable root ssh for ubuntu/linux

Ferocious Butterfly

The Setup

 

To ensure your server is properly configured for running both Laravel and a headless WordPress setup, there are a few key configurations you'll need to check and set up:

1. General Server Requirements

Both Laravel and WordPress have specific system requirements, and you'll want to make sure your server is prepared to handle them. Here's a breakdown:

Operating System

  • Ensure you're using a Linux-based server like Ubuntu or AlmaLinux (which you’re already using). Make sure the server is up to date:

    sudo yum update  # For AlmaLinux

PHP Requirements

Both Laravel and WordPress require PHP, but Laravel (latest versions) often requires newer PHP versions than WordPress.

  • Laravel (PHP 8.x required):

    sudo yum install php php-mbstring php-xml php-bcmath php-json php-zip

  • WordPress (PHP 7.4+ minimum): You'll want to install or ensure the following PHP extensions are available for WordPress:

    sudo yum install php php-mysqlnd php-gd php-xml php-json php-curl php-xmlrpc php-imagick php-intl

Composer for Laravel

Laravel requires Composer to manage dependencies. Ensure Composer is installed:

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Node.js and NPM (for Laravel with React)

Laravel Mix (used to compile assets) requires Node.js and npm. You likely already have this set up, but verify:

sudo yum install nodejs npm

2. Web Server (Apache) Configuration

You’re using Apache, so you'll want to configure it to handle both WordPress and Laravel:

Virtual Hosts Setup

You'll need to set up virtual hosts for each application (Laravel and WordPress) to serve them under different domains or subdomains.

Example configuration for Apache:

  1. Laravel Virtual Host:

    <VirtualHost *:80>
    ServerName flap-flap.ferociousbutterfly.com
    DocumentRoot /var/www/flap-flap.ferociousbutterfly.com/public
    
    <Directory /var/www/flap-flap.ferociousbutterfly.com/public>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/laravel_error.log
    CustomLog ${APACHE_LOG_DIR}/laravel_access.log combined
</VirtualHost>

  2. WordPress Virtual Host:

    <VirtualHost *:80>
    ServerName wp.flap-flap.ferociousbutterfly.com
    DocumentRoot /var/www/wp-flap-flap.ferociousbutterfly.com

    <Directory /var/www/wp-flap-flap.ferociousbutterfly.com>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/wordpress_error.log
    CustomLog ${APACHE_LOG_DIR}/wordpress_access.log combined
</VirtualHost>

Mod_Rewrite for Apache

Both Laravel and WordPress require mod_rewrite to handle pretty URLs. Make sure it’s enabled:

sudo a2enmod rewrite
sudo systemctl restart httpd

3. Database (MySQL or MariaDB)

Both Laravel and WordPress use databases (typically MySQL or MariaDB). You’ll need to ensure MariaDB is installed and configured correctly. You can host both applications on the same database server, but it’s better to create separate databases.

  1. Install MariaDB:

    sudo yum install mariadb-server mariadb
sudo systemctl start mariadb
sudo systemctl enable mariadb

  2. Set up the databases:

    CREATE DATABASE laravel_db;
CREATE DATABASE wordpress_db;

CREATE USER 'laravel_user'@'localhost' IDENTIFIED BY 'password';
CREATE USER 'wordpress_user'@'localhost' IDENTIFIED BY 'password';

GRANT ALL PRIVILEGES ON laravel_db.* TO 'laravel_user'@'localhost';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wordpress_user'@'localhost';

FLUSH PRIVILEGES;

4. SSL Configuration

If you plan to use HTTPS, you'll need SSL certificates. You can use Let's Encrypt for free SSL certificates. Install Certbot and configure SSL for both Laravel and WordPress.

  1. Install Certbot:

    sudo yum install certbot python3-certbot-apache

  2. Get SSL Certificates:

    sudo certbot --apache -d flap-flap.ferociousbutterfly.com -d wp.flap-flap.ferociousbutterfly.com

  3. Auto-Renew SSL: Certbot automatically sets up renewal, but you can manually test it:

    sudo certbot renew --dry-run

 

 

The steps you're planning, including enabling mod_rewrite and setting up WordPress, should not affect the functioning of Matomo as long as they are set up independently in separate virtual hosts with their own directories. Your current UFW firewall rules look fine as they allow traffic on ports 80 and 443, which is necessary for both Matomo and your WordPress/Laravel setup.

A few points to ensure smooth operation:

  1. Virtual Hosts Separation: Each domain/subdomain (flap-flap.ferociousbutterfly.com, tracker.ferociousbutterfly.com, etc.) is configured as its own Apache virtual host, which means they won't interfere with each other unless there’s a misconfiguration in the Apache settings. Since Matomo is served through tracker.ferociousbutterfly.com, it operates independently from the wp-flap-flap.ferociousbutterfly.com domain, so installing WordPress won’t impact Matomo.
  2. Matomo Database: Since you have separate databases for Matomo, WordPress, and Laravel, the database activities related to WordPress or Laravel won’t interfere with Matomo's data collection or reporting functions.
  3. mod_rewrite: Enabling mod_rewrite is common and required for WordPress and Laravel. Matomo itself doesn’t heavily depend on Apache's mod_rewrite unless you've configured specific redirects within your Matomo installation, which is uncommon. This step should be safe.
  4. SSL Redirection: You’ve already included SSL redirection in both virtual host configurations, which looks fine. Just ensure that your SSL certificates (for all domains) are properly configured.
  5. Running Commands as Root: You’re receiving a warning when running Composer as root. It’s recommended to run Composer commands under a different user (not root) for security reasons. You can create a non-root user and give them permission to manage your Laravel and WordPress installations.

Here’s how to create a non-root user if needed:

sudo adduser yourusername
sudo usermod -aG sudo yourusername

Then switch to that user before running Composer or other commands:

su - yourusername

Once you’ve confirmed the separation of your domains and configurations, you should be safe to proceed with:

sudo a2enmod rewrite
sudo systemctl restart apache2

 

 

 

 

 

5. WordPress Configuration (Headless)

  1. Install WordPress: Download and install WordPress in the /var/www/wp-flap-flap.ferociousbutterfly.com directory:

    wget https://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
mv wordpress /var/www/wp-flap-flap.ferociousbutterfly.com/public/

  2. Configure WordPress:

    • Update the wp-config.php file with your database credentials and set the appropriate SITEURL and HOME for the headless setup.

  3. Enable REST API: WordPress’s REST API is enabled by default. You can access it through:

    http://wp.flap-flap.ferociousbutterfly.com/wp-json/wp/v2/

6. Security

  • Firewalls: Ensure ports 80 (HTTP) and 443 (HTTPS) are open.

    sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

  • File Permissions: Ensure proper file permissions for both Laravel and WordPress to avoid issues with file uploads and security.

    sudo chown -R www-data:www-data /var/www/flap-flap.ferociousbutterfly.com
sudo chown -R www-data:www-data /var/www/wp-flap-flap.ferociousbutterfly.com

7. Caching and Performance (Optional)

  • OPcache: Enable PHP OPcache for performance.

    sudo yum install php-opcache

  • Caching Plugins: Use a caching plugin for WordPress like W3 Total Cache.

With these configurations, your server should be ready to run both Laravel and a headless WordPress setup. Would you like to proceed with setting up WordPress, or do you need help with any of these configurations?

 

 

setting up wp / frontenbd

 

Great! Let’s set up your WordPress installation as a headless CMS to serve content via the REST API, and then we’ll move on to connecting it with your React front end.

Step 1: Ensure REST API Access is Enabled

WordPress has the REST API enabled by default. You can test it by visiting the following URL in your browser:

https://wp-flap-flap.ferociousbutterfly.com/wp-json/wp/v2/posts

This should return a JSON response containing any posts in WordPress (if you haven’t created any posts yet, it will return an empty array).

Step 2: Create Sample Content in WordPress

Before connecting WordPress to the React front end, you’ll want to create some sample content that can be fetched via the REST API.

  1. Create Posts:

    • Go to https://wp-flap-flap.ferociousbutterfly.com/wp-admin/.
    • Create a couple of test posts under Posts > Add New.
    • Publish these posts, so you can retrieve them through the API.

  2. Optional: Install Useful Plugins You might want to install some plugins to enhance the REST API or your headless setup:

    • Headless WordPress Plugin: Disable WordPress's front-end rendering and only serve content via API.
    • Custom Post Types: If you want to serve more complex content, you can create custom post types with plugins like Custom Post Type UI.

Step 3: Configure WordPress Settings for Headless Setup

To prevent users from accessing the default WordPress front end, you can install a plugin like "Disable Frontend," or use a simple redirect in your theme’s functions.php:

  1. Redirect WordPress Frontend: Add this code to your theme’s functions.php file (or create a custom plugin if preferred) to redirect all non-logged-in users to your React app:

    function redirect_to_frontend() {
    if (!is_admin() && !is_user_logged_in()) {
        wp_redirect('https://flap-flap.ferociousbutterfly.com');
        exit();
    }
}
add_action('template_redirect', 'redirect_to_frontend');

This ensures the WordPress admin is still accessible but the default front-end will be redirected.

Step 4: Setting Up the React Front End

Now, we can move on to your React front end, which will fetch content from WordPress.

  1. Set Up Axios or Fetch API: In your React project, you’ll need a way to make HTTP requests. You can use either Axios or the native Fetch API to interact with the WordPress REST API.

    Install Axios if you want to use it:

    npm install axios

  2. Create a Service to Fetch Posts from WordPress: Create a service or hook in React to fetch posts from the WordPress REST API.

    Here’s an example using Axios:

    import axios from 'axios';
import { useEffect, useState } from 'react';

const useFetchPosts = () => {
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    axios.get('https://wp-flap-flap.ferociousbutterfly.com/wp-json/wp/v2/posts')
      .then(response => {
        setPosts(response.data);
        setLoading(false);
      })
      .catch(error => {
        console.error("There was an error fetching the posts!", error);
        setLoading(false);
      });
  }, []);

  return { posts, loading };
};

export default useFetchPosts;

  3. Display Posts in a React Component: Now, use the useFetchPosts hook in your component to display the posts:

    import React from 'react';
import useFetchPosts from './useFetchPosts';  // Adjust path accordingly

const PostsList = () => {
  const { posts, loading } = useFetchPosts();

  if (loading) return <div>Loading...</div>;

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>
          <h2>{post.title.rendered}</h2>
          <div dangerouslySetInnerHTML={{ __html: post.content.rendered }} />
        </div>
      ))}
    </div>
  );
};

export default PostsList;

  4. Add PostsList to Your App: Finally, add the PostsList component to your main React app (e.g., in App.js).

    import React from 'react';
import PostsList from './components/PostsList';  // Adjust path accordingly

const App = () => {
  return (
    <div className="App">
      <PostsList />
    </div>
  );
};

export default App;

Step 5: Test the Front End

Once you've connected the React app to WordPress via the REST API, deploy the front-end changes and test fetching the posts on flap-flap.ferociousbutterfly.com.

 

scp -r /Users/spiffy/Documents/nsgandolf/dit-dah/wp-flap-flap/build/* root@45.132.241.65:/var/www/flap-flap.ferociousbutterfly.com/public/

 

 

 

laravel config

 

<VirtualHost *:80>
    ServerName flap-flap.ferociousbutterfly.com
    DocumentRoot /var/www/flap-flap.ferociousbutterfly.com/public

    <Directory /var/www/flap-flap.ferociousbutterfly.com/public>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/flap-flap.ferociousbutterfly.com_error.log
    CustomLog ${APACHE_LOG_DIR}/flap-flap.ferociousbutterfly.com_access.log combined

    # Redirect all HTTP requests to HTTPS
    RewriteEngine on
    RewriteCond %{SERVER_NAME} =flap-flap.ferociousbutterfly.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

 

 

React Config

 

<VirtualHost *:80>
    ServerName flap-flap.ferociousbutterfly.com
    DocumentRoot /var/www/flap-flap.ferociousbutterfly.com/public

    <Directory /var/www/flap-flap.ferociousbutterfly.com/public>
        AllowOverride All
        Require all granted
        Options -Indexes
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/flap-flap_error.log
    CustomLog ${APACHE_LOG_DIR}/flap-flap_access.log combined
</VirtualHost>

 

reconfigure and optimize

 

sudo a2ensite flap-flap.ferociousbutterfly.com.conf
sudo systemctl restart apache2

 

 

 

 

Step 6: (Optional) Caching and Optimization

To optimize performance:

  • Caching: Use caching strategies in React (e.g., React Query, localStorage) to reduce the number of API calls.
  • Pagination: Implement pagination if your WordPress site will have many posts.

Let me know if you'd like to dive deeper into any of these steps or need additional help with configurations!

 

 

 

Yes, you can absolutely use Advanced Custom Fields (ACF) to add custom class names to almost any element in WordPress. This approach will give you complete control over which elements receive specific class names, without relying on captions or other user-facing content.

Here’s how you can set this up:

Step 1: Create a Custom Field in ACF

  1. Install and Activate ACF if you haven’t done so already.

  2. Create a New Field Group:

    • Go to Custom Fields > Add New.
    • Name the field group something like "Element Class Names."

  3. Add a New Field:

    • Add a field called something like "Custom Class Name."
    • Set the Field Type to Text.
    • Optionally, you can add a default value or placeholder text, like "Enter class name here."

  4. Set the Location Rules:

    • Choose where this field should appear. For example, you can assign this field to posts, pages, images, or custom post types.

  5. Publish the Field Group.

Step 2: Update Your Template to Use the Custom Class Name

Now that the custom field is set up, you’ll need to modify your WordPress theme template files to use the custom class name where needed.

For example, if you’re adding a custom class to an image or a post, you can modify the relevant template like this:

Example for Posts:

In your theme’s template file (e.g., single.php, content.php, or any custom template), modify the HTML where you want the class to be applied:

<?php
// Get the custom class name from ACF
$custom_class = get_field('custom_class_name');

// If a custom class is set, apply it to the post container
?>
<div class="post-container <?php echo esc_attr($custom_class); ?>">
    <h2><?php the_title(); ?></h2>
    <div class="post-content">
        <?php the_content(); ?>
    </div>
</div>

Example for Images:

If you want to use the custom class for an image, you can modify the template where the image is displayed:

<?php
// Get the custom class name from ACF for an image
$custom_class = get_field('custom_class_name');

// Display the image with the custom class if it exists
?>
<img src="<?php echo esc_url($image_url); ?>" class="<?php echo esc_attr($custom_class); ?>" alt="<?php echo esc_attr($alt_text); ?>">

Step 3: Add Class Names in the WordPress Editor

  • When you edit a post, page, or other content type, you will now see the custom "Class Name" field that you added via ACF.
  • You can input any class name you want in this field, and it will be applied to the relevant element in the front end.

Step 4: CSS

Once you have the custom classes added via ACF, you can target them in your CSS for custom styling. For example:

.custom-class-example {
    border: 2px solid blue;
    padding: 10px;
}

.custom-image-class {
    max-width: 100%;
    border-radius: 8px;
}

Benefits of Using ACF for Class Names:

  1. Complete Control: You can specify exactly which elements get custom classes.
  2. No User Confusion: Users won’t have to deal with captions or other fields for styling. Instead, they’ll have a clean input field for class names.
  3. Flexibility: You can use this approach for any type of element—posts, images, custom post types, etc.

Summary:

Using ACF to add custom class names to WordPress elements is a great solution for controlling the design and layout without exposing user-facing content like captions. It gives you flexibility and full control over styling.

Let me know if you'd like to proceed with this setup or need more details!

 

 

Steps to Disable Root SSH Access

  1. Create or Verify a Non-Root User with sudo Privileges on the Ubuntu, Debian, or Debian-based Linux distribution.

    Create a new user

    1. Use adduser command followed by the new <username>:

    Shell

    root@server:~# adduser newuser
    1. At the prompt, enter the password for the new user twice to set and verify it.
    New password:  
Retype new password:  
passwd: password updated successfully
    1. If you want to add contact information for the new user, enter it at the prompt or press ENTER to proceed with the defaults. When you finish, enter y to verify that the entered information is correct:
    Changing the user information for newuser
Enter the new value, or press ENTER for the default
  Full Name []: New Hire
  Room Number []:
  Work Phone []:
  Home Phone []:
  Other []:
Is the information correct? [Y/n] y

    Grant root permissions for a new or existing user.

    1. Use visudo to edit the sudoers file.

      root@server:~# visudo

    Or you can just directly edit the sudoers file, by using an external editor, such as nano and vim.

    root@server:~# nano /etc/sudoers

    For detailed information, invoke man sudoers in your terminal.

    Adding the user to sudoers

    1. Add the newly created user by inserting <username> ALL=(ALL:ALL) ALL at the end of the user privilege section, as shown in the following example:

      # User privilege specification
root    ALL=(ALL:ALL) ALL
newuser ALL=(ALL:ALL) ALL

      In nano, press the CTRL+s to save and then CTRL+x to exit from nano.

    Verify the permission change

    1. Use su followed by the <username> to switch to the new user account:

      root@server:~# su - newuser  
newuser@server:~$

    2. Use sudo -i to verify that the user account can elevate permissions. At the prompt, enter the new user's password:

    newuser@server:~$ sudo -i
[sudo] password for newuser:
    1. Use whoami to verify that you are currently the root user:
    root@server:~# whoami
root

  2. Disable Root Login via SSH

    Edit the SSH configuration file (/etc/ssh/sshd_config):

    sudo nano /etc/ssh/sshd_config

    Look for the line:

    PermitRootLogin yes

    Change it to:

    PermitRootLogin no

  3. Reload or Restart the SSH Service

    After making changes, you need to reload or restart the SSH service:

    sudo systemctl reload sshd   # or
sudo systemctl restart sshd

  4. Test Access via Non-Root User Log out of the root account and attempt to SSH back into the server using your non-root user:

    ssh newusername@your-server-ip

    Once logged in, you can execute commands as root using sudo:

    sudo whoami   # should return 'root'

 

More security measures

It sounds like your server is experiencing brute-force attacks aimed at SSH. This is a common issue, but it’s important to address it to improve your server's security. Here are several steps you can take to prevent further attacks and secure your SSH access:

1. Disable Root Login via SSH

If your root account is accessible via SSH, it’s more vulnerable to brute-force attacks. You can disable root login by modifying your SSH configuration file:

  • Edit /etc/ssh/sshd_config:

    PermitRootLogin no

  • Restart the SSH service to apply the changes:

    sudo systemctl restart sshd

2. Change the Default SSH Port

Changing the default SSH port from 22 to another port can reduce the number of automated attacks.

  • In /etc/ssh/sshd_config, change the line:

    Port 22

    to something like:

    Port 2222

  • Restart the SSH service:

    sudo systemctl restart sshd

3. Use Key-based Authentication

Password-based SSH authentication is vulnerable to brute-force attacks. Switching to key-based authentication significantly increases security.

  • Generate an SSH key pair on your local machine:

    ssh-keygen

  • Copy the public key to your server:

    ssh-copy-id user@your-server-ip

  • Then, in /etc/ssh/sshd_config, disable password-based authentication:

    PasswordAuthentication no

  • Restart the SSH service:

    sudo systemctl restart sshd

4. Install Fail2Ban

Fail2Ban can help prevent repeated login attempts by blocking IPs after a certain number of failed logins.

  • Install Fail2Ban:

    sudo apt-get install fail2ban

  • By default, Fail2Ban monitors SSH and automatically bans IPs with multiple failed login attempts. You can customize the configuration in /etc/fail2ban/jail.local.

5. Enable a Firewall (UFW or iptables)

Ensure only specific IP addresses can access your SSH port by configuring a firewall.

  • Install and enable UFW (Uncomplicated Firewall):

    sudo apt-get install ufw
sudo ufw allow 2222/tcp  # or the new SSH port
sudo ufw enable

  • Alternatively, you can configure iptables to restrict access.

6. Block Specific IPs

Since you know the offending IP address (5.34.207.170), you can block it manually:

  • Use iptables to block the IP:

    sudo iptables -A INPUT -s 5.34.207.170 -j DROP

7. Use SSH Guard or Security Monitoring

Consider installing tools like SSHGuard or Lynis to keep an eye on malicious activity targeting SSH.

8. Monitor Logs

Regularly check your /var/log/auth.log or /var/log/secure (depending on your distro) for any suspicious activity. Automate monitoring with intrusion detection systems like AIDE.

Taking these steps should reduce the likelihood of future brute-force attempts and secure your server more effectively.

Let me know if you'd like further details on any specific step!

If whoami is returning root, it means you're currently operating as the root user, which gives you full control over the system. However, keeping SSH access open for the root user is not recommended for security reasons. Disabling root login over SSH is a standard security practice because the root account is a primary target for brute-force attacks, as you've already experienced with the 4305 failed login attempts.

 

The privileges and setup for secure SSH access.

1. Granting newuser SSH Access

By default, any new user can log in via SSH as long as:

  • They have a home directory (which was created when you added the user).
  • They have proper file permissions on their home directory and .ssh folder (if you're using key-based authentication).
  • Root login is disabled (which is good for security), so you will use the regular user for SSH access.

You don't need to grant special privileges to the newuser user just for SSH access. However, here are the key points to ensure it works securely:

Using Password Authentication (default)

If you're allowing SSH logins via password:

  • newuser just needs to use their password to log in via SSH:

    ssh newuser@your-server-ip

Key-based authentication is more secure than password-based authentication.

  • First, generate an SSH key pair on your local machine (if you don't have one yet):

    ssh-keygen

  • Copy the public key to the server for the newuser user:

    ssh-copy-id newuser@your-server-ip

    This will automatically place the key into /home/newuser/.ssh/authorized_keys and set the correct permissions.

    After that, you should be able to SSH into the server without a password:

    ssh newuser@your-server-ip

 

 

To use a specific SSH key (like newuser_hostinger_id_rsa) for the newuser user, you can manually copy the public key to the server. Here’s the step-by-step process to achieve this:

1. Ensure the Public Key Exists

First, verify that you have both the private (newuser_hostinger_id_rsa) and public key (newuser_hostinger_id_rsa.pub). If you don’t have the public key, you can generate it from the private key:

ssh-keygen -y -f ~/.ssh/newuser_hostinger_id_rsa > ~/.ssh/newuser_hostinger_id_rsa.pub

This will create the corresponding public key file (newuser_hostinger_id_rsa.pub).

2. Copy the Public Key to the Server Manually

You'll manually add the public key to the newuser user’s ~/.ssh/authorized_keys file on the server.

Option 1: Using ssh-copy-id with a Specific Key

If you're using ssh-copy-id, you can specify which key to use by providing the key file using the -i option:

ssh-copy-id -i ~/.ssh/spiffy_hostinger_id_rsa.pub spiffy@your-server-ip

This command will copy your specific public key to the newuser user's ~/.ssh/authorized_keys file.

Option 2: Manually Add the Key to authorized_keys

If ssh-copy-id is not available or you prefer to do it manually, follow these steps:

  1. Log in to the server as a user with access:

    ssh spiffy@your-server-ip

  2. Create the .ssh directory (if it doesn't exist):

    Run these commands to ensure the .ssh directory is properly set up:

    mkdir -p ~/.ssh
chmod 700 ~/.ssh

  3. Copy the public key manually to the authorized_keys file:

    On your local machine, copy the contents of your public key (newuser_hostinger_id_rsa.pub) to the server. You can do this by outputting the public key and adding it to the authorized_keys file on the server. For example:

    cat ~/.ssh/spiffy_hostinger_id_rsa.pub | ssh spiffy@your-server-ip 'cat >> ~/.ssh/authorized_keys'

  4. Set the proper permissions:

    Ensure that the authorized_keys file has the correct permissions:

    chmod 600 ~/.ssh/authorized_keys

3. Configure Your SSH Client to Use the Specific Key

Once the public key is installed on the server, you’ll want to configure your local machine’s SSH client to use the newuser_hostinger_id_rsa private key when connecting as the newuser user.

  • You can specify the key to use directly when connecting:

    ssh -i ~/.ssh/newuser_hostinger_id_rsa newuser@your-server-ip

  • Alternatively, you can add an entry to your ~/.ssh/config file for easier access. Edit the file and add something like this:

    Host your-server-ip
    User newuser
    IdentityFile ~/.ssh/newuser_hostinger_id_rsa

    Now, you can just type:

    ssh your-server-ip

    And it will automatically use the correct key for the newuser user.

4. Test the Connection

Finally, test that your setup is working by attempting to log in:

ssh spiffy@your-server-ip

If everything is configured correctly, you should be able to log in without a password using your specific SSH key.

Let me know if you need further assistance!

 

2. SSH Access without Root Login

Since you've disabled root login via SSH, this is the recommended workflow:

  1. Log in as newuser:

    • SSH into the server as the newuser user (either using a password or SSH key):

      ssh newuser@your-server-ip

  2. Switch to newuser-root for Administrative Tasks: Once logged in as newuser, you can switch to newuser-root using the su command (if newuser-root is an account with administrative privileges) or use sudo:

    • Switch to newuser-root:

      su - newuser-root

      Enter the password for newuser-root when prompted.

    • Alternatively, if newuser-root has sudo privileges, you can perform admin tasks directly as newuser using sudo:

      sudo command_to_run_as_root

3. Grant newuser User sudo Privileges (Optional)

If you want newuser to have administrative privileges, you can add the newuser user to the wheel or sudo group. This allows newuser to use sudo to execute commands with root privileges:

sudo usermod -aG wheel newuser  # or use 'sudo' group depending on your system

This will allow newuser to run sudo commands directly after logging in via SSH. Example:

ssh newuser@your-server-ip
sudo whoami   # should return 'root'

4. Disable Password Authentication (Optional, for Key-based Security)

If you're using SSH key-based authentication, it’s a good idea to disable password authentication entirely to improve security:

  • Edit the SSH configuration file /etc/ssh/sshd_config:

    sudo nano /etc/ssh/sshd_config

  • Set the following options (if not already set):

    PasswordAuthentication no
PermitRootLogin no

  • Restart SSH to apply the changes:

    sudo systemctl restart sshd

This will ensure that only users with a valid SSH key can log in, and root login will still be disabled.

Recap:

  • You log in as the newuser user via SSH (with password or key).
  • If you need root privileges, you can either switch to newuser-root using su - newuser-root or configure newuser to use sudo directly.
  • For better security, prefer key-based SSH login and disable password authentication.
Scroll to Top