Sftp specifies the remote account on to login as. So now, on my server,, logged in as user1, and where the private key is stored as described above, an sftp session looks like this: I planted the public key in the account user2 on. Ssh-rsa saved anyone in possession of the private key that matches this public key can now login as this account. In other words, only the owner can access the directory, and the file within it.Īdd to that file the contents of the id_rsa.pub file created above. That would be a *single line* that looks something like this: If you create the file and/or directory, I recommend that the directory be chmod 700, and the file 600. If it already exists, that’s fine, use the existing file. In that account’s home directory, create a “.ssh” subdirectory, and in that directory create a new text file called “authorized_keys”.
On the “remote” server,, pick an account – ANY account – that you want to connect as. This is the key that gets distributed to those places that want to grant you access. My public key is in /home/user1/.ssh/id_rsa.pub. Otherwise, command line options will need to point to the right place and key.
This needs to be kept secure, because of the security implication above, but also needs to be available to the process attempting to make an ssh, sftp or rsync connection. If these tools are run under the ‘user1’ account, the tools will automatically look in the “.ssh” directory and I won’t need to specify the private key location. My private key was placed in /home/user1/.ssh/id_rsa. This is important: by not placing a passphrase on your private key, the security implication is that mere possession of the private key is sufficient to gain access to what ever resources into which you’ve placed the corresponding public key. Since we’re looking for an automated solution, the private key must not have a passphrase. That’s kind of important, because if you do enter a passphrase you’ll need to enter it in order to use the private key. I responded to each prompt by hitting Return. It’s that box on which you plan to run ssh, sftp or rsync.Įnter file in which to save the key (/home/user1/.ssh/id_rsa):Įnter passphrase (empty for no passphrase): We’ll generate the keypair on the Linux box that you want to connect from. This enables the public/private key authentication mechanism we’re about to use. In some cases, these settings are not always present or set the way we need: Check the “sshd_config” on that server, typically in /etc/ssh. To begin with, most of this relies on a the configuration of sshd, the SSH (Secure SHell) daemon running on the server you’re attempting to connect to (we’ll call it “”). As it turns out, this is something I do regularly with ssh, as well as both sftp and rsync, as part of my backup and load balancing approaches for Ask Leo! Let me walk you through what I’ve done.
0 kommentar(er)
