r id="header">

Mistakes holding you back from becoming a millionaire.


  • 2017-02-03
  • Vaibhav Sharma
  • 0

This blog is not for thinkers who have left everything behind and are wandering in the himalayas in search of divine pathways, this blog is for those businesspersons who are working hard and still finding it a great deal to achieve their desired goals, this blog is for those who form the basis for those bigger goals.

There are many people like you in this world and no i am not talking about doppelgangers, i am talking about the people who are running the same business as you are but are running it better and earning more then you. So, why is their business more prosperous and profitable, do their employees have superpowers or do their machinery is blessed by god to produce more, or maybe they hypnotize their customers to buy more and more products.  No, they are neither blessed nor they hypnotize customers they just follow one simple principle "Always Work Hard And Think Out Of The Box", if this is the case then you surely need to wake up now and if not then their is only one conclusion that you are happy with what you have and you have a symptom of disease i.e. "Satisfaction Symptom", worst disease a businessperson can have. 

What if you are working hard, thinking out of the box and at the same time wants to achieve more and are not satisfied with present but wants a beautiful tomorrow, but your business is rigid and not moving forward. Well in that case it's time to jolt your head and think about what's that thing which is coming in between you, your fame, and your millions. May be its your management, maybe its your employees, or maybe its you yourself who is resisting to change.

Your business is standing tall on four pillars :

  • Marketing
  • Management
  • Sale
  • Communication

It may be the case that one or more of these pillars is broken or have some trouble, which is stopping you from achieving your ultimate goal.

So what is the solution? Solution is using the right set of tools to establish a synchronization between various business processes.

Before jumping deep into the solution let's first see basic workflow of service based business and almost every startup :

  • Digital marketing (Newsletters, social marketing)
  • Converting leads to customers
  • Maintaining proper Follow-ups
  • Centrally managed customer communication
  • Sales (quotation, order, invoice)
  • Customer Relations

Now, how does this workflow be better managed and automated by using tools like epan.in,  let's see : 

1) Digital Marketing : Doing digital marketing (Content marketing) allows you to sit back and relax to see your customers coming to you rather then you pulling them. In todays era we can say that "the fortune is in the hands of digital marketing".


 

2) Follow-ups : It's true that we all lead busy life but missing an important event like meeting, call can lead into a loss of opportunity. Following up your customers or leads is as important as making a good product or proving a service.



3) Communication : Communication is an indispensable part of business. Effective communication equals good working relationship between you, your staff and your clients/customers. 




4) Sales : Sales cover a way lot bigger domain then just selling a product or service to customer, it includes proper document management like quotation, invoice, orders etc, proper integration with accounts and production in some cases.





Last but not the least : "Commit To Doing Something Every Day To Grow Your Business.

Read More

Can You Hear Me?


  • 2017-01-18
  • Vaibhav Sharma
  • 0
"Communication (from Latin comm?nic?re, meaning "to share"[1]) is the act of conveying intended meanings from one entity or group to another through the use of mutually understood signs and semiotic rules." - Wikipedia

When you were born, you cried, don't know why. May be you were trying to convey that you don't like this transition or maybe it's just a scientific process which you preferred for breathing for the first time. Then it all started, crying before sleeping, after waking up, when hungry, when bored and even in the middle of the night.

"Icky jammies : disgusting pajamas" well this is how you communicated when you were a toddler. During that time you were a creature who is used to ignore a call to it's own name but can hear a bag of chips being opened in a thunderstorm.

Communication is way lot more important, The Bhagavad Gita : Hindu scripture which is the deepest source of spiritual knowledge is based upon the dialog exchanged between Arjuna and lord Krishna.
 
When we don't communicate, we communicate that we don't want to communicate. So, basically we are communicating even when we don't, thats crazy !

When there was no language, no civilization at that time people were communicating by making drawings in cave.

