Linux ssh key path

How to Use SSH Public Key Authentication

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.

How Public Key Authentication Works

Keys come in pairs of a public key and a private key. Each key pair is unique, and the two keys work together.

These two keys have a very special and beautiful mathematical property: if you have the private key, you can prove you have it without showing what it is. It’s like proving you know a password without having to show someone the password.

Public key authentication works like this:

1. Generate a key pair.
2. Give someone (or a server) the public key.
3. Later, anytime you want to authenticate, the person (or the server) asks you to prove you have the private key that corresponds to the public key.
4. You prove you have the private key.

You don’t have to do the math or implement the key exchange yourself. The SSH server and client programs take care of this for you.

Generate an SSH Key Pair

You should generate your key pair on your laptop, not on your server. All Mac and Linux systems include a command called ssh-keygen that will generate a new key pair.

If you’re using Windows, you can generate the keys on your server. Just remember to copy your keys to your laptop and delete your private key from the server after you’ve generated it.

To generate an SSH key pair, run the command ssh-keygen.

It will look like this when you run it:

laptop1:~ yourname$ ssh-keygen Generating public/private rsa key pair.

You’ll be prompted to choose the location to store the keys. The default location is good unless you already have a key. Press Enter to choose the default location.

Enter file in which to save the key (/Users/yourname/.ssh/id_rsa):

Next, you’ll be asked to choose a password. Using a password means a password will be required to use the private key. It’s a good idea to use a password on your private key.

Enter passphrase (empty for no passphrase): Enter same passphrase again:

After you choose a password, your public and private keys will be generated. There will be two different files. The one named id_rsa is your private key. The one named id_rsa.pub is your public key.

Your identification has been saved in /Users/yourname/.ssh/id_rsa. Your public key has been saved in /Users/yourname/.ssh/id_rsa.pub.

You’ll also be shown a fingerprint and «visual fingerprint» of your key. You do not need to save these.

The key fingerprint is: d7:21:c7:d6:b8:3a:29:29:11:ae:6f:79:bc:67:63:53 yourname@laptop1 The key's randomart image is: +--[ RSA 2048]----+ | | | . o | | . . * . | | . . = o | | o S . o | | . . o oE | | . .oo +. | | .o.o.*. | | . = o | +-----------------+

Configure an SSH/SFTP User for Your Key

Method 1: Using ssh-copy-id

Now that you have an SSH key pair, you’re ready to configure your app’s system user so you can SSH or SFTP in using your private key.

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.

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.

Log In Using Your Private Key

You can now SSH or SFTP into your server using your private key. From the command line, you can use:

If you didn’t create your key in the default location, you’ll need to specify the location:

ssh -i ~/.ssh/custom_key_name SYSUSER@x.x.x.x

If you’re using a Windows SSH client, such as PuTTy, look in the configuration settings to specify the path to your private key.

Granting Access to Multiple Keys

The .ssh/authorized_keys file you created above uses a very simple format: it can contain many keys as long as you put one key on each line in the file.

If you have multiple keys (for example, one on each of your laptops) or multiple developers you need to grant access to, just follow the same instructions above using ssh-copy-id or manually editing the file to paste in additional keys, one on each line.

When you’re done, the .ssh/authorized_keys file will look something like this (don’t copy this, use your own public keys):

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSkT3A1j89RT/540ghIMHXIVwNlAEM3WtmqVG7YN/wYwtsJ8iCszg4/lXQsfLFxYmEVe8L9atgtMGCi5QdYPl4X/c+5YxFfm88Yjfx+2xEgUdOr864eaI22yaNMQ0AlyilmK+PcSyxKP4dzkf6B5Nsw8lhfB5n9F5md6GHLLjOGuBbHYlesKJKnt2cMzzS90BdRk73qW6wJ+MCUWo+cyBFZVGOzrjJGEcHewOCbVs+IJWBFSi6w1enbKGc+RY9KrnzeDKWWqzYnNofiHGVFAuMxrmZOasqlTIKiC2UK3RmLxZicWiQmPnpnjJRo7pL0oYM9r/sIWzD6i2S9szDy6aZ mike@laptop1 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzlL9Wo8ywEFXSvMJ8FYmxP6HHHMDTyYAWwM3AOtsc96DcYVQIJ5VsydZf5/4NWuq55MqnzdnGB2IfjQvOrW4JEn0cI5UFTvAG4PkfYZb00Hbvwho8JsSAwChvWU6IuhgiiUBofKSMMifKg+pEJ0dLjks2GUcfxeBwbNnAgxsBvY6BCXRfezIddPlqyfWfnftqnafIFvuiRFB1DeeBr24kik/550MaieQpJ848+MgIeVCjko4NPPLssJ/1jhGEHOTlGJpWKGDqQK+QBaOQZh7JB7ehTK+pwIFHbUaeAkr66iVYJuC05iA7ot9FZX8XGkxgmhlnaFHNf0l8ynosanqt henry@laptop2

