I have zsh running on my Debian. It has the following lines in my .zshrc included:
plugins=(git ssh-agent)
zstyle :omz:plugins:ssh-agent helper ksshaskpass
zstyle :omz:plugins:ssh-agent identities id_odin id_git
My SSH Key "id_odin" has a password. Everytime I connect to a server, it keeps asking for the passphrase.
I tried to store the password for the agent so it will be remembered on reboot, but this unfortunately doesn't work.
When I try to add it to the keychain I get the following error:
ssh-add -K .ssh/id_odin
Enter PIN for authenticator:
Provider "internal" returned failure -4
Unable to load resident keys: device not found
I have no idea what the exact PIN for the authenticator might be.
Normal adding works but won't be remembered.
Enter passphrase for .ssh/id_odin:
Identity added: .ssh/id_odin (odin admin)
Related
I have a problem with ssh rsa key authentication. I'm using an SRX100H2 that is running JUNOS 12.1X46-D10.2. I generated a private/public key pair without password on an ubuntu host. I copied the public key in /var/tmp using scp on the SRX100H2 and committed the following changes:
user salvador {
uid 2001;
class super-user;
authentication {
ssh-rsa "ssh-rsa AAAA..."
}
}
I loaded the key with load-key-file command. The problem is I can't get authenticated. It's asking for the password every time, although the key has no password. I'm trying to use this account to run some script with fail2ban. To connect, I'm using:
ssh -i .ssh/name_of_the_key -l salvador x.x.x.x
I even went as far as modifying /var/etc/sshd_config on the SRX and added LogLevel DEBUG3, but for some reason it doesn't log so much information as a regular sshd linux daemon.
Is there a bug for this firmware version JUNOS 12.1X46-D10.2, or am I doing something wrong?
Thank you for your help.
I found a workaround. There is a python library named Junos PyEZ:
https://github.com/Juniper/py-junos-eznc
It can connect directly to a junos device using a username and password, without the need of an ssh key, and it can perform various configurations on the device. I managed to create a script that just adds an address in address book and adds that address in an address set that is applied to a security policy. This way the attacking host is banned and cannot access the exposed resources. The script is being run by fail2ban each time it is needed.
I am trying to clone a repo from a project on my Team Foundation Server domain. I have created an SSH key under my profile security. However after accepting the repo's key I am still requested to sign in with a password and the authentication fails:
git clone ssh://mydomain#mydomain.visualstudio.com:22/Project/_git/project-repo
Cloning into 'project-repo'...
mydomain#mydomain.visualstudio.com's password:
Permission denied, please try again.
mydomain#mydomain.visualstudio.com's password:
Permission denied, please try again.
mydomain#mydomain.visualstudio.com's password:
Permission denied (password,publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I have tried both my visualstudio.com password and SHH key password none of which work.But Why is it asking me for a password?
The prerequisite to use ssh for VSTS as below:
Generate ssh key. In git bash, use ssh-kengen in git bash -> select path to save the key -> enter passphrase (if you don’t want passphrase, press enter direcly).
Add the content of .ssh/id_rsa.pub file in KeyData in VSTS SSH public keys (profile -> security).
For your situation, it seems the conent of .ssh/id_rsa.pub is not same with VSTS SSH public keys. So you'd better do step1 and setp2 above and ten clone again with ssh protocol.
The way I resolved this was by deleting and recreating my id_rsa.pub without a password.
The default authentication mode when using SSH is the private key. Whenever that fails for some reason, the ssh-agent falls back to username and password based authentication.
There are several reasons why the default key based authentication might have failed. Following are the most common cases :
a) The ssh-agent cannot find the default private key file which is id_rsa, and no other key path is specified explicitly.
b) The public key stored in the server is incorrect.
c) The path you're trying to clone is incorrect.
In any case, to troubleshoot the issue first of all execute the git clone command with verbose logging with the command :
GIT_TRACE=1 GIT_SSH_COMMAND="ssh -vvv" git clone ssh://pathToYourRepo
You can go through each step in the log to get an intuition of what the issue might be.
Troubleshooting in case of (a)
Make sure you have the default key name id_rsa in the .ssh directory. You might have specified some different keyname when generating the key with ssh-keygen command or maybe there isn't any key at all).
In case you want to specify a different key for authentication, use the following command :
ssh-agent bash -c 'ssh-add ~/.ssh/anotherKey; git clone ssh://pathToYourRepo'
Troubleshooting in case of (b)
Make sure there aren't extra white spaces when storing the public key in the server.
Troubleshooting in case of (c)
Make sure you aren't trying to clone with the https version of the repository path.
On an Ubuntu server, 'foo.com', that serves gitlab, a gitlab user, 'bar', can clone, push, and pull without having to use a password, with no problem (public key is set up on the gitlab server for user 'bar').
User 'bar' wants to use the command line on the server 'foo', and does ssh bar#foo.com. When user 'bar's ssh keys are not in 'foo''s authorized_keys, 'bar' is logged momentarily into Gitlab:
debug2: shell request accepted on channel 0
Welcome to GitLab, bar
and then that session promptly exits.
When user 'bar's ssh key - even one that is not registered with GitLab - is in 'foo.com''s authorized_keys, then that user gets the expected result when doing ssh bar#foo.com. However, then user bar (on their local computer) is unable to push, pull, clone, etc. from their gitlab-managed repository, with the error message being that "'some-group/some-project.git' does not appear to be a git repository".
It appears that there is a misconfiguration such that shell access is mixed up with gitlab project access.
How can user 'foo' be able to both login via ssh to a regular shell prompt and also use git normally (interacting with the remote git server from their local box)?
After a lot of searching I got to know why this was happening on my end. I had the same issue. I wanted to use the same SSH key for both SSH login as well as GitLab access.
I found this thread helpful:
https://gist.github.com/hanseartic/368a63933afb7c9f7e6b
In the authorized_keys file, the gitlab-shell enters specific commands to limit the access. It adds the limitation once the user enters the public key through web interface. It uses the command option to do so.
We would need to modify the command option to allow access to bash and remember to remove the option of no-pty if listed in the comma-separated section. For example in my case I had this within the line: no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty and had to remove no-pty from the list.
A sample modified command should look like this:
command="if [ -t 0 ]; then bash; else /home/ec2-user/gitlab_service/gitlab-shell/bin/gitlab-shell key-11; fi",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAA...
Need to be mindful to edit the correct command by checking the key number or the publickey and username associated with the command.
This did not require any service restart.
I'm new to GitHub and experimenting with my first repo. I'm using my Mac which was used by my friend for few days. Now the problem is, as I tried to push my first commit, I see an error that says -
remote: Permission to myUserName/repo.git denied to myFrndsUserName.
fatal: unable to access 'https://github.com/myUserName/repo.git/': The requested URL returned error: 403
I understand that my friend has used his credentials earlier and those are mismatching with my credentials as I tried to push my code. In best case, I would like to replace my friend's credentials with mine and I don't have to give my username and password everytime for different repos that I create in the near future.
Can somebody help me with this? Thank you.
Try this:
Open terminal :
Enter: ls -al ~/.ssh to see if existing SSH key are present in your case may be your friend have removed your previous SSH key.
if dont have any public or private key pair or if you do not want to use those keys available you have to generate new one.
$ ssh-keygen -t rsa -b 4096 -C "your_email#exaple.com"
# Creates a new ssh key, using the provided email as a label
When you are prompted to "Enter a file which to save the key" press Enter. this accepts the default file location.
At the prompt, Type a secure passphrase. For more info see "Working with SSH Key"
Add SSH key to your GitHub account
Copy the SSH key to clipboard.
If your SSH key file has a different name than the example code, modify the filename to match your current setup. When copying your key, don't add any newlines or whitespace.
$ pbcopy < ~/.ssh/id_rsa.pub
To follow further steps click here
Let me know if this doesn't work out properly
In SourceTree I'm using OpenSSH as authentication and created + added my SSH keys (on Windows) like this:
ssh-keygen -t rsa -C "my#email.com"
(and entered filename, password etc)
Added the key to the SSH agent:
eval "$(ssh-agent)"
ssh-add id_rsa
Added the SSH key to GitLab using
cat id_rsa.pub to print my public key
Added the public key to SourceTree by "Tools > Add SSH key" followed by the password ("Tools > options > SSH client configuration" I've selected OpenSSH).
After these steps I'm able to push and pull code.
However, each time I restart SourceTree a terminal pops-up and I have to re-enter my password again*. How can I make SourceTree / the SSH agent remember this password?
ps. my keys are saved in a directory like /d/MyName/Gitlab/ instead of ~/.ssh/ but that shouldn't be a problem, right?
EDIT:
*The message shown in the terminal:
SourceTree is loading your SSH key into the agent for authentication Please enter your passphrase if prompted to do so Enter passphrase for D:\MyName\GitLab\.ssh\id_rsa:
EDIT2:
This solution didn't solve my problem either:
You can use the Windows OpenSSH ssh-agent to manage your keys.
The problem is that Sourcetree on windows wants to start its own instance of the ssh-agent instead of using the already running service. Even if you can get that to work it will still prompt for your key passphrase on startup because Sourcetree's ssh-agent process doesn't save your keys to the the Windows keychain.
There are heaps of instructions on how to use Pageant as your ssh agent, but that is not why you're here. You're here because you want to use the OpenSSH agent, with OpenSSH formatted keys, with passphrases but without being prompted for said passphrase all over the place.
The trick is to proxy all requests to Pageant through to your OpenSSH agent.
Install OpenSSH.
Start the ssh-agent service and set to automatic.
Add your private keys to the agent with
ssh-add <key_file>
Add your public keys to the hosts you want to authenticate with.
Test that you can authenticate via ssh:
ssh -T git#github.com
Your private keys will now be loaded when you log in to your Windows account and you won't have to provide passphrases ever again.
To allow programs and libraries such as Sourcetree, WinSCP and Fabric that normally use Pageant to instead have keys provided by the ssh-agent there is an awesome program https://github.com/ndbeals/winssh-pageant
Follow instructions to install winssh-pageant, schedule it as a task to start on windows startup.
Now all calls to Pageant's NamedPipe will be proxied to the OpenSSH agent.
The last step to get SourceTree working with OpenSSH is a bit counter-intuitive.
Go to Tools | Options | General and set the SSH Client to PuTTY/Plink and uncheck the "Automatically start SSH agent when Sourcetree opens".
I solved this issue following these steps:
Find the path to Pageant (in my case was in C:\Users\{my-user}\AppData\Local\SourceTree\app-3.3.8\tools\putty\pageant.exe)
Do Window key + R or type run in Windows bar
In the text box put shell:startup
Make a shortcut of your pageant and paste it in the window that just opened
Right click on the shortcut and click on Properties
In Shortcut tab, in target put your-sourcetree-pageant-path\pageant.exe id_rsa.ppk
In Start in put C:\Users\{my-user}\.ssh and click ok
Note that your id_rsa.ppk must be inside C:\Users\{my-user}\.ssh directory
If for some reason your id_rsa.ppk is protected by a passphrase and you are sure you won't have security issues. Just remove the passphrase.
To remove the id_rsa.ppk's passphrase, follow these steps
Open PuttyGen
Go to Conversions => Import key
Remove the passphrase
Save the private key & public key
Replace the protected id_rsa.ppk with the unprotected id_rsa.ppk
Hope that helped!
You manually start your agent and set environment variables in order for commands to find it.
Whenever you start your a command (like SourceTree) without those environment variables set, that command is not able to access the agent and therefore asks for your password.
Making your agent start on system startup should solve things.
If ssh cannot reach the agent it will also look into ~/.ssh/ therefor if you place you keys there it should work, too. (Have a look at man ssh.)
After did below test, the password never asked for me.
To test whether your SSH key was added correctly, run the following command in your terminal (replacing gitlab.com with your GitLab's instance domain):
ssh -T git#gitlab.com
The first time you connect to GitLab via SSH, you should verify the authenticity of the GitLab host that you're connecting to. For example, when connecting to GitLab.com, answer yes to add GitLab.com to the list of trusted hosts:
The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitlab.com' (ECDSA) to the list of known hosts.
NOTE: Note: For GitLab.com, consult the SSH host keys fingerprints, section to make sure you're connecting to the correct server. For example, you can see the ECDSA key fingerprint shown above in the linked section.
Once added to the list of known hosts, you should validate the authenticity of GitLab's host again. Run the above command once more, and you should only receive a Welcome to GitLab, #username! message.
If the welcome message doesn't appear, you can troubleshoot the problem by running ssh in verbose mode with the following command:
ssh -Tvvv git#gitlab.com