Here I'll describe some specific configuration options, I use to optimize my SSH client workflow.
The instructions are split into 4 topics with different level of complexity:
The second part: Deploying code from Docker container by using the ssh-agent
Keeping all the usernames, hostnames, ip addresses and passwords in mind is not a fun at all. It's also not a fun to have a file with a bunch of such credentials and copy and paste them every time you need to establish a new connection;
Suppose you have a remote server with domain
zinovyev.net with a user called
Every time you want to establish a connection to your server, you have to perform these steps:
Open a file called
~/Desktop/MySecretCredentials.txt to find out your username (e.g.
Type in a command
ssh email@example.com to initiate a connection;
Go back to a file with credentials to retrieve your password;
Copy and paste your password when the prompt is shown;
Suppose now, that the company you're working for, owns a dozens of servers.
Let's optimize the described above workflow.
To don't type your username and hostname every time you want to initialize a connection, you can make up
an intuitive name for each server and use it with the
The configuration file of the ssh client is called
Let's open it and put this configuration in it:
Host zinovyev-prod Hostname zinovyev.net User ubuntu
Now you can use the
ssh command in this way:
But you still have to put in your password. Let's use an RSA key instead!
ssh-keygen command to generate a new rsa key:
ssh-keygen -trsa Generating public/private rsa key pair. Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): Created directory '/home/ubuntu/.ssh'. Enter passphrase (empty for no passphrase):
Don't enter any passphrase, just press an ENTER key. You don't want to provide it everytime you are trying to establish a connection, don't you?
ssh-keygen will generate you two files:
The first one (
~/.ssh/id_rsa) is a private key. You should NOT SHARE it with anybody;
The second one (
~/.ssh/id_rsa.pub, remember the
pub part wich stands for public) can be used
by the remote host to verify your identity;
Copy the content of the public key (run
cat ~/.ssh/id_rsa.pub and copy the output).
Now log in to the your server
ssh zinovyev-prod and create a specific file for you keys ON THE REMOTE HOST:
mkdir ~/.ssh touch ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Now put the content of your original idrsa.pub file (wich is stored in your buffer, remember?) to the `~/.ssh/authorizedkeys` file. Log out and log in again.
No password should be asked next time you log in to the server with the
ssh zinovyev-prod command.
P.S. You might be interested in the utility called
ssh-agent. Launch it on both: local machine and on the
remote server too by typing in
ssh-agent command. Your private key will now be shared accross the ssh session
without a need to copy it directly to the remote host so nobody will be able to read it. It gives you the ability
to deploy from remote host and to work with your github repositories from the remote host without need to type in
When you enter a password when you generate the key, you are encrypting the private key. If you happen to loose the key or laptop, or usb key that you put the private key on, the encryption offers an extra level of protection. Especially when you consider that you are likely storing the file which has a list of servers this key authenticates too alongside the private key.
At the very least use an ssh agent, when you start the session, just execute ssh-add
There's usually a specific path there on the remote you want to chdir to after you have successfully connected
to the server. It's often a directory where the source code of your application is stored to. The directory of
your application can vary from host to host: it can be
/opt/apps/app2 or just anything.
To switch to the proper directory authomatically open your configuration file
and enhance it with a
Host zinovyev-prod Hostname zinovyev.net User ubuntu RequestTTY yes RemoteCommand cd /var/www/app1
Now every time you type in
ssh zinovyev-prod you will be connected to the remote server and the directory will be
changed to the
Sometimes the connection gets lost for a second. Sometimes you accidently halt your laptop, forgetting about a script
that was running through an ssh session without
nohup. In any case there's not reasonable cause to rely on
the unstable connection channel.
There's a software tool called
screen wich makes it terribly simple to create a daemonized session on server.
All you need is to install it (it does exists in mostly all repositories of all Linux based distros).
The basic screen commands are:
screen -help To list all existing commands;
screen -help To list all running sessions;
screen To start a new session;
screen -x [session-name] Attach to a not deatached session (somebody is already using it, you'll share the screen);
screen -r [session-name] Attach to a detached session (somebody has used it, but now it is daemonized);
Ctrl^a+d Detach from session without killing it;
Now let's change an ssh configuration file one more time to start (or attach to existing) a screen session just after signing in to remote server:
Host zinovyev-prod Hostname zinovyev.net User ubuntu RequestTTY yes RemoteCommand cd /var/www/app1 ; screen -SRR example-name
Here's an explanation of used options (from the screen\'s help page):
-D -RR Do whatever is needed to get a screen session.
-S sockname Name this session
.sockname instead of . . .
So you can use any name you like instead of
example-name to name your session.
Now when you ssh to the remote host the new session will be started imidiatly just after login. And when you want to close the connection just use
Ctrl^a+d to keep the connection alive until the next login.
All the settings that we've declared so far are restricted to a specific host. The client can also be configured to store some global options.
There are several client configuration options which can speed up connections by reducing the number of sessions by enabling the sharing of multiple sessions over a single network connection.
The other option that can speed up the connection (on slower networks) is enabling the compression of the ssh traffic.
So let's modify our
~/.ssh/config file one more time:
# Global options Compression yes ControlMaster auto ControlPersist yes ControlPath ~/.ssh/sockets/socket-%r@%h:%p # Per-host settings Host zinovyev-prod Hostname zinovyev.net User ubuntu RequestTTY yes RemoteCommand cd /var/www/app1 ; screen -SRR example-name
If you like this post you'll probably like the other one too Deploying code from the Docker container.