We don’t get too many roving bands of rogue systems administrators in this neck of the woods, but just in case… The bad guy would have to break in to your office and know his way round a headless Linux box. Realistically, this is a pretty low risk. However, using SSH keys without a passphrase is a security risk - is someone had access to the local backup server, they would be easily able to access the remote server.
Using an SSH key without a passphrase makes it possible to automate remote tasks - a user-entered passphrase is not required for local key decryption.Īutomation of backup tasks is essential - if backup relies on human intervention, sooner or later it will fail.
#Grsync raspberry pi password
The -i flag can be used to set the specific key file that should be transferred: ssh-copy-id -i ~/.ssh/local-fileserver.pub the key has been transferred, set the SSH config to disallow password login ( PasswordAuthentication no) and restart SSH. If no keyfile is specified, this command will copy all public keys from the /home/username/.ssh directory, which may not be what you intend. This can be achieved easily using the ssh-copy-id command - though the server must obviously allow the connection before the key is set up, so you may need to temporarily amend the servers SSH configuration to reflect this. IdentityFile ~/.ssh/local-fileserver Uploading the Key The following command will do this in any case, with the file being created when you save (ctrl + o in nano): sudo nano /home/username/.ssh/config You may need to create the config file it it doesn’t exist. If you’re not using the default key file, create an entry in an SSH config file specifying the correct key file for the server that you’re going to connect to. To add a comment, just enter text at the end of the public key, separated from the key content by a space. If no comment is added, the public key file has appended to the key as a default comment. If the client machine is compromised, it allows the relevant line to be easily removed from the server authorized_keys file. The comment will help distinguish the key. When transferred to the target machine, the public key will be appended to the /home/username/.ssh/authorized_keys file. It can be helpful to have a comment in the key file. home/username/.ssh/local-fileserver Comments in the Key File If one doesn’t already exist, or you need a unique key for some reason, you can generate an RSA key with a specific name: ssh-keygen -t rsaĮnter file in which to save the key (/home/david/.ssh/id_rsa ): Key GenerationĪ public-private key pair is required, with the public key added to the target server. This limitation is the focus of this article, though I also provide a sample backup script. The scope of action on the target machine must be limited to read-only rsync for a specified directory. The setup is low power, cost-effective, secure and runs automatically.īecause the backup script runs automatically and is unattended, it has to be passwordless. The Pi acts as an always-on local fileserver - this periodically connects to a remote server (in this case, a Digital Ocean Ubuntu box) via SSH collecting backup data using rsync. Once downloaded, files are accessible across the LAN by SSHing into the Pi. The solution needed to be fully automatic and secure.Ī Raspberry Pi with an external SSD storage drive was used as the local client. The objective is to hold a local copy of backup files. The connection is limited to read-only access of a specified directory on the remote server.
#Grsync raspberry pi how to
This article describes how to provide a local Raspberry Pi access to a remote server in order to automatically download backup files through an encrypted channel.
0 kommentar(er)
