Cannot push Vue CLI app to github.io after build - Permission denied (publickey) - linux

I've troubleshooted https://help.github.com/en/github/authenticating-to-github/error-permission-denied-publickey
Should the sudo command be used with Git?
I'm not using sudo together with my git commands
Check that you are connecting to the correct server
Running $ ssh -vT git#github.com makes the connection on port 22 and returns You've successfully authenticated
Always use the "git" user
I've used the set-url command to change the repo to use the SSH protocol and ssh -T git#github.com returns:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to github.com [140.82.118.4] port 22.
debug1: Connection established.
debug1: identity file /home/warwick/.ssh/id_rsa type 0
debug1: identity file /home/warwick/.ssh/id_rsa-cert type -1
debug1: identity file /home/warwick/.ssh/id_dsa type -1
debug1: identity file /home/warwick/.ssh/id_dsa-cert type -1
debug1: identity file /home/warwick/.ssh/id_ecdsa type -1
debug1: identity file /home/warwick/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/warwick/.ssh/id_ed25519 type -1
debug1: identity file /home/warwick/.ssh/id_ed25519-cert type -1
debug1: identity file /home/warwick/.ssh/id_xmss type -1
debug1: identity file /home/warwick/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
debug1: Remote protocol version 2.0, remote software version babeld-17f81433
debug1: no match: babeld-17f81433
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
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: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/warwick/.ssh/known_hosts:3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/warwick/.ssh/id_rsa RSA SHA256:XUyMmE8J489MaD9Ix/1xJdilSU4aH/F27hdhQubMQL4
debug1: Will attempt key: /home/warwick/.ssh/id_dsa
debug1: Will attempt key: /home/warwick/.ssh/id_ecdsa
debug1: Will attempt key: /home/warwick/.ssh/id_ed25519
debug1: Will attempt key: /home/warwick/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-dss>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/warwick/.ssh/id_rsa RSA SHA256:XUyMmE8J489MaD9Ix/1xJdilSU4aH/F27hdhQubMQL4
debug1: Server accepts key: /home/warwick/.ssh/id_rsa RSA SHA256:XUyMmE8J489MaD9Ix/1xJdilSU4aH/F27hdhQubMQL4
Enter passphrase for key '/home/warwick/.ssh/id_rsa':
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([140.82.118.4]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_ZA.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
Hi WNortier! You've successfully authenticated, but GitHub does not provide shell access.
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3452, received 2484 bytes, in 0.5 seconds
Bytes per second: sent 6930.1, received 4986.7
debug1: Exit status 1
Make sure you have a key that is being used
I've created a new public/private key combination as per https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account
Identity added: /home/warwick/.ssh/id_rsa (myemail#gmail.com)
There is a problem here:
Starting eval "$(ssh-agent -s)" in the terminal and running ssh-add -l is returning The agent has no identities. even though I just added it?
Pushing changes made to the project src files to github does not prompt me for my password and when I check my github settings I see the key is used. So the key appears to be working
I run into Permission denied (publickey) every time I try to run build and push. I created a .deploy.sh file as per this guide on the Vue documentation and uncommented and added my username on the line intended for a github.io push https://cli.vuejs.org/guide/deployment.html#github-pages
set -e
npm run build
cd dist
git init
git add -A
git commit -m "deploy"
git push -f git#github.com:wnortier/wnortier.github.io.git master
cd -
but when I run it with sh .deploy.sh it returns
DONE Compiled successfully in 2175ms 15:40:48
File Size Gzipped
dist/js/chunk-vendors.c4d3d4de.js 114.27 KiB 40.31 KiB
dist/js/app.8b5fd9c9.js 6.99 KiB 2.90 KiB
dist/css/app.35dcd38a.css 0.27 KiB 0.21 KiB
Images and other types of assets omitted.
DONE Build complete. The dist directory is ready to be deployed.
INFO Check out deployment instructions at https://cli.vuejs.org/guide/deployment.html
Initialized empty Git repository in /home/warwick/Projects/wnortier.github.io/dist/.git/
[master (root-commit) 74551eb] deploy
8 files changed, 14 insertions(+)
create mode 100644 css/app.35dcd38a.css
create mode 100644 favicon.ico
create mode 100644 img/logo.82b9c7a5.png
create mode 100644 index.html
create mode 100644 js/app.8b5fd9c9.js
create mode 100644 js/app.8b5fd9c9.js.map
create mode 100644 js/chunk-vendors.c4d3d4de.js
create mode 100644 js/chunk-vendors.c4d3d4de.js.map
git#github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
git config is as follows:
user.email=warwick.nortier#gmail.com
user.name=warwick
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/WNortier/wnortier.github.io.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
user.name=warwick
user.email=warwick.nortier#gmail.com
Please could anyone assist me?

It turns out my ssh key was setup correctly all along.
I've managed to solve the problem by running the following command: sudo chown -R $USERNAME /home/<myusername>
It allowed me to run the deploy script without [sudo].

Set the GIT_SSH_COMMAND in your session (as you, not root)
export GIT_SSH_COMMAND='ssh -Tv'
And run your script.
You will see the same kind of debug log you have in your question.
If not, that means the script is not running with your profile environment settings, which could explain why it works in command-line when done manually, and not through said script.

Related

Can't clone on windows but can clone on linux from Gitlab server

I am trying to clone a repository from a remote Gitlab server over SSH. I am using Gitlab CE version 9.3.9 755bb71 and TortoiseGIT version 2.5.0 and git (for windows) version 2.14.0
SSH Keys are installed correctly as I have tested the authentication using
ssh -vT git#192.168.100.100 -i /path/to/.ssh/key
I get the following message for authentication success using the above key
OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.100.100 [192.168.100.100] port 22.
debug1: Connection established.
debug1: identity file /path/to/.ssh/key type 1
debug1: key_load_public: No such file or directory
debug1: identity file /path/to/.ssh/key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to 192.168.100.100:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256#libssh.org
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:fEztD+bNxKRs24poXJMlP0GBAP6Q1dZT80OhQAtDQJE
debug1: Host '192.168.100.100' is known and matches the ECDSA host key.
debug1: Found key in /path/to/.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_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /path/to/.ssh/key
debug1: Server accepts key: pkalg ssh-rsa blen 535
Enter passphrase for key '/path/to/.ssh/key':
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.100.100 ([192.168.100.100]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
Welcome to GitLab, John Doe!
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow#openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3476, received 3264 bytes, in 2.2 seconds
Bytes per second: sent 1574.0, received 1478.0
debug1: Exit status 0
When I use TortoiseGit on windows to clone a repository I get the following error on the client
Cloning into 'C:\path\folder'...
GitLab: Disallowed command
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
On the gitlab server, in the gitlab-shell.log I get the following warning message
WARN -- : gitlab-shell: Attempt to execute disallowed command <git upload-pack '/path/to/repo.git'> by user with key key-1.
But when I try git clone from another linux machine with a different SSH key it's successfull and I get the following info message in gitlab-shell.logon the gitlab server
INFO -- : gitlab-shell: executing git command <gitaly-upload-pack {"repository":{"path":"/very/long/path/to/repo.git"},"gl_id":"key-2"}> for user with key key-2.
I have spent more than 10 hours trying to debug everything and I am not sure what's the difference or where exactly is the problem. I have also tried adding the following in my local .gitconfig file for TortoiseGit but that doesn't change anything.
[remote "origin"]
uploadpack = git-upload-pack
Finally, cloning the same repository over HTTPS works fine, without any problem using a username / password.
Note: I just upgrade to Git 2.14.0 for Windows... and none of the ssh url are working:
> git ls-remote
GitLab: Disallowed command
fatal: Could not read from remote repository.
(with origin being an ssh url)
Another side effect: git-for-windows/git issue 1258
fatal: protocol error: bad line length character: Not
It looks as if BitBucket looks at argv[0] (typically git-upload-pack, with the regression git) to determine whether it is a permitted command.
So I think it is by design that git is rejected while git-upload-pack is not.
Same kind on error on GitLab: gitlab-ce issue 36028.
The pending merge request explicitly restore git-xxx when it detects a git xxx command.
See gitlab_shell.rb#parse_cmd(args)
def parse_cmd(args)
# Handle Git for Windows 2.14 using "git upload-pack" instead of git-upload-pack
if args.length == 3 && args.first == 'git'
#command = "git-#{args[1]}"
args = [#command, args.last]
else
#command = args.first
end
At the Git for Windows side, a fix is in progress: see commit 0f33428
Revert "git_connect: prefer Git's builtins over dashed form"
It would appear that this change (which was intended to fix tests
interacting with local repositories when git-upload-pack was not in the
PATH) regresses on SSH access.
A Git for Windows 2.14.0(2) is in the work and was just released (2017-08-07T11:05:34Z UTC) 30 minutes ago at the time of this edit.
Original answer
If key1 is the same as your /path/to/.ssh/key and does identify John Doe, that should mean John Doe does not have access to that repo (as in here).
Check that key2 is associated with a different user.
If both keys reference the same user, then it is more a local configuration issue (as in this answer).
Check also that your TortoiseGit does use the same key as in your test:
set "GIT_COMMAND_SSH=ssh -v"
# launch TortoiseGit from that CMD session
You will then see what TortoiseGit is using when cloning the repo with an ssh url. You might need to define an .ssh/config file.
Both Bitbucket Server and Gogs are seeing similar problems.
It appears that something changed in git 2.14.0 (possibly only on Windows) that requires either an update to the products or a fix to git.

Cant ssh to a cygwin server

Its getting stuck as you can see.
Below is what verbose connection shows.
[ftpuser#eu9sacovn48 ~]$ ssh -v gmrsops#uscasaciccx82
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to uscasaciccx82 [113.130.154.54] port 22.
debug1: Connection established.
debug1: identity file /cpmapps/ftpuser/.ssh/identity type -1
debug1: identity file /cpmapps/ftpuser/.ssh/id_rsa type 1
debug1: identity file /cpmapps/ftpuser/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 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-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 'uscasaciccx82' is known and matches the RSA host key.
debug1: Found key in /cpmapps/ftpuser/.ssh/known_hosts:7
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: /cpmapps/ftpuser/.ssh/identity
debug1: Offering public key: /cpmapps/ftpuser/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
I tried connecting to the server without a key but its still not working.
[ftpuser#eu9sacovn48 ~]$ ssh -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no gmrsops#USCASACICCX82
gmrsops#uscasaciccx82's password:
I can login to cygwin just fine while on local server.
Here's what fixed the issue for me.
Run sshd in debug mode using below command
/usr/sbin/sshd.exe -D -dd
This gave me the below warnings
$ /usr/sbin/sshd.exe -D -dd debug2: load_server_config: filename
/etc/sshd_config debug2: load_server_config: done config len = 285
debug2: parse_server_config: config /etc/sshd_config len 285 debug1:
sshd version OpenSSH_7.5, OpenSSL 1.0.2k 26 Jan 2017
########################################################### #
WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0770 for '/etc/ssh_host_rsa_key' are too open. It is
required that your private key files are NOT accessible by others.
This private key will be ignored. key_load_private: bad permissions
Could not load host key: /etc/ssh_host_rsa_key
########################################################### #
WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0770 for '/etc/ssh_host_dsa_key' are too open. It is
required that your private key files are NOT accessible by others.
This private key will be ignored. key_load_private: bad permissions
Could not load host key: /etc/ssh_host_dsa_key
########################################################### #
WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0770 for '/etc/ssh_host_ecdsa_key' are too open. It is
required that your private key files are NOT accessible by others.
This private key will be ignored. key_load_private: bad permissions
Could not load host key: /etc/ssh_host_ecdsa_key
########################################################### #
WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0770 for '/etc/ssh_host_ed25519_key' are too open. It is
required that your private key files are NOT accessible by others.
This private key will be ignored. key_load_private: bad permissions
Could not load host key: /etc/ssh_host_ed25519_key sshd: no hostkeys
available -- exiting.
So I changed the permissions of the above files to 600
$ chmod 0600 /etc/ssh_host*
Then the debug command again.
SHA256:4yqAb/GiMfMJPmIXfKz+Zw4fWOCVN7E6vUDHEtokdHk /var/empty must be owned by root and not group or world-writable.
Then change the permission of this folder to 600.
$ chmod 600 /var/empty
This fixed the issue.
Since you're trying to connect to a Windows machine, you may not have an SSH server installed/enabled. Check to make sure SSH is installed and properly configured in your cygwin environment. It is part of the OpenSSH package. More info here.
Edit: See this post where someone had the exact same error.

Github Permission denied (publickey) SSH keys in wrong directory?

I've recently installed this stack on AWS EC2:
https://aws.amazon.com/marketplace/pp/B00NO1HJ56/ref=srh_res_product_title?ie=UTF8&sr=0-2&qid=1461119036279
The instance's system log says that the SSH keys were installed here:
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
I have added the public key to my Github account and the fingerprints match.
When cloning a repo I get:
Permission denied (publickey).
From the Github help section https://help.github.com/articles/error-permission-denied-publickey
I run: ssh -vT git#github.com and get:
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to github.com [192.30.252.122] port 22.
debug1: Connection established.
debug1: identity file /home/bitnami/.ssh/id_rsa type -1
debug1: identity file /home/bitnami/.ssh/id_rsa-cert type -1
debug1: identity file /home/bitnami/.ssh/id_dsa type -1
debug1: identity file /home/bitnami/.ssh/id_dsa-cert type -1
debug1: identity file /home/bitnami/.ssh/id_ecdsa type -1
debug1: identity file /home/bitnami/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/bitnami/.ssh/id_ed25519 type -1
debug1: identity file /home/bitnami/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6
debug1: Remote protocol version 2.0, remote software version libssh-0.7.0
debug1: no match: libssh-0.7.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_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_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 /home/bitnami/.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: 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: /home/bitnami/.ssh/id_rsa
debug1: Trying private key: /home/bitnami/.ssh/id_dsa
debug1: Trying private key: /home/bitnami/.ssh/id_ecdsa
debug1: Trying private key: /home/bitnami/.ssh/id_ed25519
debug1: No more authentication methods to try.
I seems the ssh agent is searching /home/bitnami/.ssh/ but the keys are located in /etc/ssh
This is the contents of /home/bitnami/.ssh
authorized_keys
known_hosts
And this is the contents of /etc/ssh
moduli
ssh_host_dsa_key
ssh_host_ecdsa_key.pub
ssh_host_rsa_key
ssh_config
ssh_host_dsa_key.pub
ssh_host_ed25519_key
ssh_host_rsa_key.pub
sshd_config
ssh_host_ecdsa_key
ssh_host_ed25519_key.pub
ssh_import_id
If I check what keys are added to the ssh agent I get:
$ ssh-add -l I get:
The agent has no identities.
Is this simply a matter of adding my public key in /etc/ssh/ to the ssh agent by using ssh-add, so it knows where to look?
I don't understand why the keys are were not installed in /etc/hosts rather than the home directory.
The solution is simply to ignore the keys in /etc/ssh. These keys are used by AWS to access the instance and belongs to the system rather than a user.
So I just generated new keys for the bitnami user and those keys are now correctly sitting in /home/.ssh/
I can now pull my repo from Github.

SSH Login fails while executing a backup bash script to commit to Stash

(I am very new to git and version control. ) I have several bash scripts that perform nightly backups- I also have a cronjob already set up,. Executing a single script at a time also requires the password even though I have tried my best to enable the scripts to perform ssh authentication but I keep getting prompted for my stash password when they execute(I have looked at several online resources but I think I keep going around in circles- not reaching anywhere close to the solution), if I could get my scripts to execute via ssh authentication then I can go ahead and run the cron job successfully.
I have already created the public - private key pair and my public key has been added to the Stash Project.
A ssh -v 'username'#'server' gives the following output :
`OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to dbstore1 [10.4.2.3] port 22.
debug1: Connection established.
debug1: identity file /home/<myusername>/.ssh/identity type -1
debug1: identity file /home/<myusername>/.ssh/id_rsa type 1
debug1: identity file /home/<myusername>/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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 'dbstore1' is known and matches the RSA host key.
debug1: Found key in /home/<myusername>/.ssh/known_hosts:2
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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/<myusername>/.ssh/identity
debug1: Offering public key: /home/<myusername>/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
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
`
So looking at the above result- the authentication using the SSH public key is successful for my user account, right?
Now, the problem comes in when i execute the schema backup script - sudo ./script.sh
It keeps asking me for my (stash) password when it is about to commit/push. Also, I noticed that when I supply the password and there is a successful commit on Stash - the author is displayed as 'root'.
So my SSH public key is set up for MY user account but the commits are made from root - Could this be a cause of why ssh login doesn't work for me ?

Setting up git on Linux server

I am trying to set up a git repo on a server running Linux RedHat.
I follow the instructions on Github's help page. I reach the step where the instructions tell me to ssh into git#github.com.
this gives me the following error -
$ ssh -T git#github.com
Permission denied (publickey).
So then I did $ ssh -vT git#github.com and get this -
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /home/min/a/foo/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [some IP] port 22.
debug1: Connection established.
debug1: identity file /home/shay/a/foo/.ssh/id_rsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1+github2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1+github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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 /home/min/a/foo/.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: 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: /home/shay/a/foo/.ssh/id_rsa
debug1: No more authentication methods to try.
Permission denied (publickey).
Here's where I currently am -
$ pwd
/home/min/a/foo/.ssh
I don't understand what's going wrong? Also, if I try to add this path by doing ssh-add, it says "Could not open a connection to your authentication agent".
It appears that you either have not uploaded a key to github, or you have uploaded a key that does not match your default key for the current user.
Check that your local key is on github:
Get your key's fingerprint: ssh-keygen -lf ~/.ssh/id_rsa.pub
Check this against the list of allowed keys on github: https://github.com/settings/ssh
Alternatively, check that your key is enabled on github. A little while ago, a there was an security issue related to ssh keys on github. All ssh keys were disabled in order to force users to review their list of allowed keys. If you've not used github recently, yours could still be disabled.
Just in case someone is interested or has a similar issue and checks this post, the solution is to cd out of the .ssh dir and ssh into github. Provided everything else is followed exactly as on github's help page, this will solve the problem.

Resources