Passwordless SSH Login to VPS Server Using Windows

Md.Tarikul — Sat, 24 Aug 2024 10:42:24 +0000

This guide will walk you through the steps to set up passwordless SSH login to your VPS server from a Windows machine.

1. Generate SSH Key on Your Local Machine
Start by creating an SSH key on your local Windows machine. This key will be used to authenticate your login to the VPS server without needing a password.
bash
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Explanation:
-t rsa: Specifies the type of key to create, RSA in this case.
-b 4096: The key size in bits (4096 is a strong key size).
-C "your_email@example.com": Adds a comment to the key, usually your email.
Output: This command generates two files:
id_rsa: Your private key (keep this secure and do not share it).
id_rsa.pub: Your public key (this will be copied to the VPS server).

2. Verify SSH Key Creation
Check if your SSH key has been created successfully by navigating to the .ssh directory on your local machine.
Location:
plaintextC:\Users\tarik\.ssh

Expected Files: Look for the id_rsa.pub file. If it exists, your key was created successfully.

3. Log In to Your VPS Server
Use the following command to log in to your VPS server. This initial login will still require your password.
bash
ssh root@your_vps_ip

Note: Replace your_vps_ip with the actual IP address of your VPS server.
First-Time Login:
You may be prompted to verify the server’s fingerprint. Type yes to continue.
Enter your VPS password when prompted.

4. Check or Create the .ssh Directory on the VPS
Once logged in, check if the .ssh directory exists on your VPS server.
Check for .ssh Directory:

ls -a

Explanation: This command lists all files, including hidden ones (files beginning with a dot, like .ssh).
Or Use:
ls -ld ~/.ssh

Output if .ssh Exists:
plaintext
drwx------ 2 user user 4096 Aug 24 12:34 /root/.ssh

Output if .ssh Does Not Exist:
ls: cannot access '/root/.ssh': No such file or directory

Create the .ssh Directory (If Needed): If the .ssh directory does not exist, create it with the following command:
mkdir -p ~/.ssh

Set Correct Permissions:
chmod 700 ~/.ssh

Explanation:
mkdir -p ~/.ssh: Creates the .ssh directory, including any necessary parent directories.
chmod 700 ~/.ssh: Sets the directory's permissions so only the owner (you) can read, write, and execute.

5. Copy Your Public Key to the VPS
Now, copy your public key (id_rsa.pub) from your Windows machine to the VPS server. This step allows passwordless authentication.
Command:
`:=>nano ~/.ssh/authorized_keys
=>Add the new key to the file by pasting it at the end of the file on a new line.

=>Save and exit the file in Nano:

Press Ctrl + O to save.
Press Enter to confirm the file name.
Press Ctrl + X to exit.`

6. Log In Without a Password
Now, you should be able to log in to your VPS server without entering a password.
Command:
ssh root@74.208.202.89

If everything is set up correctly, you’ll be logged in without needing to enter a password.

MongoDB Schema Design, Indexes & More Best Practices

Md.Tarikul — Tue, 16 Jul 2024 02:49:16 +0000

Schema Design Approaches – Relational vs. MongoDB:
Relational Databases: Best for applications requiring complex queries, transactions, and data integrity. Ideal for structured data and systems where schema stability is important (e.g., financial applications, ERP systems).
MongoDB: Best for applications requiring scalability, flexibility, and rapid development. Ideal for handling large volumes of unstructured or semi-structured data, real-time analytics, and applications where data structures evolve frequently (e.g., content management systems, IoT applications).

Embedding vs. Referencing:

Embedding
Example:
Imagine a blog application where each post has comments.

{ "_id": 1, "title": "First Post", "content": "This is the content of the first post", "comments": [ { "user": "Alice", "comment": "Great post!", "date": "2024-07-16" }, { "user": "Bob", "comment": "Thanks for sharing!", "date": "2024-07-17" } ] }

Advantages:

Performance: Faster read operations since related data is stored together.
Atomicity: Updates to a document are atomic, ensuring consistency.
Simplicity: Easy to manage and query related data within a single document.
Limitations:

Document Size: Limited to 16 MB, so embedding large amounts of related data can exceed this limit.
Data Redundancy: Duplicating data in multiple places can lead to inconsistencies and increased storage usage.

Referencing
Example:
Using the same blog application, comments are stored in a separate collection.

Posts Collection:
{ "_id": 1, "title": "First Post", "content": "This is the content of the first post", "comments": [ 101, 102 ] }
Comments Collection:
{ "_id": 101, "user": "Alice", "comment": "Great post!", "date": "2024-07-16", "postId": 1 } { "_id": 102, "user": "Bob", "comment": "Thanks for sharing!", "date": "2024-07-17", "postId": 1 }
Advantages:

Flexibility: No size limit issues as comments grow.
Data Normalization: Reduces data redundancy and potential inconsistencies.
Scalability: Easier to manage large volumes of related data.
Limitations:

Complexity: More complex queries to fetch related data, requiring joins.
Performance: Slower read operations since data is spread across multiple documents.
Atomicity: Updates to related data across multiple documents are not atomic, which can lead to inconsistencies.

Recap:

One-to-One - Prefer key value pairs within the document
One-to-Few - Prefer embedding
One-to-Many - Prefer embedding
One-to-Squillions - Prefer Referencing
Many-to-Many - Prefer Referencing

General Rules for MongoDB Schema Design:

