We eliminated the need to use a password so we can write a script to use the above. But, we can still ssh using that key to do other things besides just rsync. Time to finally get to the topic of this post.

If the IP/hostname of the host you are backing up flyingmonkey from does not change, you can begin by adding that to the front of the ~bob/.ssh/authorized_keys entry for the flyingmonkey public key. //

Next step is specify which commands that can be run when connected using this key. And that one again will require playing with ~bob/.ssh/authorized_keys. This time we will specify the command:

from="192.168.42.24",command="/home/bob/.ssh/validate-rsync" ssh-rsa AAAAB3NzaC1yc2EAAAADAQlVk [...] se9ZDx backup-key

And define validate-rsync as

 cat > .ssh/validate-rsync << 'EOF'

 #!/bin/sh
 case "$SSH_ORIGINAL_COMMAND" in
     rsync\ --server\ --sender\ -vlogDtprze.iLsf\ .\ pickles)
         $SSH_ORIGINAL_COMMAND
         ;;
     *)
         echo "Permission denied: scripts/eiger "
         ;;
 esac
 EOF

 chmod +x .ssh/validate-rsync

And this is where it get really exciting. All that validate-rsync is doing is seeing if the command being sent is not only an rsync command but a specific one. Once we figure out how to get the proper SSH_ORIGINAL_COMMAND, we can change the line
rsync\ --server\ --sender\ -vlogDtprze.iLsf\ .\ pickles)
to what it needs to be to match our backup script and test. Note that if you change the rsync statement, you will need to change the case.

In OpenSSH, a user's authorized keys file lists keys that are authorized for authenticating as that user, one per line. Lines starting with # and empty lines are ignored.

Each line contains a public SSH key. The public key may be preceded by options that control what can be done with the key.

The following options are supported in authorized_keys files.

sshdo provides an easily configurable way of controlling which commands may be executed via incoming ssh connections.

But, what if you really want to be really precise on the command? Using the above example, not only running rsync but also specifying the path and the arguments? You could cheat and find what the command you are sending is supposed to look like by replacing (temporarily) your wrapper script with this

 #!/bin/sh

 DEBUG="logger" # Linux
 #DEBUG="syslog -s -l note" # OSX

 if [ -n "$SSH_ORIGINAL_COMMAND" ]; then
         $DEBUG "Passed SSH command $SSH_ORIGINAL_COMMAND"
 elif [ -n "$SSH2_ORIGINAL_COMMAND" ]; then
         $DEBUG "Passed SSH2 command     $SSH2_ORIGINAL_COMMAND"
 else
         $DEBUG Not passed a command.
 fi

Then you run the ssh command and see what it looks like in the log file. Copy that to your original wrapper script, and you are good to go. So

 ssh -t -i /home/raub/.ssh/le_key raub@virtualpork echo "Hey"

Results in

 Dec 26 13:34:05 virtualpork syslog[64541]: Passed SSH command echo Hey

While

 rsync -avz -e 'ssh -i /home/raub/.ssh/le_key' raub@virtualpork:Public /tmp/backup/

results in

 Dec 26 13:28:17 virtualpork syslog[64541]: Passed SSH command rsync --server  --sender -vlogDtprze.iLs . Public

The latter meaning our little wrapper script would then look like

 #!/bin/sh
 case $SSH_ORIGINAL_COMMAND in
     "rsync --server --sender -vlogDtprze.iLs . Public")
         $SSH_ORIGINAL_COMMAND
         ;;
     *)
         echo "Permission denied."
         exit 1
         ;;
 esac

///

find command:
grep "Passed SSH command" /var/log/syslog

The authorized_keys has a command="..." option that restricts a key to a single command. Is there a way to restrict a key to multiple commands? E.g. by having a regex there, or by editing some other configuration file? //

You can have only one command per key, because the command is “forced”.

But you can use a wrapper script. The called command gets the original command line as environment variable $SSH_ORIGINAL_COMMAND, which it can evaluate.