The only reason they communicated is to tell us that "they were there when it happened and it was beautiful". In todays world those caveman are roaming around with a selfie stick in hand (#I was there
#beautiful).

The best use of communication can only be seen in politics. From asking for votes to making policies to communicating their benefits to the people, communication comes handy.


Vote for me because i love peanut butter sandwiches and also sandwiches filled with peanut butter.


TaDa ! it's marketing time : You know we love you so much and we won't waste your time. So, let's see what we have in our basket for your business.

Communication is an indispensable part of business. Effective communication equals good working relationship between you, your staff and your clients/customers. So, here we present Epan Services Communication Application which comes up with features like : Multiple email management system, communication filtering based upon customers, leads, suppliers, post based email permissions to employees. 





Internal communication to avoid mails from office to office.

Want to know about Epan Services and it's features, visit www.epan.in/features 

Missed something? Let me know in the comments and I'll add it in !
Read More

How To Set Up MariaDB Master-Master Replication


  • 2016-07-30
  • Vijay Mali
  • 0


Intro

The simplest and probably most common replication method is master-slave replication. Basically, data is replicated from master database to the slave. In case of master database failure you must get the slave database up-to-date before failover and then promote slave to be new master.

Another method is to set up replication in both directions called master-master replication. But you must be aware that this setup brings some potential issues as data changes are happening on both nodes. It could be problem if you have tables with auto_increment fields. If both servers are inserting or updating in the same table replication will break on one server due to “duplicate entry” error. To resolve this issue you have "auto_increment_increment" and "auto_increment_offset" settings.

In my case its best to use master-master setup as active-passive replication. If we know that only one node is performing data modifications we can avoid many possible problems. In case of the failover "slave" could be easily promoted to a new master. Data modifications are automatically replicated to failed node when it comes back up.

Of course, this simple setup is not suitable for all situations and it has it's drawbacks but luckily you have several other options at your disposal, like MariaDB Galera Cluster.

 

 

Install MariaDB 10 (both nodes (Server1 , Server2 )  ).

The examples in this article will be based on two VPS, named Server 1 and Server 2.

Server 1

Server 2

Install MariaDB 10.1 on Ubuntu14.04/15.10/16.04

I always like to install software packages from official repository (if there’s one) rather than from my Linux distribution repository. For one thing, I can install the latest stable version. For another, I don’t have to worry about distribution specific modifications. In other words, what I got is a bog-standard package no matter what Linux distribution I use.

This tutorial will guide you through the process of installing the latest stable version of MariaDB and that’s MariaDB 10.1 on Ubuntu 14.04 and 15.10, 16.04. Ubuntu repository has MariaDB 10.0, but no MariaDB 10.1.

Step1: Install software-properties-common

$ sudo apt-get install software-properties-common

Step2: Fetch MariaDB signing key from Ubuntu’s key server.

$ apt-key adv --keyserver ha.pool.sks-keyservers.net --recv-keys F1656F24C74CD1D8

Step3: add MariaDB repository to your system.
ubuntu 14.04

$ sudo add-apt-repository 'deb [arch=amd64,i386] http://sgp1.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu trusty main'

ubuntu 15.10

$ sudo add-apt-repository 'deb [arch=amd64,i386] http://sgp1.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu wily main'

Ubuntu 16.04

$ sudo add-apt-repository 'deb [arch=amd64,i386] http://sgp1.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'

Step4: Update server

$ sudo apt-get update

Step4: Update server

$ sudo apt-get install mariadb-server

You will be asked to set a password for the MariaDB root user.



After it’s installed, mysqld process will be automatically started.

Check version

root@server1:~# mysql --version
Output:
mysql Ver 15.1 Distrib 10.1.16-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

root@server1:~#

Finally we should execute the secure installation script to remove anonymous user, disable remote root login and remove test database for security reasons.

root@server1:~# mysql_secure_installation

You will be asked these questions:
Enter current password for root (enter for none): press enter
Set root password? [Y/n] y
New password: Re-enter new password: Repeat the password
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] <-- y
Reload privilege tables now? [Y/n] y

