Setting up SSH key access to Backup Stor Print

SSH keys identify you to the server without a password. For Backup Stor this matters in particular because an automated backup job cannot type a password — a key is what makes unattended backups possible.

A key pair consists of a private key, which stays on your machine and is never sent anywhere, and a public key, which is placed on the storage in the file ~/.ssh/authorized_keys.

Generating a key on Linux or macOS

ssh-keygen -t ed25519

You will be asked two things:

• Where to save the key. Press Enter to accept the default, ~/.ssh/id_ed25519.
• A passphrase. It protects the private key if the file is stolen. For an automated backup job leave it empty, since nothing can enter it — in that case the key file itself is the credential, so keep its permissions at 600 and do not copy it around. For interactive use, set one.

Two files are created: ~/.ssh/id_ed25519 (private — never share it) and ~/.ssh/id_ed25519.pub (public).

We suggest ed25519 rather than RSA: the keys are shorter, faster and at least as secure. If a tool in your chain does not support it, use ssh-keygen -t rsa -b 4096 instead.

Generating a key on Windows

Current Windows versions include OpenSSH, so the same command works in PowerShell:

ssh-keygen -t ed25519

The keys are placed in C:\Users\YourName\.ssh\.

If you use PuTTY, generate the pair with PuTTYgen instead: click Generate, move the mouse over the blank area to provide randomness, then save the private key as a .ppk file and copy the public key text from the box at the top of the window. Note that PuTTY needs its own .ppk format — a key generated with ssh-keygen has to be imported and saved as .ppk before PuTTY will use it.

Installing the public key on the storage

The simplest route, if you can already log in with a password:

ssh-copy-id [email protected]

Or, doing the same thing by hand:

cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Replace kdXXXXXXX with your storage user name — see Подключение услуги Backup Stor по протоколам SMB/CIFS и FTP/FTPS for your connection details.

The public key must be added as a single line. Pasting it into an editor and letting it wrap across lines is the most common reason key authentication silently fails.

If you cannot write to authorized_keys on the storage, send us the contents of your public key in a ticket and we will install it. Never send the private key — to us or to anyone else.

Testing it

ssh [email protected]

This must connect without asking for a password. Only once it does should you configure an automated job to use it — see Setting up a remote backup repository in KeyHelp.

If the key is not accepted

• Permissions. SSH ignores keys when the permissions are too open: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys on the storage, and chmod 600 on your private key.
• Line breaks. Check that the public key is one unbroken line beginning with ssh-ed25519 or ssh-rsa.
• The wrong key offered. If you have several, name the one to use: ssh -i ~/.ssh/id_ed25519 [email protected]
• See what happens. ssh -v shows which keys are offered and why they are refused.

If it still does not work, open a ticket from your client area with the output of ssh -v.