GNU Rush is a Restricted User Shell, designed for sites providing limited remote access to their resources, such as, for example, savannah.gnu.org. Its main program, rush, is configured as a user login shell for users that are allowed only remote access to the machine.

Our second line of defense in securing our script setup is to use the command ="" directive, also specified in the authorized_keys file. The syntax for this looks like:

 command ="command",  KEY

This tells SSH to run command and then exit. It effectively limits your ability to run commands on the remote server.

PuTTY for Windows saves all sites and configuration in Windows Registry.

Batch file to export sites and configuration from Windows Registry to a .reg file:

@echo off
::
:: export putty sites in ANSI mode
::
regedit /ea "o:\my documents\.ssh\putty-ini.reg" HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

To later import, right-click on putty-ini.reg and select "import" or "merge".

SFTP stands for SSH File Transfer Protocol. As its name suggests, it’s a secure way of transferring files to a server using an encrypted SSH connection. Despite the name, it’s a completely different protocol than FTP (File Transfer Protocol), though it’s widely supported by modern FTP clients.

SFTP is available by default with no additional configuration on all servers that have SSH access enabled. It’s secure and easy to use, but comes with a disadvantage: in a standard configuration, the SSH server grants file transfer access and terminal shell access to all users with an account on the system.

In some cases, you might want only certain users to be allowed file transfers and no SSH access. In this tutorial, we’ll set up the SSH daemon to limit SFTP access to one directory with no SSH access allowed on per user basis.

DWService is an open source project which offers a service to allow access to remote systems (Windows, Mac, Linux, Raspberry...) using a standard web browser - no client-side download required!
Wherever you may be in the world, you may need to access your home computer. You can connect to the DWService website from any device and immediately gain control of the computer (Screen + Files + Running processes).

There’s lots of articles on SSH tunneling, and plenty that cover how to create a tunnel with PuTTY, so why write another one? Because I spent longer than I should have trying to get this working the other day, and failing due to a simple order of operations issue.

During connecting to a SSH server, the client stores the few details like Server’s Hostname, IP Address and Host key in a file name known_hosts. This file will be located in you ~/.ssh directory as shown below :

This file contains list of all servers to which you connect in a plaintext. It poses a small security risk if the host is shared or your client gets compromised. This can be avoided by Hashing the known_hosts file. Hashing known_hosts file is easy, you just use the ssh-keygen command as shown below :

 $ ssh-keygen -H -f known_hosts
 known_hosts updated.
 Original contents retained as known_hosts.old
 WARNING: known_hosts.old contains unhashed entries
 Delete this file to ensure privacy of hostnames

Note : You need to delete the backup file known_hosts.old

Unfortunately, the 0.74 stable PuTTY release does not safely guard plain-text passwords provided to it via the -pw command line option for the psftp, pscp, and plink utilities as the documentation clearly warns. There is evidence within the source code that the authors are aware of the problem, but the exposure is confirmed on Microsoft Windows, Oracle Linux, and the package prepared by the OpenBSD project.

After discussions with the original author of PuTTY, Simon Tatham developed a new -pwfile option, which will read an SSH password from a file, removing it from the command line. This feature can be backported into the current 0.76 stable release. Full instructions for applying the backport and a .netrc wrapper for psftp are presented, also implemented in Windows under Busybox.

While the -pw option is attractive for SSH users who are required to use passwords (and forbidden from using keys) for scripting activities, the exposure risk should be understood for any use of the feature. Users with security concerns should obtain the -pwfile functionality, either by applying a patch to the 0.76 stable release, or using a snapshot release found on the PuTTY website.

If you want to, say, put it in your .profile, then you might try the following setup.

SSH_ENV="$HOME/.ssh/environment"

