Tag: ssh

SSH (Secure Shell) relies on public-key cryptography for secure logins. But how can you be sure your public and private key pair are actually linked? This blog post will guide you through a simple method to verify their authenticity in Linux and macOS.

Understanding the Key Pair:

Imagine a lock and key. Your public key acts like the widely distributed lock – anyone can see it. The private key is the unique counterpart, kept secret, that unlocks the metaphorical door (your server) for SSH access.

Using ssh-keygen

This method leverages the ssh-keygen tool, already available on most Linux and macOS systems.

1. Locate the keys :Open a terminal and use cd to navigate to the directory where your private key resides (e.g., cd ~/.ssh).
2. Use the command ‘ls -al’ to list all files in the directory, and locate your private/public keypair you wish to check.

Example:

ababwaha@ababwaha-mac .ssh % ls -al
total 32
drwx------   6 ababwaha  staff   192 Jun 24 16:04 .
drwxr-x---+ 68 ababwaha  staff  2176 Jun 24 16:04 ..
-rw-------   1 ababwaha  staff   411 Jun 24 16:04 id_ed25519 
-rw-r--r--   1 ababwaha  staff   103 Jun 24 16:04 id_ed25519.pub    
-rw-------   1 ababwaha  staff  3389 Jun 24 16:04 id_rsa            
-rw-r--r--   1 ababwaha  staff   747 Jun 24 16:04 id_rsa.pub

3. Verify the Key Pair: Run the following command, replacing with the actual path to your private key file (e.g., ssh-keygen -lf ~/.ssh/id_rsa):

ssh-keygen -lf ssh-keygen -lf

This command displays fingerprint information about your key pair.

ababwaha@ababwaha-mac .ssh % ssh-keygen -l -f id_rsa
4096 SHA256:7qXL09ejiSkrKs8HfhEo8EXkUVFOsoPfv52QY/l/kzg ababwaha@ababwaha-mac (RSA)
ababwaha@ababwaha-mac .ssh % ssh-keygen -l -f id_rsa.pub 
4096 SHA256:7qXL09ejiSkrKs8HfhEo8EXkUVFOsoPfv52QY/l/kzg ababwaha@ababwaha-mac (RSA)
ababwaha@ababwaha-mac .ssh % 
ababwaha@ababwaha-mac .ssh % 
ababwaha@ababwaha-mac .ssh % 
ababwaha@ababwaha-mac .ssh % ssh-keygen -l -f id_ed25519
256 SHA256:4pWu5rdA1IvbbjD7/k4/k/7A4X6kft28MpKL1HMqmgQ ababwaha@ababwaha-mac (ED25519)
ababwaha@ababwaha-mac .ssh % ssh-keygen -l -f id_ed25519.pub 
256 SHA256:4pWu5rdA1IvbbjD7/k4/k/7A4X6kft28MpKL1HMqmgQ ababwaha@ababwaha-mac (ED25519)
ababwaha@ababwaha-mac .ssh %

4. Match the Fingerprints: Compare the fingerprint displayed by ssh-keygen with the beginning of the text in your public key file. If they match, congratulations! Your public and private keys are a verified pair.

Remember:

Security: Always keep your private key secure. Avoid storing it on publicly accessible locations.

Permissions: Ensure your private key file has appropriate permissions (usually 600) to prevent unauthorized access.

By following this method, you can easily verify the authenticity of your public and private SSH key pair, ensuring a secure connection to your server.

Securing Your Connections: A Guide to SSH Key authentication

By wahab

On December 12, 2023

In Devops, Linux server

Securing Your Connections: A Guide to SSH Keys

SSH (Secure Shell) is a fundamental tool for securely connecting to remote servers. While traditional password authentication works, it can be vulnerable to brute-force attacks. SSH keys offer a more robust and convenient solution for secure access.

This blog post will guide you through the world of SSH keys, explaining their types, generation process, and how to manage them for secure remote connections and how to configure SSH key authentication.

Understanding SSH Keys: An Analogy
Imagine your home has two locks:

Combination Lock (Password): Anyone can access your home if they guess the correct combination.

High-Security Lock (SSH Key): Only someone with a specific physical key (your private key) can unlock the door.

Similarly, SSH keys work in pairs:

Private Key: A securely stored key on your local machine. You never share this.

Public Key: A unique identifier you share with the server you want to access.
The server verifies the public key against your private key when you attempt to connect. This verification ensures only authorized users with the matching private key can access the server.

Types of SSH Keys
There are many types of SSH keys, we are discussing the two main ones:

RSA (Rivest–Shamir–Adleman): The traditional and widely supported option. It offers a good balance of security and performance.
Ed25519 (Edwards-curve Digital Signature Algorithm): A newer, faster, and potentially more secure option gaining popularity.

RSA vs. Ed25519 Keys:

Security: Both are considered secure, but Ed25519 might offer slightly better theoretical resistance against certain attacks.

Performance: Ed25519 is generally faster for both key generation and signing/verification compared to RSA. This can be beneficial for slower connections or resource-constrained devices.

Key Size: RSA keys are typically 2048 or 4096 bits, while Ed25519 keys are 256 bits. Despite the smaller size, Ed25519 offers comparable security due to the underlying mathematical concepts.

Compatibility: RSA is widely supported by all SSH servers. Ed25519 is gaining popularity but might not be universally supported on older servers.

Choosing Between RSA and Ed25519:

For most users, Ed25519 is a great choice due to its speed and security. However, if compatibility with older servers is a critical concern, RSA remains a reliable option.

Generating SSH Keys with ssh-keygen
Here’s how to generate your SSH key pair using the ssh-keygen command:

Open your terminal.