Test the login to MariaDB with the "mysql command"

root@server1:~# mysql -uroot -p
Output:

Welcome to the MariaDB monitor. Commands end with ; or \g
Your MariaDB connection id is 9
Server version: 10.1.16-MariaDB-1~xenial mariadb.org binary distribution
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

To leave the MariaDB shell, enter the command "quit" and press enter.

Stop MariaDB on both nodes:

 
root@server1:~# sudo service mysql stop

MASTER1
Edit /etc/mysql/my.cnf parameter file.

root@server1:~# nano /etc/mysql/my.cnf

# bind-address = 127.0.0.1
server-id = 61
report_host = master1
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
relay_log = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
# replicate-do-db = testdb


# bind-address = 127.0.0.1
By default mysql will accept connections only from local host. We will comment this line to enable connections from other hosts. This is important for replication to work.

server-id = 1
report_host = server1
Choose ID that will uniquely identify your host. I will use last two digits of my IP address. Optionally you could set report_host parameter for servers to report each other their hostnames.

log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
Enable binary logging.

relay_log = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
Enable creating relay log files. Events that are read from master’s binary log are written to slave relay log.

replicate-do-db = testdb
With this parameter we are telling to MariaDB which databases to replicate. This parameter is optional.

Now we can start MariaDB server.

root@server1:~# sudo service mysql start
Login as root and create user that will be used for replicating data between our servers. Grant appropriate privileges to the user.
 
root@server1:~# sudo mysql -uroot -p
MariaDB [(none)]> create user 'replusr'@'%' identified by 'replusr';
MariaDB [(none)]> grant replication slave on *.* to 'replusr'@'%';
MariaDB [(none)]> show master status;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000009 | 634 | | |
+--------------------+----------+--------------+------------------+

MASTER2
Edit /etc/mysql/my.cnf parameter file.

root@server2:~# nano /etc/mysql/my.cnf
# bind-address = 127.0.0.1
server-id = 2
report_host = server2
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
relay_log = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
# replicate-do-db = testdb
 


Start MariaDB server.

root@server2:~# sudo service mysql start

Create user which will be used for replication and grant privileges to the user.

root@server2:~# sudo mysql -uroot -p
MariaDB [(none)]> create user 'replusr'@'%' identified by 'replusr';
MariaDB [(none)]> grant replication slave on *.* to 'replusr'@'%';

To start replication enter following commands.

 MariaDB [(none)]> STOP SLAVE;

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='server1', MASTER_USER='replusr',
-> MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000009', MASTER_LOG_POS=634;

MariaDB [(none)]> START SLAVE;

For MASTER_LOG_FILE and MASTER_LOG_POS I have used information from "show master status" on the first node.

Check status information of the slave threads.

 MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: server1
Master_User: replusr
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000009
Read_Master_Log_Pos: 634
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 537
Relay_Master_Log_File: mariadb-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 634
Relay_Log_Space: 828
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:

Notice that Read_Master_Log_Pos and Exec_Master_Log_Pos are in sync which is good indicator that our databases are in sync.


Check status information about binary log files of the MASTER2 node. We will need this information to start replication on MASTER1 node.

 MariaDB [(none)]> show master status;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000009 | 759 | | |
+--------------------+----------+--------------+------------------+


MASTER1

Start replicating data from MASTER2 to MASTER1 node.

MariaDB [(none)]> STOP SLAVE;

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='server2', MASTER_USER='replusr',
-> MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000009', MASTER_LOG_POS=759;

MariaDB [(none)]> START SLAVE;

 

MariaDB [(none)]> STOP SLAVE;MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: server2
Master_User: replusr
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000009
Read_Master_Log_Pos: 759
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 537
Relay_Master_Log_File: mariadb-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 759
Relay_Log_Space: 828
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 62
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:

Everything seems to be OK.


Let’s create test table and insert some rows to test our replication.

 

Master1

MariaDB [(none)]> create database testdb;

MariaDB [(none)]> use testdb;
Database changed

MariaDB [testdb]> CREATE TABLE users (id INT AUTO_INCREMENT,
-> name VARCHAR(30),
-> datum TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
-> PRIMARY KEY(id));
Query OK, 0 rows affected (0.50 sec)

MariaDB [testdb]> INSERT INTO users(name) VALUES ('Marko');
Query OK, 1 row affected (0.06 sec)

MariaDB [testdb]> select * from users;
+----+-------+---------------------+
| id | name | datum |
+----+-------+---------------------+
| 1 | Marko | 2015-02-01 00:41:41 |
+----+-------+---------------------+
1 row in set (0.00 sec)

Master2

 MariaDB [testdb]> use testdb
Database changed

MariaDB [testdb]> select * from users;
+----+-------+---------------------+
| id | name | datum |
+----+-------+---------------------+
| 1 | Marko | 2015-02-01 00:41:41 |
+----+-------+---------------------+
1 row in set (0.00 sec)

MariaDB [testdb]> INSERT INTO users(name) VALUES('John');
Query OK, 1 row affected (0.39 sec)

MariaDB [testdb]> select * from users;
+----+-------+---------------------+
| id | name | datum |
+----+-------+---------------------+
| 1 | Marko | 2015-02-01 00:41:41 |
| 2 | John | 2015-01-31 16:17:55 |
+----+-------+---------------------+
2 rows in set (0.00 sec)

Master1

MariaDB [testdb]> select * from users;
+----+-------+---------------------+
| id | name | datum |
+----+-------+---------------------+
| 1 | Marko | 2015-02-01 00:41:41 |
| 2 | John | 2015-01-31 16:17:55 |
+----+-------+---------------------+
2 rows in set (0.00 sec)

As we can see our table and rows are replicated successfully.



Let’s simulate crash of the MASTER1 node and power off the server.

root@server1:~# sudo shutdown -h now

 

While server is down insert some rows on MASTER2 node.

Master2

MariaDB [testdb]> INSERT INTO users(name) VALUES ('Eric');
Query OK, 1 row affected (0.41 sec)

MariaDB [testdb]> INSERT INTO users(name) VALUES ('Clive');
Query OK, 1 row affected (0.08 sec)

MariaDB [testdb]> INSERT INTO users(name) VALUES ('Maria');
Query OK, 1 row affected (0.09 sec)

MariaDB [testdb]> select * from users;
+----+-------+---------------------+
| id | name | datum |
+----+-------+---------------------+
| 1 | Marko | 2015-02-01 00:41:41 |
| 2 | John | 2015-01-31 16:17:55 |
| 3 | Eric | 2015-01-31 16:19:49 |
| 4 | Clive | 2015-01-31 16:19:55 |
| 5 | Maria | 2015-01-31 16:20:01 |
+----+-------+---------------------+
5 rows in set (0.00 sec)
MariaDB [testdb]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Reconnecting after a failed master event read
Master_Host: server1
Master_User: replusr
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000010
Read_Master_Log_Pos: 1828
Relay_Log_File: relay-bin.000012
Relay_Log_Pos: 1083
Relay_Master_Log_File: mariadb-bin.000010
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1828
Relay_Log_Space: 1663
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2003
Last_IO_Error: error reconnecting to master 'replusr@master1:3306' - retry-time:
60 retries: 86400 message: Can't connect to MySQL server
on 'master1' (111 "Connection refused")
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:

Check Last_IO_Error message while MASTER1 is down.

Now turn on MASTER1 node again.
MariaDB server and replication will start automatically and MASTER1 should catch up MASTER2.

MASTER1

Check "users" table - it's synchronised again.