function start_agent {
echo "Initialising new SSH agent..."
/usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
echo succeeded
chmod 600 "${SSH_ENV}"
. "${SSH_ENV}" > /dev/null
/usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
 . "${SSH_ENV}" > /dev/null
 #ps ${SSH_AGENT_PID} doesn't work under cywgin
 ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null 
|| {
     start_agent;
 }
else
  start_agent;
fi 

Finally, time to type a password. The last one of this session, maybe.
you#local$ ssh-add ~/.ssh/id_dsa
Need passphrase for /home/mah/.ssh/id_dsa (you@example.com).
Enter passphrase:

Create a New SSH Key Pair

Open a terminal and run the following command:

ssh-keygen 

SSH config, which is a per-user configuration file for SSH communication. Create a new file: ~/.ssh/config and open it for editing:

nano ~/.ssh/config

Managing Custom Named SSH key

The first thing we are going to solve using this config file is to avoid having to add custom-named SSH keys using ssh-add. Assuming your private SSH key is named ~/.ssh/id_rsa, add following to the config file:

Host github
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

Now you can use git clone git@github:username/project

Sometimes, while trying to connect to remote systems via SSH, you may encounter the error “Received disconnect from x.x.x.x port 22:2: Too many authentication failures”. In this short article, I will explain how to fix this error in a few simple steps.

I discovered that this resulted from existence of many ssh identity keys on my machine, and each time I run the ssh client, it would try all my ssh keys known by the ssh-agent and all other keys, when attempting to connect to the remote server (vps2 as shown in the above screenshot). This is the default behavior of ssh.

Since ssh server (sshd) on the remote server expects a particular identity key, the server rejects the connection and ssh client aborts with the above error.

To fix this error, you need to add the IdentitiesOnly with a value of yes, which instructs ssh to only use the authentication identity files specified on the command line or the configured in the ssh_config file(s), even if ssh-agent offers additional identities.

Public key authentication is a way of logging into an SSH/SFTP account using a cryptographic key rather than a password.

If you use very strong SSH/SFTP passwords, your accounts are already safe from brute force attacks. However, using public key authentication provides many benefits when working with multiple developers. For example, with SSH keys you can

• allow multiple developers to log in as the same system user without having to share a single password between them;
• revoke a single developer's access without revoking access by other developers; and
• make it easier for a single developer to log in to many accounts without needing to manage many different passwords. //

Method 1: Using ssh-copy-id

To copy your public key to your server, run the following command. Be sure to replace "x.x.x.x" with your server's IP address and SYSUSER with the name of the the system user your app belongs to.

ssh-copy-id SYSUSER@x.x.x.x

Method 2: Manual Configuration

If you don't have the ssh-copy-id command (for example, if you are using Windows), you can instead SSH in to your server and manually create the .ssh/authorized_keys file so it contains your public key.

First, run the following commands to make create the file with the correct permissions.

(umask 077 && test -d ~/.ssh || mkdir ~/.ssh)
(umask 077 && touch ~/.ssh/authorized_keys)

Next, edit the file .ssh/authorized_keys using your preferred editor. Copy and paste your id_rsa.pub file into the file. //

Correcting Permissions on the .ssh Directory

The instructions in this article will create your server's .ssh directory and .ssh/authorized_keys file with the correct permissions. However, if you've created them yourself and need to fix permissions, you can run the following commands on your server while SSH'd in as your app's system user.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

By creating a public/private SSH keypair, and uploading the public key to your rsync.net filesystem, you can allow your backup process to authenticate without your password.

Generating the SSH Keypair

First, log into your unix system as the user that your backups will run under. So, if your backups will run as the root user (which is very common) you need to log in as root.

Now run the following command:

ssh-keygen -t rsa -b 4096

Accept the defaults - do not change the filenames or file locations It is very important that the resultant private and public keys reside in your home directories .ssh directory, or ~/.ssh (which is the default)

DO NOT enter a passphrase - just hit enter twice, leaving an empty passphrase.

Uploading Your Public Key

Upload your newly created public key using this command:

scp ~/.ssh/id_rsa.pub 123@tv-s009.rsync.net:.ssh/authorized_keys

DO NOT change the permissions on the uploaded file, before or after the upload

DO NOT change the permissions on your home directory, or your .ssh directory

NOTE: 123@tv-s009 is most certainly NOT your login ID or hostname - please change them.

Testing Your Passwordless Login

Test that your key works by ssh'ing to your rsync.net filesystem (from your local system, as the user who created/uploaded the key):

ssh 123@tv-s009.rsync.net ls

You should not be asked for a password

Multiple Keys (optional)

It is possible to upload multiple public keys to your rsync.net account, allowing one or more users on one or more computer systems to log in without a password. However, you cannot just follow the above instructions over and over again, because each time you follow them, you will overwrite the previous key.

Instead, do this:

1. For the first user on the first computer system, follow the instructions above exactly.

2. For each subsequent user (possibly on different computer systems), replace the 'scp' step in the above instructions with:

   cat ~/.ssh/id_rsa.pub | ssh 123@tv-s009.rsync.net 'dd of=.ssh/authorized_keys oflag=append conv=notrunc'

3. Repeat this process for each user until you have a fully populated authorized_keys file in your rsync.net account.

Mosh, or mobile shell, is the ideal tool for remote system administration. While SSH is great, Mosh beats it in several areas. Let’s dive into the reasons why it makes sense to learn about Mosh.

Session Resumption

Remember the last time your connection was interrupted? It it frustrating and sometimes even leads to losing some of your work. The stable TCP connection is not always a blessing. Mosh comes to the rescue, especially for less stable connections. It solves this issue by picking up where you left. Mosh has a roaming function, allowing you to even between connections. Very useful when you are on the move, or your WiFi connection provides you suddenly with a new IP lease. No longer you need to run everything in a screen session.

No root permissions needed

Mosh can run without root privileges. This is because it uses normal binaries (mosh, mosh-client, and mosh-server). There is no daemon (of its own) waiting for incoming connections.

Default UTF8 support

Every terminal reacts differently to “strange” characters. Mosh will not break your terminal, as it uses UTF-8 by default. So the intended output ends up correctly on your screen, every time. This is much better than showing garbled text or even hanging your terminal screen.

Responsive

SSH has the tendency to be slow to respond to your Ctrl+C requests. This is caused by network buffers be filled and your Ctrl+C has to wait in a long line. Mosh can deal with this, and ensures you it quits much quicker. Interestingly enough Telnet was in some ways much better than SSH, like local echo. Mosh brings back some of the good features.

Another great use-case is when having to do administration on slow connections, especially with “long” network links, including a high latency). With SSH you are waiting for every character to show up, Mosh makes it much more responsive. It does so with the combination of previous input and predictions. It shows what it expects to be there, by using underlining. Then it does a validation step to ensure things are right and tells you that by removing the underlining.