Run the following command, replacing with your desired name for the key pair:

ssh-keygen -t <key_type> -b 4096 -C "<your_email@example.com>"

<key_type>: Choose either rsa or ed25519.

-b 4096: Specifies the key size (4096 bits is recommended for strong security).

-C “<your_email@example.com”>: Adds a comment to your key (optional).

You’ll be prompted to enter a secure passphrase for your private key. Choose a strong passphrase and remember it well (it’s not mandatory, but highly recommended for added security).

The command will generate two files:

<key_name>>.pub: The public key file (you’ll add this to the server).
<key_name>>: The private key file (keep this secure on your local machine).

Important Note: Never share your private key with anyone!

Adding Your Public Key to the Server’s authorized_keys File

Access the remote server you want to connect to (through a different method if you haven’t set up key-based authentication yet).
Locate the ~/.ssh/authorized_keys file on the server (the ~ represents your home directory). You might need to create the .ssh directory if it doesn’t exist.
Open the authorized_keys file with a text editor.
Paste the contents of your public key file (.pub) into the authorized_keys file on the server.
Save the authorized_keys file on the server.

Permissions:

Ensure the authorized_keys file has permissions set to 600 (read and write access only for the owner).

Connecting with SSH Keys
Once you’ve added your public key to the server, you can connect using your private key:

ssh <username>@<server_address>

You’ll be prompted for your private key passphrase (if you set one) during the connection. That’s it! You’re now securely connected to the server without needing a password.

Benefits of SSH Keys:

Enhanced Security: More secure than password authentication, making brute-force attacks ineffective.

Convenience: No need to remember complex passwords for multiple servers.

Faster Logins: SSH key-based authentication is often faster than password authentication.

By implementing SSH keys, you can significantly improve the security and convenience of your remote server connections. Remember to choose strong passwords and keep your private key secure for optimal protection.

Problems logging into Plesk because of IP restrictions

By wahab

On June 29, 2016

In Linux server, Plesk

Hello,

If you receive following error while logging to the Plesk panel, that means there is a IP based restriction to access Plesk admin panel and your current IP is not allowed to access.

“Unable to log into Plesk: Access for administrator from address xx.xx.xx.xx is restricted in accordance with IP Access restriction policy currently applied”

Cause
Plesk IP access policy was configured in such a way so that Plesk could not be accessed from the certain IP.

Resolution

Method 1. To enable Plesk access, you need to log into the Plesk from another IP and change the IP access policy:

Tools and Settings > Restrict Administrative Access
Add your IP to the whitelist

Method 2. Updating the database directly

If you cannot login to the panel, then you can connect to the server using SSH and correct this through database queries. Plesk database records regarding the access policy need to be corrected.

To retrieve the current policy and the restricted/allowed IPs, the following commands can be used:

Linux

#MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa
    mysql> select * from cp_access;
    mysql> select * from misc where param='access_policy';

Windows

"%plesk_bin%\dbclient" --direct-sql --sql="select * from cp_access"
    "%plesk_bin%\dbclient" --direct-sql --sql="select * from misc where param='access_policy'";

If you wish to clear the access policy settings, remove all records from “cp_access” and set the policy to “allow”:

Linux

# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa
    mysql> delete from cp_access;
    mysql> update misc set val="allow" where param='access_policy';

Windows

"%plesk_bin%\dbclient" --direct-sql --sql="delete from cp_access";
    "%plesk_bin%\dbclient" --direct-sql --sql="update misc set val='allow' where param='access_policy'";

To whitelist the IP manually

bash# mysql -uadmin -p`cat /etc/psa/.psa.shadow ` psa

insert into cp_access values ("", "deny", "x.x.x.", "255.255.255.255"); //change the IP address to your public IP.

Then you should be able to connect to the Plesk control panel from the new IP address.

Plesk to cPanel Manual migration

By wahab

On June 24, 2013

In Cpanel and WHM, Plesk

Migrating accounts manually is a surprisingly simple task. All that needs to be done are the following:

Populate /etc/trueuserdomains on the source server
Package an account of your choice into a single file
Copy the packaged account to the cPanel server
Restore the account on the cPanel server

Steps:-

1. On the source server (Plesk), download the script that builds the list of accounts at /etc/trueuserdomains:

# wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/updateuserdomains-universal

and the script that packages the accounts:

#wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/packages-pXa


2. Make them both of the scripts executable:

# chmod +x updateuserdomains-universal
# chmod +x pkgacct-*


3. Execute updateuserdomains-universal:

# ./updateuserdomains-universal
Now there should be a plain text file at /etc/trueuserdomains that contains a list of accounts that can be packaged.

4. To package an account, select a user from /etc/trueuserdomains (we'll use "alice" in the example below), and run the pkgacct script that we downloaded in the first step.

# ./pkgacct-pXa alice

his will package the entire account to a single file here:
/home/cpmove-alice.tar.gz

The amount of time that this process takes will depend on the size of the account. I would strongly advise running the "screen" command before packaging (and restoring) accounts. This will allow the package/restore processes to continue even if you get disconnected from the server.

Also, if the /home directory is too small, you can specify which partition to use like this:

# ./pkgacct-pXa alice /disk1

where "/disk1" is only an example, and likely does not exist on your server. If it did, and if you ran that command, then you would end up with a file here:

/disk1/cpmove-alice.tar.gz

5. Copy the archive to the new server by running this from the source server:

# scp /home/cpmove-alice.tar.gz root@x.x.x.x:/home

6. On the cPanel server, after running "screen" (if you choose to use screen), run these commands to restore the account:
# cd /home

# /scripts/restorepkg cpmove-alice.tar.gz

Leave a comment if you have any doubts
Thanks!