root@server1:~#  mysql -u root -p -D testdb

MariaDB [testdb]> select * from users;
+----+-------+---------------------+
| id | name | datum |
+----+-------+---------------------+
| 1 | Marko | 2015-02-01 00:41:41 |
| 2 | John | 2015-01-31 16:17:55 |
| 3 | Eric | 2015-01-31 16:19:49 |
| 4 | Clive | 2015-01-31 16:19:55 |
| 5 | Maria | 2015-01-31 16:20:01 |
+----+-------+---------------------+
5 rows in set (0.00 sec)




Please let me know if you see possible problems in this configuration. I will update post gladly. Thanks for reading!









 

Read More

How To Configure SSH Key-Based Authentication on a Linux Server


  • 2016-07-28
  • Vijay Mali
  • 122

Introduction

SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with a Linux server, chances are, you will spend most of your time in a terminal session connected to your server through SSH.

While there are a few different ways of logging into an SSH server, in this guide, we'll focus on setting up SSH keys. SSH keys provide an easy, yet extremely secure way of logging into your server. For this reason, this is the method we recommend for all users.

 

How Do SSH Keys Work?

An SSH server can authenticate clients using a variety of different methods. The most basic of these is password authentication, which is easy to use, but not the most secure.

Although passwords are sent to the server in a secure manner, they are generally not complex or long enough to be resistant to repeated, persistent attackers. Modern processing power combined with automated scripts make brute forcing a password-protected account very possible. Although there are other methods of adding additional security (fail2ban, etc.), SSH keys prove to be a reliable and secure alternative.

SSH key pairs are two cryptographically secure keys that can be used to authenticate a client to an SSH server. Each key pair consists of a public key and a private key.

The private key is retained by the client and should be kept absolutely secret. Any compromise of the private key will allow the attacker to log into servers that are configured with the associated public key without additional authentication. As an additional precaution, the key can be encrypted on disk with a passphrase.

The associated public key can be shared freely without any negative consequences. The public key can be used to encrypt messages that only the private key can decrypt. This property is employed as a way of authenticating using the key pair.

The public key is uploaded to a remote server that you want to be able to log into with SSH. The key is added to a special file within the user account you will be logging into called ~/.ssh/authorized_keys.

When a client attempts to authenticate using SSH keys, the server can test the client on whether they are in possession of the private key. If the client can prove that it owns the private key, a shell session is spawned or the requested command is executed.

An overview of the flow is shown in this diagram:

 



The diagram shows a laptop connecting to a server, but it could just as easily be one server connecting to another server.

How To Create SSH Keys

The first step to configure SSH key authentication to your server is to generate an SSH key pair on your local computer.

To do this, we can use a special utility called ssh-keygen, which is included with the standard OpenSSH suite of tools. By default, this will create a 2048 bit RSA key pair, which is fine for most uses.

On your local computer, generate a SSH key pair by typing:

 

On your local computer, generate a SSH key pair by typing:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

The utility will prompt you to select a location for the keys that will be generated. By default, the keys will be stored in the ~/.ssh directory within your user's home directory. The private key will be called id_rsa and the associated public key will be called id_rsa.pub.

Usually, it is best to stick with the default location at this stage. Doing so will allow your SSH client to automatically find your SSH keys when attempting to authenticate. If you would like to choose a non-standard path, type that in now, otherwise, press ENTER to accept the default.

If you had previously generated an SSH key pair, you may see a prompt that looks like this:

/home/username/.ssh/id_rsa already exists.
Overwrite (y/n)?

If you choose to overwrite the key on disk, you will not be able to authenticate using the previous key anymore. Be very careful when selecting yes, as this is a destructive process that cannot be reversed.

Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again: 

Next, you will be prompted to enter a passphrase for the key. This is an optional passphrase that can be used to encrypt the private key file on disk.