Additional Information

Retrieve Your Public Key from Your Private Key

The following command will retrieve the public key from a private key:

ssh-keygen -y -f /path/to/your_private_key_file (eg. /root/.ssh/id_rsa or ~/.ssh/custom_key_name)

This can be useful, for example, if your server provider generated your SSH key for you and you were only able to download the private key portion of the key pair.

Note that you cannot retrieve the private key if you only have the public key.

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

Disabling Password Authentication

NOTE: When changing anything about the way SSH is accessed (ports, authentication methods, et cetera), it is very strongly recommended to leave an active root SSH session open until everything is working as intended. This ensures you have a way to revert changes in the event something goes wrong and logins are not working properly.

As an extra security precaution, once you have set up SSH keys, you may wish to disable password authentication entirely. This will mean no users will be able to log into SSH or SFTP without SSH keys. Anyone entering a password will receive a message like:

Permission denied (publickey,password).

No supported authentication methods available

Disabling password authentication is an excellent way to improve server security. Please see our guide here for the steps to accomplish this goal.

Then, test whether you’re able to log in with a password by opening a new SSH or SFTP session to the server. Passwords should not be able to be used and, if everything has been done correctly, an error will be issued when someone tries to use a password. Unless this setting is changed back to allow password authentication, no users will be able to log in without an SSH key set up.

Источник

Setting the default ssh key location

ssh will look for its keys by default in the ~/.ssh folder. I want to force it to always look in another location. The workaround I’m using is to add the keys from the non-standard location to the agent:

ssh-agent ssh-add /path/to/where/keys/really/are/id_rsa 

@tardate, hmm, trusting dropbox with your keys seems dangerous, unless you password-protect them well .

you should really have separate key in each of your computers, this way when someone stols one of them you you will just remove its public key from server without disabling rest of the computers. Having private key on Dropbox is equivalent of having text file with your passwords on a Dropbox => Something may or may not happen but still bad idea.

@equivalent8 — noted! I actually use this mainly for seeding my (main one and only) computer from Dropbox. So when I get a new computer, it’s ready to go..

3 Answers 3

If you are only looking to point to a different location for you identity file, the you can modify your ~/.ssh/config file with the following entry:

man ssh_config to find other config options.

Note also that you can list this parameter multiple times for multiple keys. However, listing too many keys (typically >4) can cause auth to fail before prompting for a password on systems where your key isn’t valid. ssh-agent, or keychain (gentoo.org/proj/en/keychain) are helpful here.

if you have password protected for you ssh keys, you’d better ssh-add your-private-key , otherwise, it’s always asking for key’s password

man ssh gives me this options would could be useful.

-i identity_file Selects a file from which the identity (private key) for RSA or DSA authentication is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro- tocol version 2. Identity files may also be specified on a per- host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in config- uration files).

So you could create an alias in your bash config with something like

I haven’t looked into a ssh configuration file, but like the -i option this too could be aliased

-F configfile Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is ~/.ssh/config.

Update for Git Bash on Windows 10: on my system, git bash app will work over the ssh layer (brought by OpenSSH) look for an environment variable called HOME (To Windows key and type in «env» to edit env vars). If this variable points to a place that doesn’t exist, git bash may never open.

Like on Linux, Git Bash app will look for its config file in %HOME%\.ssh .

e.g. If you set HOME to C:\Users\Yourname , than it will look for C:\Users\Yourname\.ssh

Finally, within config text file, git bash will look for IdentifyFile path. On Windows, set the path using cygwin notation.

e.g. to /e/var/www/certs/keys/your_passwordless_key.key

Bonus: for free, PHPStorm will use that setup. Restart IDE if you’ve just changed settings.

Источник