Rule 1:
Favor embedding unless there is a compelling reason not to.
Rule 2:
Needing to access an object on its own is a compelling reason not to embed it.
Rule 3:
Avoid joins and lookups if possible, but don't be afraid if they can provide a better schema design.
Rule 4:
Arrays should not grow without bound. If there are more than a couple of hundred documents on the many side, don't embed them; if there are more than a few thousand documents on the many side, don't use an array of ObjectID references. High-cardinality arrays are a compelling reason not to embed.
Rule 5:
As always, with MongoDB, how you model your data depends entirely on your particular application's data access patterns. You want to structure your data to match the ways that your application queries and updates it.

Relationships

One-to-One:

Let's take a look at our User document. This example has some great one-to-one data in it. For example, in our system, one user can only have one name. So, this would be an example of a one-to-one relationship. We can model all one-to-one data as key-value pairs in our database.
{ "_id": "ObjectId('AAA')", "name": "Joe Karlsson", "company": "MongoDB", "twitter": "@JoeKarlsson1", "twitch": "joe_karlsson", "tiktok": "joekarlsson", "website": "joekarlsson.com"}

One-to-Few:

Okay, now let's say that we are dealing a small sequence of data that's associated with our users. For example, we might need to store several addresses associated with a given user. It's unlikely that a user for our application would have more than a couple of different addresses. For relationships like this, we would define this as a one-to-few relationship.
{ "_id": "ObjectId('AAA')", "name": "Joe Karlsson", "company": "MongoDB", "twitter": "@JoeKarlsson1", "twitch": "joe_karlsson", "tiktok": "joekarlsson", "website": "joekarlsson.com", "addresses": [ { "street": "123 Sesame St", "city": "Anytown", "cc": "USA" }, { "street": "123 Avenue Q", "city": "New York", "cc": "USA" } ] }

One-to-Many:

Alright, let's say that you are building a product page for an e-commerce website, and you are going to have to design a schema that will be able to show product information. In our system, we save information about all the many parts that make up each product for repair services. How would you design a schema to save all this data, but still make your product page performant? You might want to consider a one-to-many schema since your one product is made up of many parts.

Product
{ "name": "left-handed smoke shifter", "manufacturer": "Acme Corp", "catalog_number": "1234", "parts": ["ObjectID('AAAA')", "ObjectID('BBBB')", "ObjectID('CCCC')"] }

Parts
{ "_id" : "ObjectID('AAAA')", "partno" : "123-aff-456", "name" : "#4 grommet", "qty": "94", "cost": "0.94", "price":" 3.99" }

One-to-Squillions:

What if we have a schema where there could be potentially millions of subdocuments, or more? That's when we get to the one-to-squillions schema. And, I know what you're thinking: Is squillions a real word?
And the answer is yes, it is a real word.
Let's imagine that you have been asked to create a server logging application. Each server could potentially save a massive amount of data, depending on how verbose you're logging and how long you store server logs for.

hosts
{ "_id": ObjectID("AAAB"), "name": "goofy.example.com", "ipaddr": "127.66.66.66" }

Log messages
{ "time": ISODate("2014-03-28T09:42:41.382Z"), "message": "cpu is on fire!", "host": ObjectID("AAAB") }

Many-to-Many:

The last schema design pattern we are going to be covering in this post is the many-to-many relationship. This is another very common schema pattern that we see all the time in relational and MongoDB schema designs. For this pattern, let's imagine that we are building a to-do application. In our app, a user may have many tasks and a task may have many users assigned to it.
todo_9ddb687d61
In order to preserve these relationships between users and tasks, there will need to be references from the one user to the many tasks and references from the one task to the many users. Let's look at how this could work for a to-do list application.

users:
{ "_id": ObjectID("AAF1"), "name": "Kate Monster", "tasks": [ObjectID("ADF9"), ObjectID("AE02"), ObjectID("AE73")] }

tasks:
{ "_id": ObjectID("ADF9"), "description": "Write blog post about MongoDB schema design", "due_date": ISODate("2014-04-01"), "owners": [ObjectID("AAF1"), ObjectID("BB3G")] }

Optimising query patterns:

Optimizing your query patterns is crucial for reducing execution time and resource usage:

Projection:
Use projection to limit the fields returned by your queries, minimizing data transfer and processing load. Also, it’s better to exclude _id with 0 (false) if it’s not a field pertaining to the application — i.e., an auto-generated field by MongoDB. db.collection.find({ field: value }, { field1: 1, field2: 1 })
Aggregation framework:
Leverage MongoDB's
aggregation framework for complex data processing. Ensure aggregations utilize indexed fields where possible.
db.collection.aggregate([ { $match: { field: value } }, { $group: { _id: "$field", total: { $sum: "$amount" } } } ])
Avoid $where:
The $where operator can be slow and resource-intensive. Use it sparingly and only when necessary. Instead, the use of $expr with aggregation operators that do not use JavaScript (i.e., non-$function and non-$accumulator operators) is faster than $where because it does not execute JavaScript and is preferable, when possible. However, if you must create custom expressions, $function is preferred over $where.

Summary:

As you can see, there are a ton of different ways to express your schema design, by going beyond normalizing your data like you might be used to doing in SQL. By taking advantage of embedding data within a document or referencing documents using the $lookup operator, you can make some truly powerful, scalable, and efficient database queries that are completely unique to your application. In fact, we are only barely able to scratch the surface of all the ways that you could model your data in MongoDB.

DEV Community: Md.Tarikul