You may be wondering what advantages an SSH key provides if you still need to enter a passphrase. Some of the advantages are:

  • The private SSH key (the part that can be passphrase protected), is never exposed on the network. The passphrase is only used to decrypt the key on the local machine. This means that network-based brute forcing will not be possible against the passphrase.

 

  • The private key is kept within a restricted directory. The SSH client will not recognize private keys that are not kept in restricted directories. The key itself must also have restricted permissions (read and write only available for the owner). This means that other users on the system cannot snoop.

 

  • Any attacker hoping to crack the private SSH key passphrase must already have access to the system. This means that they will already have access to your user account or the root account. If you are in this position, the passphrase can prevent the attacker from immediately logging into your other servers. This will hopefully give you time to create and implement a new SSH key pair and remove access from the compromised key.


Since the private key is never exposed to the network and is protected through file permissions, this file should never be accessible to anyone other than you (and the root user). The passphrase serves as an additional layer of protection in case these conditions are compromised.

A passphrase is an optional addition. If you enter one, you will have to provide it every time you use this key (unless you are running SSH agent software that stores the decrypted key). We recommend using a passphrase, but if you do not want to set a passphrase, you can simply press ENTER to bypass this prompt.

Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host
The key's randomart image is:
+--[ RSA 2048]----+
|     ..o         |
|   E o= .        |
|    o. o         |
|        ..       |
|      ..S        |
|     o o.        |
|   =o.+.         |
|. =++..          |
|o=++.            |
+-----------------+

You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH key authentication to log in.

 

How to Embed your Public Key when Creating your Server

If you are starting up a new DigitalOcean server, you can automatically embed your SSH public key in your new server's root account.

Towards the bottom of the Droplet creation page, there is an option to add SSH keys to your server:



If you have already added a public key file to your DigitalOcean account, you will see it here as a selectable option (there are two existing keys in the example above: "Work key" and "Home key"). To embed an existing key, simply click on it and it will highlight. You can embed multiple keys on a single server:


If you do not already have a public SSH key uploaded to your account, or if you would like to add a new key to your account, click on the "+ Add SSH Key" button. This will expand to a prompt:



In the "SSH Key content" box, paste the content of your SSH public key. Assuming you generated your keys using the method above, you can obtain your public key contents on your local computer by typing:

$ cat ~/.ssh/id_rsa.pub
$ ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD username@example.com

Paste this value, in its entirety, into the larger box. In the "Comment (optional)" box, you can choose a label for the key. This will be displayed as the key name in the DigitalOcean interface:



When you create your Droplet, the public SSH keys that you selected will be placed in the ~/.ssh/authorized_keys file of the root user's account. This will allow you to log into the server from the computer with your private key.

 

How To Copy a Public Key to your Server

If you already have a server available and did not embed keys upon creation, you can still upload your public key and use it to authenticate to your server.

The method you use depends largely on the tools you have available and the details of your current configuration. The following methods all yield the same end result. The easiest, most automated method is first and the ones that follow each require additional manual steps if you are unable to use the preceding methods.

Copying your Public Key Using SSH-Copy-ID

The easiest way to copy your public key to an existing server is to use a utility called ssh-copy-id. Because of its simplicity, this method is recommended if available.

The ssh-copy-id tool is included in the OpenSSH packages in many distributions, so you may have it available on your local system. For this method to work, you must already have password-based SSH access to your server.

To use the utility, you simply need to specify the remote host that you would like to connect to and the user account that you have password SSH access to. This is the account where your public SSH key will be copied.

The syntax is:

$ ssh-copy-id username@remote_host

You may see a message like this:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

This just means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type "yes" and press ENTER to continue.

Next, the utility will scan your local account for the id_rsa.pub key that we created earlier. When it finds the key, it will prompt you for the password of the remote user's account:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@111.111.11.111's password:

