I'm using OpenSSH for Windows on Windows 10 v1809. I've added an identity via ssh-add which required I enter the password for my encrypted key (C:\Users\Me\.ssh\id_rsa). I find that identity remains in ssh-agent after I restart Windows. Therefore, I can ssh to other machines without entering the key's password. In previous agents I've used, such as the one in MobaXterm (not OpenSSH), there was a master password used to unlock all keys saved to the agent. You had to re-enter that one master password after restarting.
Is this behavior in OpenSSH for Windows of no password being required after restart expected?
Perhaps I could write a script to ssh-add -D on Windows shutdown if don't want the identities to be saved?
Related
Problem:
I am trying to use OpenSSH Agent in Windows 10 Pro. It is loading the keys but not forwarding to the host.
Goal:
I am attempting to get ssh-agent to work in Windows so I don't have to keep entering my passphrase for my private key (with the ultimate goal of getting this to work with VS Code Remote-SSH Extension as well as on the command line).
What I've Tried:
I am using Windows 10 Pro 21H2 build 19044.1865. I have OpenSSH installed. In Powershell (admin mode), I use ssh-add to add my private key and confirm by doing ssh-add -L which shows the key is loaded (X'd out in example):
ssh-add -L
ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (redacted)
I then attempt ssh -A username#serverip and it prompts me for my passphrase. The expected behavior is that it would not prompt me for my passphrase, it would simply obtain the key from the ssh-agent service. I have tried both rsa and ed25519 keys formatted as OpenSSH keys with the same result.
If I enter my passphrase I immediately connect. I have tried all the suggestions I could find online including:
killing all ssh-agent processes shown in task manager and restarting
starting and restarting the OpenSSH Authentication Agent
fixing the permissions on my keys so only I as owner have access
It appears that the ssh-agent has loaded the key but is simply not passing it on to my server for some reason. Using the -v (verbose) option shows no attempt to use ssh-agent forwarding. I have used putty/pageant successfully and have even tried wsl-ssh-pageant which seems to work, loading my key from pageant (the Pageant keys viewable as loaded after doing ssh-add -L) but they are ignored when I attempt a connection (again nothing in the verbose output shows attempt to use the ssh-agent). The OpenSSH agent is clearly running in Windows services.
Any suggestions or help ? Thank you.
I've created GIT repo at my account of shared hosting via cPanel. Then I've installed Git to my local PC with Windows, right-clicked local repo folder and selected the command "Git Bash Here". Next I've run in CMD the command like
git clone ssh://user123#example.com/home/user123/public_html/repo
First I've received
The authenticity of host 'example.com (...)' can't be established.
ED25519 key fingerprint is SHA256:...
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?
I've typed "yes" and received the error
Warning: Permanently added 'example.com' (ED25519) to the list of known hosts.
user123#example.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Next I've copy-pasted the file id_rsa from the folder .ssh at my hosting to my local folder C:/Users/MyUserName/.ssh
Now if I run the command of cloning I receive
Enter passphrase for key '/c/Users/MyUserName/.ssh/id_rsa':
Why? What is the passphrase and where can I get it?
The pass-phrase is the password(s) you used when you created the ssh keys. You must use those password(s) to unlock access to the ssh keys.
Note that the warnings (about whether the host is known or not) are just that: warnings. The first time you connect to some other system, your ssh software checks the identity message that comes from that host. But there's nothing to check against, so you get the warnings. After that, the identity is saved, so the second, third, etc., times that you connect to the host, your ssh makes sure it identifies itself the same way. (This is a fancied-up variant of having the host tell you its password, which you then check to make sure you're still talking to the same guy.)
Of course, the host doesn't know whether the guy claiming to be you is really you, so the host demands that you provide your password. Your "password" in this case is your ssh key ... and your ssh key is protected with another password (or rather, "pass phrase": you can use multiple words). So you give your machine your "get me the password" pass-phrase, after which your machine gets the password to give to their host.
I keep most of my personal projects on BitBucket by Atlassian. As a natural choice, I use SourceTree app (their product) as git GUI client on Windows, and I'm happy with it. For projects where ssh git is available, I prefer ssh over https. SourceTree plays very well with projects hosted on BitBucket. Although it offers both of ssh agents: OpenSSH or PuTTY, its default selection is PuTTY/Plink (perhaps because PuTTY is more Windows-familiar).
Recently my establishment requested to host some projects on its own server. At first look it's a git server using GitLab opensource. I can use SourceTree with project hosted here using https just fine, however when it comes to ssh, the only choice of SSH agent is OpenSSH. The only key pair it would use (unless specified in config) is ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa (located in %USERPROFILE%\.ssh\
I've tried to:
Load ~/.ssh/id_rsa into PuTTY Key Generator
Convert it to PuTTY format (.ppk) file
Load the .ppk into Pageant (PuTTY authentication agent).
Despite the key being loaded and kept in the memory by Pageant, the connection with the server failed all the time, e.g. git: fatal: Could not read from remote repository. The only way to make it work is to start ssh-agent and ssh-add (go with OpenSSH).
Since I have Pageant running usually in the background, I find it more convenient to use (e.g. the keyphrase to open the private key is long/complex, and I don't remember it, and it can be copy-pasted from KeePass, while in the case of OpenSSH, cmd console does not allow me to paste it, too bad).
Is there anyway to make the ssh authentication to GitLab done via PuTTY instead of OpenSSH?
Did you connect to the SSH server using PuTTY before using plink? If not a reason could be that plink is refusing to connect to the server, because the ssh hostkey isn't verified yet. Another reason could be that the SSH server requires ciphers which are not supported by PuTTY. You can only find out if you connect with PuTTY with the same version as plink.
Use TortoiseGitPlink (from TortoiseGit) to circumvent this issue, as it will popup a messagebox asking whether to accept the hostkey or not.
PuTTY fatal error:
No supported authentication methods available
When I tried to login into the production server, I am getting above error. Could anyone help me to fix this?
Edit file
sudo vi /etc/ssh/sshd_config
Set PasswordAuthentication yes
Then restart server
sudo service ssh restart
sudo service sshd restart
It worked for me after I did the following steps :
1- Download Puttygen (https://www.puttygen.com/download-putty)
2- Open PUttyGen and then Load the private key from :
C:\Users[username]\Chapter6.vagrant\machines\default\virtualbox
3- save the new private key with a new name.
4- Open Putty, go to Connection > SSH > Auth > and add the new private key
5- Connect now using 127.0.0.1 and 2222
I think your private key file format is not compatible with putty for putty uses its' native format instead.
Detail:http://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter10.html#errors-no-auth
If you are using cloud service and trying to connect server using ssh then Don't login the user name as ec2-user, the default user name is ubuntu forubuntu server.
This error can also be seen if you haven’t selected the .ppk file for the session in Putty: Connection > SSH > Auth
You’re done if you’ve employed PuttyGen to generate the keys. Else import the private key to your .ppk file as others have instructed.
Note on Linux as opposed to Windows, puttygen is accessed only via the command line. Here’s some resources for that:
https://the.earth.li/~sgtatham/putty/0.76/htmldoc/Chapter8.html#pubkey
http://manpages.ubuntu.com/manpages/bionic/man1/puttygen.1.html
https://www.ssh.com/academy/ssh/putty/linux/puttygen
In my case, I updated the Putty application to the latest and issue was solved.
Do you still have access to the server (maybe an open shell?) Check /var/log/messages for more details. This could have something to do with your PAM configuration.
Did you change folder permissions? i met this question in this week, so i find the error that is cause to me change the folder(name is ec2-user) permission.
1.Edit the /etc/ssh/sshd_config file.
2.Change PasswordAuthentication and ChallengeResponseAuthentication to yes.
3a. Restart ssh /etc/init.d/ssh restart.
OR
3b. better you use service sshd restart
If you've saved your public key on an external drive and it's not connected, putty will throw this error when connecting to your remote server.
Solved via Puttygen
I was on a windows system and it doesnt support direct shell access like linux or macOS.
Download Puttygen.
Load the .pem key to puttygen
Save as Private key
Use this key to login to ec2 instance
P.S : Also if the SSH ask for login/username - enter ubuntu or admin
Download Puttygen
Load the .pem key to puttygen
convert .pem file to .ppk
Save as Private key
Install/Open Putty >> puTTY Configuration >> Auth >> Browse >> path to .ppk file
Use this key to login to ec2 instance (check that IP of remote server is allowed in security group config of EC2 instance)
Username
The usual user names are ec2-user, ubuntu, centos, root, or admin
If that server is in the cloud like AWS, the rookie mistake I did was not realizing that a new Public IPv4 DNS gets used when the instance was off for some time. So, check the new DNS
Today I faced the same problem. So in putty you have to use "user name" of your EC2 instance
to get your "user name" of your EC2 instance
Select EC2 instance
select Connect
Now go to putty use ec2_name#public address
To see your public address
select EC2
under details you will be able to see your public address.
Now try loading your "ppk" file you will be able to log in.
For Digital Ocean, we should enable password authentication first.
The complete instruction is here: https://docs.digitalocean.com/support/i-lost-the-ssh-key-for-my-droplet/#enable-password-authentication
Log in to the Droplet via the Recovery Console
Even though you have a root password for the Droplet, if you try to log in via SSH using that password immediately, you’ll receive a Permission denied (publickey) error. This is because password authentication is still disabled on the Droplet. To fix this, you need to log in via the Recovery Console and update its SSH configuration.
There are detailed instructions on how to connect to Droplets with the
Recovery Console for a more explicit walkthrough, but here’s a brief
summary:
On the Droplet’s detail page, in the same Access tab, click the Launch
Console button.
At the login prompt, enter root as the username.
At the subsequent password prompt, enter the root password you were
sent via email. Most distributions prompt you to enter the password
twice, but some (like Fedora 27) do not.
Enter a new root password to replace the one that was emailed to you,
then enter that same new password again.
You will now be logged in as root in the Recovery Console, which gives
you access to the Droplet’s SSH configuration.
Enable Password Authentication To enable password authentication on
your Droplet, you need to modify a line in its SSH config file, which
is /etc/ssh/sshd_config.
Open /etc/ssh/sshd_config using your preferred text editor, like nano
or vim. Find the line that reads PasswordAuthentication no line and
change it to PasswordAuthentication yes, then save and exit the file.
Because the SSH daemon only reads its configuration files when it’s
first starting, you need to restart it for these changes to take
effect. The command to do this depends on your operating system:
Operating System SSH Restart Command
Ubuntu 14.x service ssh restart
Ubuntu 15.4 and up systemctl restart ssh
Debian systemctl restart ssh
CentOS 6 service sshd restart
CentOS 7 systemctl restart sshd
Fedora systemctl restart sshd\
Ok, so I have Hudson (v1.393) running in an Ubuntu VM and everything's working fine.
However I'm trying to add a Mac slave to the Ubuntu master and I've run in to a few problems.
I have set up SSH keys so that from the command line, the Ubuntu VM can ssh using the key into a user called hudson on the Mac.
In the Hudson slave configuration, I have "Launch slave agents on Unix machines via SSH" selected and have entered the host IP, username of the user on the slave and the location of my private key file on the master (which has been added to the authorised keys file on the slave).
However, the master fails to connect to the slave.
Looking at the log (below), it's trying to authenticate using a password.
Is this a fall back for a failed key based SSH attempt?
Is Hudson only trying to authenticate using a password, and I need to change something else to get it to use the key file which is defined in the configuration?
Is it just not possible to launch slave agents via ssh on a mac? (I know the name of this type of slave launch method explicity states Unix, but I was thinking (read: hoping) that it would work with OS X too)
Log
[01/14/11 10:38:07] [SSH] Opening SSH connection to 10.0.1.188:22.
[01/14/11 10:38:07] [SSH] Authenticating as hudson/******.
java.io.IOException: Password authentication failed.
at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:319)
at com.trilead.ssh2.Connection.authenticateWithPassword(Connection.java:314)
at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:565)
at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:179)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:184)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.IOException: Authentication method password not supported by the server at this stage.
at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:289)
... 9 more
[01/14/11 10:38:07] [SSH] Connection closed.
If anyone has managed to conquer this type of set up before, or has any tips or ideas, I'd be very grateful!
Thanks
I've recently run into the same problem, trying to launch an agent on a Mac OS X 10.6 machine using SSH.
To get password authentication to work you'll need to edit /etc/sshd_config on the client node, setting PasswordAuthentication yes
In the Hudson dashboard take the node offline, make sure the configuration has a valid username and password, and launch the agent. Also make sure that the Remote FS root directory is owned by the build user you're connecting as.
For password-less ssh authentication, first check which user the Hudson master is running as. Lets assume that this is tomcat55. Generate a public/private SSH key pair (with an empty passphrase), then verify that the Hudson user can connect.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tomcat55/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tomcat55/.ssh/id_rsa.
Your public key has been saved in /home/tomcat55/.ssh/id_rsa.pub.
$ # authorize the hudson master on the hudson node
$ scp /home/tomcat55/.ssh/id_rsa.pub hudson#macnode:~/.ssh/authorized_keys
$ # test the connection
$ ssh -i /home/tomcat55/.ssh/id_rsa hudson#macnode
On the Hudson mac node, the /etc/sshd_config needs to allow for password-less access.
Protocol 2
PubkeyAuthentication yes
In the node configuration clear the password field, and set the private key field (in this example it is /home/tomcat55/.ssh/id_rsa). You should now be able to launch the agent:
[01/19/11 22:38:44] [SSH] Opening SSH connection to macnode:22.
[01/19/11 22:38:44] [SSH] Authenticating as hudson with /home/tomcat55/.ssh/id_rsa.
[01/19/11 22:38:45] [SSH] Authentication successful.
Check the /var/log/auth.log file on the Ubuntu machine. I'm betting you need to chmod 700 the .ssh directory of the hudson user.
I think the first answer (the selected one) is an awesome answer, but I did find a case where it is not the only solution.
In my case I have a Mac OS slave that was working and then I took that Mac down and brought up a new one. I thought I could just tweak the settings for the existing node's configuration to point it at the new Mac. It didn't work and I had all the same errors and problems described throughout this message thread.
Then I went in and deleted the node and recreated it with exactly the same settings and it worked. I suspect that SSH key fingerprint changed and by deleting the node and recreating it I was able to get it working. Whatever it is, the key component that caused it to fail is not a configuration option.