scp from Amazon ec2 is hanging, but SSH works fine - amazon-ec2

I'm trying to copy a file from an ec2 instance to my local machine. Here's the command:
scp -v -i commoncrawl_practice.pem ec2-user#ec2-54-86-8-91.compute-1.amazonaws.com:/home/ec2-user/testfile .
And here's where it hangs:
debug1: Trying private key: commoncrawl_practice.pem
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to ec2-54-86-8-91.compute-1.amazonaws.com ([54.86.8.91]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -f /home/ec2-user/testfile
Thanks in advance.

Check if you have a ~/.bashrc file on the destination which prints stuff to your terminal. If yes, disable it for non-interactive shells by inserting
[[ $- == *i* ]] || return
before printing anything.
(solution found on https://unix.stackexchange.com/questions/18231/scp-fails-without-error)

Try SFTP as an alternative to SCP.

Related

Shh connection, in a Jenkins pipeline, disconnects after login

Scenario: I'm developing a jenkins step that needs to transfer a file to a machine (install a jboss module). I'm trying to do it via ssh interactions. I need to connect via ssh, switch to an authorized user in order to access jboss folders/files, and then use rsync to transfer the jar file inside jboss modules folder. I cannot use the same user to ssh and jboss.
Problem: I can successfully connect via ssh, but when I send the first command (to switch user), it disconnects and then nothing works anymore. Appearently is disconnecting before the 'su' command is executed. The next command would be to check if module folder exists (and create it if doesn't).
The sequence of commands is executed inside a function:
def installModule(HOST, USER, PASSWORD) {
sh set -x && sshpass -p [PASSWORD] ssh -v -tt -o StrictHostKeyChecking=no [USER]#[HOST] echo [PASSWORD] | sudo -S su - jboss && cd [MODULE_FOLDER] && if [[ ! -e [MODULE_VERSION] ]]; then mkdir [MODULE_VERSION]; fi
}
The console output:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to [MACHINE_NAME_HERE] ([IP_HERE]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00#openssh.com want_reply 0
debug1: tty_make_modes: no fd or tio
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: echo [PASSWORD_HERE]
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Connection to [MACHINE_NAME_HERE] closed.
Transferred: sent 2180, received 3356 bytes, in 0.3 seconds
Bytes per second: sent 7006.2, received 10785.6
debug1: Exit status 0
Sorry, try again.
[sudo] password for jenkins: Sorry, try again.
[sudo] password for jenkins:
sudo: no password was provided
sudo: 2 incorrect password attempts
Any help would be appreciated =)
I had to do something similar, in my case, I opt for having a shell script file in my environment containing all the commands I needed to be executed on the remote machine.
I did it like this:
withCredentials([
usernamePassword(credentialsId: "$VM_CREDENTIALS", usernameVariable: 'USER_VM', passwordVariable: 'PWD_VM')
]) {
script {
sh 'sshpass -p $PWD_VM ssh -o StrictHostKeyChecking=no $USER_VM#$IP_VM "bash -s ' + "$VARIABLE_A $VARIABLE_B" + '" < path/to/shell/script.sh'
}
}
I used $VARIABLE_A and $VARIABLE_B to pass some arguments to the script. The $path/to/shell_script.sh represents the path to the script placed in your Jenkins environment to be executed on the remote machine.
I also had to switch users in the shell script, I did it like so:
# Switch to root user
echo $PWD | sudo -S sleep 1 && sudo -E su
Remember, don't define the $PWD variable hardcoded somewhere, you need to take security measures.

ssh works with my custom shell but can't execute commands directly using ssh

I searched through the website but could not find a similar problem and a solution. So asked a new question.
I'm trying to build a custom shell with some limited commands. As an start point, I'm using this custom shell provided by Stephen Brennan. It has 3 built-in commands (cd, help, exit) and also can execute system commands.
I edited this line in /etc/passwd:
root:x:0:0:root:/root:/mnt/n1/custom-shell
and also added this line to /etc/shells:
/mnt/n1/custom-shell
Now I can connect to remote host using ssh and my custom shell comes up and I can enter commands in it; but I can't execute commands directly using ssh. for example when i try to run "help" command on remote host using ssh 192.168.32.1 help, nothing happens. I tried ssh -v 192.168.32.1 help and the result is as follows. It sticks at debug1: Sending command: help.
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.32.1 [192.168.32.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.32.1' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
root#192.168.32.1's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: help
As a result I can't copy files to remote host using scp -v devel/bin/i2c root#192.168.32.1:/mnt/n1/ and it sticks at this line:
debug1: Sending command: scp -v -t /mnt/n1/
I searched alot but could not come to an answer. Any help would be appreciated.
One of the standard ways to invoke a shell and have it run a command is to invoke the shell program with the command-line parameters -c and the command to run. This is the method used by the OpenSSH SSH server to invoke commands requested by clients.
When an SSH client connects to the OpenSSH server and requests to run a command on the server, the server ends up invoking the equivalent of this:
$SHELL -c 'the-command'
where $SHELL is the default shell for the user, -c is a literal command-line option, and the-command is the command requested by the client. The command is passed to the shell as a single command-line argument.
In your case, the shell will be your custom shell program. It will need to parse its command-line parameters to pick up the fact that it was run with "-c" and a command string. Then it'll have to execute the command that was specified on the command line, instead of reading commands from an input stream.
Like any other C program, the entry point into your shell program is a function called main:
int main(int argc, char **argv)
{
...
When your shell is invoked from the SSH server in this fashion, you should find that argc and argv will reflect the command-line arguments ["/name/of-shell", "-c", "the-command"]. There are standard functions like getopt(3) that you can call to help parse the command-line arguments.
I'll add that scp works by having the server invoke a program through your shell. So you'll see your custom shell being invoked (with a -c parameter and a command to run) for scp sessions. You may also see this for sftp sessions, depending on how the server is configured.

Adding users to ec2 - ssh works, but scp does not

As the "ec2-user", we can SSH and SCP to our EC2 instance just fine.
As any other user, we can SSH just fine, but cannot SCP.
Instead, when trying to SCP as any user other than "ec2-user", our ec2 instance spawns a new (dup) ssh-agent and does not receive files.
--
We use ssh-agent and each user ssh-add their own .pem key.
Their public key is added on the remote ec2 instance, in each user's ~/.ssh/authorized_keys. Again, our config works fine for SSH.
The contents of (local) /home/jonathan/.ssh/config is:
Host my-ec2.com
User jdoe
Hostname 123.123.123.123
ForwardAgent yes
IdentityFile /Users/jonathan/.ssh/key.pem
And there is no remote ~/.ssh/config on ec2, we just used the system defaults.
I'm really not sure why the local and/or remote ssh-agent's work differently with SSH than they do with SCP.
Any help would be appreciated!!
DEBUG INFO
This works -- ssh as "ec2-user":
$> ssh-add /Users/jonathan/.ssh/key.pem
$> ssh ec2-user#my-ec2.com
This works too -- ssh as "jdoe":
$> ssh-add /Users/jonathan/.ssh/key.pem
$> ssh jdoe#my-ec2.com
This also works -- scp as "ec2-user":
$> ssh-add /Users/jonathan/.ssh/key.pem
$> scp foo.txt ec2-user#my-ec2.com:~/.
foo.txt 100% 197 2.5KB/s 00:00
This does NOT work -- scp as "jdoe":
$> ssh-add /Users/jonathan/.ssh/key.pem
$> scp foo.txt jdoe#my-ec2.com:~/.
Agent PID 12345
Additionally, every failed scp attempt creates a duplicate ssh-agent on ec2
$> ssh-add /Users/jonathan/.ssh/key.pem
$> ssh jdoe#my-ec2.com
$> ps -x | grep ssh-agent
11677 ? Ss 0:00 ssh-agent
11708 ? Ss 0:00 ssh-agent
11742 ? Ss 0:00 ssh-agent
11919 ? Ss 0:00 ssh-agent
12345 ? Ss 0:00 ssh-agent
### a duplicate copy if ssh-agent is running with PID 12345
### there are as many ssh-agent running as failed SCP attempts...
Here's a copy of the full "scp -v" output:
$> scp -v foo.txt jdoe#my-ec2.com:~/.
Executing: program /usr/bin/ssh host my-ec2.com, user jdoe, command scp -v -t ~/foo
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/jonathan/.ssh/config
debug1: /Users/jonathan/.ssh/config line 2: Applying options for *
debug1: /Users/jonathan/.ssh/config line 7: Applying options for my-ec2.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 123.123.123.123 [123.123.123.123] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jonathan/.ssh/cps-keypair.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jonathan/.ssh/cps-keypair.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 123.123.123.123:22 as 'jdoe'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:j4kSCIWNUz5k7LHHK+n9iR9kxktihrD4X/srX4uX/5U
debug1: Host '123.123.123.123' is known and matches the ECDSA host key.
debug1: Found key in /Users/jonathan/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/jonathan/.ssh/cps-keypair.pem
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 123.123.123.123 ([123.123.123.123]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00#openssh.com want_reply 0
debug1: Sending command: scp -v -t ~/foo
Agent pid 24732
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2812, received 2696 bytes, in 0.2 seconds
Bytes per second: sent 15501.9, received 14862.4
debug1: Exit status 0
Start ssh-agent on your EC2 instance only for interactive sessions. You will not need it for scp, and it's output causes your scp to fail.
Apparently ssh-agent gets called during login on your EC2 instance (e.g. in your Bash profile).
To prevent it from starting, adjust your profile script on your EC2 instance - e.g. by adding a if statement like this one (assuming you're using Bash on your EC2 instance):
if [[ "$-" == *i* ]]; then
# <start ssh agent here>
fi

Github permission denied: ssh add agent has no identities

This is my first time accessing GitHub and I'm not experienced using a console. I am on a MacBook using Bash. When I try to access GitHub, I get this:
git clone git#github.com:dhulihan/league-of-legends-data-scraper.git
Cloning into 'league-of-legends-data-scraper'...
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I've tried following the instructions on Github page about permission being denied.
When I use ssh -vT git#github.com, I get the following:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to github.com [192.30.252.129] port 22.
debug1: Connection established.
debug1: identity file /Users/XXXX/.ssh/id_rsa type -1
debug1: identity file /Users/XXXX/.ssh/id_rsa-cert type -1
debug1: identity file /Users/XXXX/.ssh/id_dsa type -1
debug1: identity file /Users/XXXX/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version libssh-0.6.0
debug1: no match: libssh-0.6.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/XXXX/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/XXXX/.ssh/id_rsa
debug1: Trying private key: /Users/XXXX/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
Next, eval "$(ssh-agent -s)" returns "Agent pid 2314",
however ssh-add -l returns "The agent has no identities."
And that is where I am stuck.
Full details in this answer.
In summary, when ssh-add -l returns “The agent has no identities”, it means that keys used by ssh (stored in files such as ~/.ssh/id_rsa, ~/.ssh/id_dsa, etc.) are either missing, they are not known to ssh-agent, which is the authentication agent, or that their permissions are set incorrectly (for example, world writable).
If your keys are missing or if you have not generated any, use ssh-keygen -t rsa, then ssh-add to add them.
If keys exist but are not known to ssh-agent (like if they are in a non-standard folder), use ssh-add /path/to/my-non-standard-ssh-folder/id_rsa to add them.
See this answer if you are having trouble with ssh-add or ssh-agent.
try this:
ssh-add ~/.ssh/id_rsa
worked for me
THE 2019 ANSWER for macOS Sierra & High Sierra & Catalina:
PS: most of the other answers will have you to create a new ssh key ... but you don't need to do that :)
As described in detail on https://openradar.appspot.com/27348363, macOS/OS X till Yosemite used to remember SSH keys added by command ssh-add -K <key>
So here are the 4 steps i had to take in order for it to work:
1: ssh-add ~/.ssh/PATH_TO_YOUR_SSH_PRIVATE_KEY (e.g. ~/.ssh/id_rsa)
2: Add the following in ~/.ssh/config
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile PATH_TO_YOUR_SSH_PRIVATE_KEY (e.g. ~/.ssh/id_rsa)
3: make sure to remove any gitconfig entry that use osxkeychain helper:
https://github.com/gregory/dotfiles/commit/e38000527fb1a82b577f2dcf685aeefd3b78a609#diff-6cb0f77b38346e0fed47293bdc6430c6L48
4: restart your terminal for it to take effect.
I have been stucked a while on the same problem, which I eventually resolved.
My problem: I could not execute any push. I could check & see my remote (using git remote -v), but when I executed git push origin master, it returned : Permission denied (publickey). fatal: Could not read from remote repository. and so.
How I solved it :
I generated a key using ssh-keygen -t rsa. Entering a name for the key file (when asked) was useless.
I could then add the key (to git): ssh-add /Users/federico/.ssh/id_rsa , which successfully returned Identity added: /Users/myname/.ssh/id_rsa (/Users/myname/.ssh/id_rsa)
I added the SSH key to github using this help page.
Having tried all the commands in Github's 'Permission denied publickey' help page, only the ssh-add -l command worked / seemed useful (after having ran the previous steps), it successfully returned my key. The last step shows you where to check your public key on your GitHub page. And this command will help you check all your keys : ls -al ~/.ssh.
Then the push command eventually worked !
I hope this will help !
Best luck to all.
Run the following commands:
ssh-keygen -t rsa
ssh-add /Users/*yourUserNameHere*/.ssh/id_rsa**
pbcopy < ~/.ssh/id_rsa.pub**
Go to your Github account : https://github.com/settings/profile
1) Click : SSH and GPG keys
2) New SSH Key and Past it there
3) Add SSH Key
Done!
tl;dr
ssh-add # no parameter
# Identity added: /home/<user>/.ssh/id_rsa (user#host)
Further readings
two files necessary in the ssh - user - folder:
ls ~/.ssh
id_rsa id_rsa.pub
If the files are not there, enter command ssh-keygen
Now start the ssh-agent:
eval `ssh-agent -s`
Verify
ssh-add -l
# voila:
2048 SHA256:<key one> user#host (RSA)
Bonus
check the local SHA256 from above with the Github SHA256 from your user settings -> SSH Keys. If they are equal you should be able to push/pull to/from Github using your keys.
first of all you need to go in your ssh directory
for this type following command in your terminal in mac or whatever you use in window
cd ~/.ssh
now it is in the ssh
here you can find all you ssh key/files related to your all projects. now, type the following command to show you if any ssh key available
ls
this will show you all available ssh, in my case there were two
now, you will need to start an agent to add a ssh in it. For this type following command
eval "$(ssh-agent -s)"
now last but not least you will add a ssh in this agent type following command
ssh-add ~/.ssh/your-ssh
replace
replace your-ssh with your ssh file name which you got a list form second step ls command
This could cause for any new terminal, the agent id is different.
You need to add the Private key for the agent
$ ssh-add <path to your private key>
This worked for me:
chmod 700 .ssh
chmod 600 .ssh/id_rsa
chmod 644 .ssh/id_rsa.pub
Then, type this:
ssh-add ~/.ssh/id_rsa
For my mac Big Sur, with gist from answers above, following steps work for me.
$ ssh-keygen -q -t rsa -N 'password' -f ~/.ssh/id_rsa
$ ssh-add ~/.ssh/id_rsa
And added ssh public key to git hub by following instruction;
https://docs.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account
If all gone well,
you should be able to get the following result;
$ ssh -T git#github.com
Hi user_name! You've successfully authenticated,...
One additional element that I realized is that typically .ssh folder is created in your root folder in Mac OS X /Users/. If you try to use ssh -vT git#github.com from another folder it will give you an error even if you had added the correct key.
You need to add the key again (ssh-add 'correct path to id_rsa') from the current folder to authenticate successfully (assuming that you have already uploaded the key to your profile in Git)
I had this issue after restoring a hard drive from a backup.
My problem:
I could check & see my remote (using git remote -v), but when I executed git push origin master, it returned : Permission denied (publickey). fatal: Could not read from remote repository.
I already had an SSH folder and SSH keys, and adding them via Terminal (ssh-add /path/to/my-ssh-folder/id_rsa) successfully added my identity, but I still couldn't push and still got the same error. Generating a new key was a bad idea for me, because it was tied to other very secure permissions on AWS.
It turned out the link between the key and my Github profile had broken.
Solution:
Re-adding the key to Github in Profile > Settings > SSH and GPG keys resolved the issue.
Also:
My account had 2-factor authentication set up. When this is the case, if Terminal requests credentials, use your username - but NOT your Github password. For 2-factor authentication, you need to use your authentication code (for me, this was generated by Authy on my phone, and I had to copy it into Terminal for the pw).
If you are using Linux or Windows open terminal or cmd in directory you want your keys in. Create a pair of private-public key
$ ssh-keygen -t ed25519 -C "your_email#example.com"
If you are using a legacy system that doesn't support the Ed25519 algorithm, use:
$ ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
Generating public/private ALGORITHM key pair.
Enter a file in which to save the key (/c/Users/YOU/.ssh/id_ALGORITHM):[Press enter any name you like your private public keys file to be]
Enter passphrase (empty for no passphrase): [Type a passphrase or enter for without it]
Enter same passphrase again: [Type a passphrase or enter for without it]
Now, in Linux
$ sudo cp <filename without .pub ending> ~/.ssh
In Windows simply copy the <filename without .pub ending> file in this C:\Users\your_username\.ssh directory
And then
$ ssh-add ~/.ssh/<filename without .pub ending>
It may work now!
After struggling for long I was finally able to resolve this issue on Windows, For me the User env variable GIT_SSH was set to point to
"C:\Program Files(x86)\WinScp\PuTTY\plink.exe"
which was installed along with WinScp. I changed the pointing to use default ssh.exe which comes with git-scm "C:\Program Files\Git\usr\bin\ssh.exe"
Steps for BitBucket:
if you dont want to generate new key, SKIP ssh-keygen
ssh-keygen -t rsa
Copy the public key to clipboard:
clip < ~/.ssh/id_rsa.pub
Login to Bit Bucket:
Go to View Profile -> Settings -> SSH Keys (In Security tab)
Click Add Key,
Paste the key in the box, add a descriptive title
Go back to Git Bash :
ssh-add -l
You should get :
2048 SHA256:5zabdekjjjaalajafjLIa3Gl/k832A /c/Users/username/.ssh/id_rsa (RSA)
Now: git pull should work
This worked for me also:
chmod 700 .ssh
chmod 600 .ssh/id_rsa
chmod 644 .ssh/id_rsa.pub
Then, type this: ssh-add ~/.ssh/id_rsa
Sometimes it could be useful to check ~/.ssh/config
it should look like this
Host github.com
IdentityFile ~/.ssh/id_rsa
id_rsa can be different if you linked a different key.

Error: Permission denied (publickey)

Following this post to fix the following error:
>> ssh -vT git#github.com
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/user/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/id_rsa type 1
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:10
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
Through the post made sure that I have a key and SSH is using it. I have even verified that the public key is attached to my github account. Not sure of the -1 in the last 3 lines? Saw all the related posts but no help.
debug1: identity file /Users/user/.ssh/id_rsa type 1
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
I was doing ssh -T git#github.com. I had to do ssh -T git#github.company's-github-account-name.com. All set now.
The most likely problem, it seems, is that the public key isn't actually correctly attached to your github account. Can you confirm that the output of
ssh-keygen -y -f /Users/user/.ssh/id_rsa
is exactly the same as what you put in Github, and that if you do
ssh-keygen -y -f /Users/user/.ssh/id_rsa > tmp
ssh-keygen -l -f tmp
..that the fingerprint shown matches exactly one of the fingerprints shown at https://github.com/settings/ssh ?
Edit: you confirmed. It looks like you've done everything right, then. I can't think of much more that could be going wrong. I suppose you might be getting the wrong remote host (the IP is right, but a malicious person or a misbehaving corporate firewall could still be sending the packets to the wrong place). You can check this by seeing what fingerprint you've stored in your known_hosts file:
ssh-keygen -F github.com > tmp
ssh-keygen -l -f tmp
The output should start with:
2048 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
If it does, then I suppose it might be a problem on the github side after all. Maybe they have some sort of delay in between receiving your public key and propagating it to the main ssh server. You probably ought to try the "contact a human" link at the bottom of the page you cited.
Extensive troubleshooting of this GIT issue “Git – Permission denied (publickey)” can be done with the below command:
ssh -vT git#github.com
Navigate to .ssh directory inside your home directory
cd ~/.ssh
Generate the public/private rsa key pair
ssh-keygen
Copy the SSH key to the clipboard using the below command
cat id_rsa.pub | clip
Navigate to your GIT repository in https://github.com/
Go to Account Settings –> SSH Keys
Click on Add SSH key and store the key
I agree with the answer posted by #Ava. Using ssh -T git#github."company's_github_account".com It worked for me. Many times, we do not realize that a simple fix exists for seemingly complex problems.

Resources