Firewall Rules

One of the disadvantages of Mosh is that the additional UDP port means opening up a set of ports in your firewall. As one port per connection is used, you can limit this (e.g. 60000-60005). For environments which strict rules, this might be a deal breaker. Still for many situations Mosh is a useful addition to simplify work.

Each time the SSH client connects with a server, it will store a related signature (a key) of the server. This information is stored in a file names named known_hosts. The known_hosts file itself is available in the .ssh subdirectory of the related user (on the client). In the case the signature of the server changes, SSH will protect the user by notifying about this chance.

Risk involved

This configuration option is very useful, but also introduces a new risk. Previously it was common to store the hostname related with the key. The result is a “picture” of the network, revealing which systems are connected. This made it easy for worms and other malicious scripts to use this information and spread to other systems, once they had a single system compromised.

Improve security

To reduce the risk of storing a clear picture of the network, the solution introduced was hashing the hostname. To enable this functionality, the HashKnownHosts option can be set to yes. This option can be found in the system-wide SSH client configuration file, which is usually /etc/ssh/ssh_config.

The final result of hashing entries will look something like this:

The hostname (hashed with ecdsa-sha2-nistp256) is unreadable for the human eye or malicious scripts. For each new connection to the related host, the hashing algorithm will result in the same string. This way the client knows it already has a stored key and compare it during the handshaking process with the server.