Type in the password (your typing will not be displayed for security purposes) and press ENTER. The utility will connect to the account on the remote host using the password you provided. It will then copy the contents of your ~/.ssh/id_rsa.pub key into a file in the remote account's home ~/.ssh directory called authorized_keys.

You will see output that looks like this:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'username@111.111.11.111'"
and check to make sure that only the key(s) you wanted were added.

At this point, your id_rsa.pub key has been uploaded to the remote account. You can continue onto the next section.

Copying your Public Key Using SSH

If you do not have ssh-copy-id available, but you have password-based SSH access to an account on your server, you can upload your keys using a conventional SSH method.

We can do this by outputting the content of our public SSH key on our local computer and piping it through an SSH connection to the remote server. On the other side, we can make sure that the ~/.ssh directory exists under the account we are using and then output the content we piped over into a file called authorized_keys within this directory.

We will use the >> redirect symbol to append the content instead of overwriting it. This will let us add keys without destroying previously added keys.

The full command will look like this:

$ cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

You may see a message like this:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

This just means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type "yes" and press ENTER to continue.

Afterwards, you will be prompted with the password of the account you are attempting to connect to:

username@111.111.11.111's password:

After entering your password, the content of your id_rsa.pub key will be copied to the end of the authorized_keys file of the remote user's account. Continue to the next section if this was successful.

Copying your Public Key Manually

If you do not have password-based SSH access to your server available, you will have to do the above process manually.

The content of your id_rsa.pub file will have to be added to a file at ~/.ssh/authorized_keys on your remote machine somehow.

To display the content of your id_rsa.pub key, type this into your local computer:

$ cat ~/.ssh/id_rsa.pub

You will see the key's content, which may look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

Access your remote host using whatever method you have available. For instance, if your server is a DigitalOcean Droplet, you can log in using the web console in the control panel:



Once you have access to your account on the remote server, you should make sure the ~/.ssh directory is created. This command will create the directory if necessary, or do nothing if it already exists:

$ mkdir -p ~/.ssh

Now, you can create or modify the authorized_keys file within this directory. You can add the contents of your id_rsa.pub file to the end of the authorized_keys file, creating it if necessary, using this:

$ echo public_key_string >> ~/.ssh/authorized_keys

In the above command, substitute the public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you executed on your local system. It should start with ssh-rsa AAAA....

If this works, you can move on to try to authenticate without a password.

 

Authenticate to your Server Using SSH Keys

If you have successfully completed one of the procedures above, you should be able to log into the remote host without the remote account's password.

The basic process is the same:

$ ssh username@remote_host

If this is your first time connecting to this host (if you used the last method above), you may see something like this:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

This just means that your local computer does not recognize the remote host. Type "yes" and then press ENTER to continue.

If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be required to enter it now. Afterwards, a new shell session should be spawned for you with the account on the remote system.

If successful, continue on to find out how to lock down the server.

 

Disabling Password Authentication on your Server

If you were able to login to your account using SSH without a password, you have successfully configured SSH key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.

Before completing the steps in this section, make sure that you either have SSH key-based authentication configured for the root account on this server, or preferably, that you have SSH key-based authentication configured for an account on this server with sudo access. This step will lock down password-based logins, so ensuring that you have will still be able to get administrative access is essential.

Once the above conditions are true, log into your remote server with SSH keys, either as root or with an account with sudo privileges. Open the SSH daemon's configuration file:

$ sudo nano /etc/ssh/sshd_config

Inside the file, search for a directive called PasswordAuthentication. This may be commented out. Uncomment the line and set the value to "no". This will disable your ability to log in through SSH using account passwords:

PasswordAuthentication no

Save and close the file when you are finished. To actually implement the changes we just made, you must restart the service.

On Ubuntu or Debian machines, you can issue this command:

$ sudo service ssh restart

On CentOS/Fedora machines, the daemon is called sshd:

sudo service sshd restart

After completing this step, you've successfully transitioned your SSH daemon to only respond to SSH keys.





 

Read More