I want to configure SSH to use it without the need of writing the password. I am using Ubuntu 18.04 LTS on Windows 10. I need it to run Hadoop 3.1.1 (https://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-common/SingleCluster.html#Standalone_Operation) using the pseudo-distributed mode.

I have tried a lot of different solutions but without any result. I obtained that the first time that I used the command ssh localhost I do not need to write the passphrase but when I write again I have to write the passphrase.

I explain the different steps that I have used:

  1. I have created a key using ssh-keygen -t rsa
  2. I add the public key to the authorized_keys files: cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  3. I add the key executing: exec ssh-agent bash and ssh-add id_rsa (Years ago, in this point sometimes I had different problems and I used different solutions: https://superuser.com/questions/1147145/what-are-the-differences-between-the-those-ways-of-using-the-ssh-agent)
  4. I execute: ssh localhost

At this point all is right, but, when I execute again ssh localhost, then, I have to write the passphrase. These steps worked fine in the Ubuntu of AWS 3 years ago.

I have tried in the point 3 this other method: https://www.ssh.com/ssh/copy-id

All the possible solutions that I found said the same that I have tried in point 3, or I think that. I have tried to change permissions of authorized_keys and .ssh as I found in other solutions too but without success.

  • 1
    "... when I execute again ssh localhost ..." - Are you doing ssh localhost from the previous SSH session? In other words, are you doing ssh localhost, logged in successfully, and then in the same terminal without logging out, doing ssh localhost again?
    – marcelm
    Oct 7, 2018 at 23:45
  • Also, why would you even need to ssh to localhost?
    – marcelm
    Oct 7, 2018 at 23:45
  • This is often seen with automation, such as Ansible, and is a reasonable test when first learning ssh. It threw me off too, at first, but we can also assume that the OP, or other readers, will eventually ssh into remote hosts.
    – earthmeLon
    Oct 8, 2018 at 0:01
  • Users unaware of sudo sometimes implement access via ssh keys to be able to switch users.
    – earthmeLon
    Oct 8, 2018 at 0:08
  • @earthmeLon Nice speculation on why OP is doing ssh localhost, but I'd prefer to hear the actual reason from them ;)
    – marcelm
    Oct 8, 2018 at 0:26

1 Answer 1


You should take a look at this answer which describes configuring ssh for your user (editing ~/.ssh/config) and other details.

The steps are:

  1. Generate your ssh key.
  2. Add the Host to your ~/.ssh/config file.
  3. Add your Public (.pub) key to the remote user's ~/.ssh/authorized_keys
    • This is most easily done with ssh-copy-id command.
    • ssh is very particular about the permissions of ~/.ssh/ and the files found within. ssh-copy-id handles everything for you.
  4. Try connecting to the Host:
    • ssh host
    • ssh host -vvv # Verbose output for troubleshooting

Are you trying to use ssh-agent because your keys are protected by a password? I would recommend working on manually connecting without ssh-agent and getting that working. After you have your key working, you can work on solving any of the ssh-agent-specific issues.

To troubleshoot, be sure to use ssh in a verbose mode, and also monitor (tail -f) the remote server's /var/log/auth.log file. On newer systems, you may have to use journalctl (journalctl -u sshd | tail -f).

Once you've gotten the key working in general, you can look into ssh-agent documentation, such as this set of setup instructions. Typically the steps are as follows:

  1. Generate your keys (as you have already done).
  2. Install the keys (as you have already done).
  3. Start ssh-agent
    • eval ssh-agent
    • Only once, not each connection or anything.
    • You can have this happen automatically, depending on when and for which user.
  4. Add your key to ssh-agent:
    • ssh-add ~/.ssh/private_key

Be sure to look into other ssh-agent configuration options, such as the duration your keys will remain unlocked.

Boiling it down a bit, your problem is most likely one of these:

  1. You say you added ssh-agent starting, and the addition of your id_rsa key (in the past), but now that you've generated a new key, that key will also need to be ssh-add'd.
    • Check that ssh-agent is actually running on your system if you have problems after adding the key.
    • ps aux | ssh-agent
  2. You're adding the key to your local file, not the remote user's file.
    • Think of it like you're adding a password, so you need to add the password on the system which should accept it.
    • Your remote host is localhost, but this assumes you'll want to be able to work on remote hosts in the future. However, it still needs to be in the correct $HOME directory for the correct user.
  3. You say it works a single time? Does it work twice if you try two times in a shorter timeframe, say one minute? I am trying to understand if your ssh-agent is just set up to lock your key in a shorter timeframe than you've tested.
  4. When appending to the ~/.ssh/authorized_keys file (>>), you initially created the file, and this would be with incorrect permissions.
    • Do not do the following without securing access, and making backups to any remote files.
    • If your 'remote host' is localhost, it very likely has files you want to keep, such as your keys, and should be backed up before removal.
    • Delete the entire remote ~/.ssh/ directory and use ssh-copy-id to properly key your user on the remote host.
    • This would show up on the remote host's auth.log and specify that the file permissions are incorrect.
    • If you continue to experience issues after using ssh-copy-id to create the directory and files, post the permissions of ~/.ssh and your generated key files.
  5. After you ssh into the remote host, you lose ssh-agent, unless you have configured ssh-agent, and ssh via ~/.ssh/config to ForwardAgent yes. If you wish to forward ssh-agent, you'll have to configure it to allow that, and understand the security implications with that decision. It should also be noted that ForwardAgent may be designed to run on different machines, and it may not be possible to get forwarding working locally because of complications with ssh-agent already running.
  • THX: 2 problems. If I use 'eval ssh-agent' because when I use ssh-add id_rsa the system return me 'Could not open a connection to your authentication agent.' Then, I have to use 'exec ssh-agent bash'.
    – CGG
    Oct 7, 2018 at 21:35
  • The other problem: I said it works in a single time because I execute 'ssh localhost' and then I do not require to introduce the passphrase. If I execute again 'ssh localhost', then, I have to insert the passphrase.
    – CGG
    Oct 7, 2018 at 21:36
  • Hey, glad you're making some progress. Could you clarify if everything is working now that you ran exec ssh-agent bash? The How-To references this command: eval `ssh-agent`. Notice the backticks. Either way, we need to make sure ssh-agent runs a single time, and stays up. If I were you, I'd look into having ssh-agent start when you login to X, and verify it starts properly after restarting. Then use ssh-add and it should work. I'll update the Answer when I understand more of what you're doing to fix it :D
    – earthmeLon
    Oct 8, 2018 at 0:06
  • Maybe, I have solved it now. I had to reset Windows 10 to restart Ubuntu. I tried to do 'ssh localhost but it returned me ssh: connect to host localhost port 22: Connection refused'. I did the same steps than before (I found it in different webpages): purge and install open-ssh server, configure sshd_config (PermitRootLogin no,PasswordAythentication yes,AllowUsers myaccount,UsePrivilegeSeparation no). I did a service ssh --full-restart. After these steps, all worked fine, except the warning: Remote Host Identification has changed. The difference was the reboot of Windows 10.
    – CGG
    Oct 8, 2018 at 9:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .