ssh (and git) authentication issues on external port/ip (local ip works fine) - linux

I am trying to set up a git repository on a server machine that is remote-accessible over the internet.
I have succeeded in getting git working over local/internal IP addresses. Within local LAN, I have private-key-based authentication working for SSH (password logins disabled), and I can clone, push, and pull successfully using Git and SSH, e.g.;
ssh USER#192.168.1.xxx
[-> accepts public key, gives me a remote console prompt as "USER", etc]
git clone git+ssh://USER#192.168.1.xxx//gitdir/project.git
[-> creates a local clone as desired, commits and push work, no problems seemingly]
However, I am now trying to access this machine via an external/internet IP in the same way, and I don't understand the behavior it's giving me.
I have enabled port forwarding on my router for port 22 to the server machine.
I have opened port 22 in software on "UFW" on the server machine.
As far as I can tell, I have no settings on my router, SSH configs, or UFW that would block any specific web address or otherwise cause problems on either my local machine or the server. The server should accept a connection from any external address accessing via port 22, and both my local machine and the server allow outgoing connections in general.
I am using Ubuntu 17.04 on the local machine, if that matters.
Both the server and the local machine are currently on the same LAN/connected to the same router.
I have DISABLED "ChallengeResponseAuthentication" and "PasswordAuthentication", and have ENABLED "PubkeyAuthentication" in my "sshd_config".
I have quadruple-checked that I was using the correct IP, and used copy-paste rather than manual typing. Unless I am truly missing something, I am attempting to connect to the correct machine.
For a direct SSH login, I get this (using the -v flag):
LOCALUSER#LOCALMACHINE:~$ ssh -v -i ~/.ssh/[PRIVATE_KEY] USER#[IP6_EXTERNAL_IP]
OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/[HOME]/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to [IP6_EXTERNAL_IP] [[IP6_EXTERNAL_IP]] port 22.
debug1: Connection established.
debug1: identity file /home/[HOME]/.ssh/[PRIVATE_KEY] type 4
debug1: key_load_public: No such file or directory
debug1: identity file /home/[HOME]/.ssh/[PRIVATE_KEY]-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Ubuntu-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Ubuntu-10
debug1: match: OpenSSH_7.4p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug1: Authenticating to [IP6_EXTERNAL_IP] as 'USER'
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:[SHA_HASH]
debug1: Host '[IP6_EXTERNAL_IP]' is known and matches the ECDSA host key.
debug1: Found key in /home/[HOME]/.ssh/known_hosts:4
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=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/[HOME]/.ssh/[PRIVATE_KEY]
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
USER#[IP6_EXTRNAL_IP]'s password:
...and no password I supply works. I don't know why the server is even asking for a password, I disabled password logins globally in "sshd_config", and I have triple-checked that there is no exception to that for this user, as well.
Git similarly asks for my remote user's password when I try to clone from the server via the external IP (because it's working through SSH of course), if I do the following to set it to use an external IP, instead of the original local IP:
git remote set-url origin ssh+git://USER#[REMOTE_IP]//gitdir/project.git
Any help understanding what I'm missing here would be much appreciated; thanks.

Figured it out:
I am unclear as to why, but my system does not like it when I try to access my server via an external public ip, from inside my own LAN. I assume this is because of some kind of packet confusion as the local machine and the server machine share the same public ip via the router (confirmation on this would be appreciated).
When I tried to connect from another network, things worked correctly and as expected. I am asked for my public key and immediately rejected with no password prompt if I don't supply the right one, and both SSH and git via SSH seem to work as desired over the internet after I change my repo source to use the public ip. Any further details were covered by editing ~/.ssh/config to set key identities and hosts.
Marking as solved. Thank you.

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.

How to execute SCP in bash script using public key

I humbly apologize, but I looked everywhere in the net and I still couldn't do this. This is the best guide i've found so far. I've also used this as guide as well. And still nothing works.
I needed to execute a script that automatically sends a local file to a remote machine. Both local and remote machines are Linux.
EDIT: script should NOT prompt for password to user - hence why I should use public keys.
What I've done so far:
EDIT: executed eval `ssh-agent`, and then ssh-add, and then ssh-copy-id
executed ssh-keygen on local machine, to produce id_rsa and id_rsa.pub at ~/.ssh folder
Used NO passphrase in ssh-keygen
Sent id_rsa.pub to remote machine into its ~/.ssh folder
Renamed id_rsa.pub in remote machine into authorized_keys (since it didn't exist originally)
Script file (in local machine)
#!/bin/bash
scp -i ~/.ssh/id_rsa -o BatchMode=yes -v file.txt meuser#remotemachine:/home/meuser
Output of verbose mode of SCP:
./scp_example.sh
Executing: program /usr/bin/ssh host webui01, user meuser2, command scp -v -t /home/meuser
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 remotemachine [###.###.###.###] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 504/505
debug1: identity file /home/meuser/.ssh/id_rsa type 1
debug1: loaded 1 keys
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_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 'remotemachine' is known and matches the RSA host key.
debug1: Found key in /home/meuser/.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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Next authentication method: publickey
debug1: Offering public key: /home/meuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
lost connection
Hopefully someone can shed light into this.
Thanks and best regards.
Your offered key is rejected. Have a look into the server log for the reason, make sure that the home directory, .ssh and .ssh/authorized_keyus is owned by the correct user and not writable by anyone else (which is most common mistake).

SSH Tunneling to docker container

I'm trying to establish an ssh tunnel to my docker container running on my remote Virtual Server.
Basically I followed the instruction here on this post where you also find more details about what I'm trying to achieve:
Stackoverflow's linked post: How to SSH into Docker?
Actually I set up everything correctly but my connection is terminated every time with the following message:
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is <rsa-key>.
Please contact your system administrator.
Add correct host key in /home/rico/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/rico/.ssh/known_hosts:31 remove with: ssh-keygen -f "/home/rico/.ssh/known_hosts" -R [<server-ip>]:33
RSA host key for [<server-ip>]:33 has changed and you have requested strict checking.
Host key verification failed.
I attached a screenshot here:
https://s18.postimg.org/ivnnxj7a1/connection_closed.png
My command line is:
ssh -p 33 root#<server-ip>
where '33' is the ssh port of the docker container.
What I have to do in order to have the connection accepted by my Virtual Server?
[UPDATE]
run the command adding also -v flag and post the output:
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: Connecting to <server-ip> [<server-ip>] port 44.
debug1: Connection established.
debug1: identity file /home/rico/.ssh/id_rsa type 1
debug1: identity file /home/rico/.ssh/id_rsa-cert type -1
debug1: identity file /home/rico/.ssh/id_dsa type -1
debug1: identity file /home/rico/.ssh/id_dsa-cert type -1
debug1: identity file /home/rico/.ssh/id_ecdsa type -1
debug1: identity file /home/rico/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/rico/.ssh/id_ed25519 type -1
debug1: identity file /home/rico/.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.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm#openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA <server-mac-address>
debug1: Host '[<server-ip>]:44' is known and matches the ECDSA host key.
debug1: Found key in /home/rico/.ssh/known_hosts:32
debug1: ssh_ecdsa_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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/rico/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: <my-email>#gmail.com
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: <my-email>#gmail.com
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/rico/.ssh/id_dsa
debug1: Trying private key: /home/rico/.ssh/id_ecdsa
debug1: Trying private key: /home/rico/.ssh/id_ed25519
debug1: Next authentication method: password
root#<server-ip>'s password:
Even if I set up a new root password it doesn't work
You might want to reconsider using SSH. As the comments in your linked post point out, this goes against Docker's concept. Furthermore, running addtional SSH server(s) increases your potential attack surface.
There are two alternatives for getting access to your containers:
SSH into your VM and use docker exec, e.g. docker exec -it <yourcontainer> bash
Connect your local client to the docker daemon running inside your VM. This is an advanced approach, but Docker has a good documentation how to do it securely. In a nuthshell: You configure the daemon on your VM to listen to a TCP socket, e.g. dockerd -H=0.0.0.0:2376. Then you point your local client to the corresponding IP, docker -H=$HOST:2376 version. Everyting must be secured by using signed TLS certificates.
I hope this helps!
You can bypass that issue by adding this to your ssh command:
-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
To solve the authentication problem, follow this guide to create an authorized_keys file and finally add it to your image using the Dockerfile:
ADD authorized_keys /home/docker/.ssh/authorized_keys
NOTE: as #stepf comments ssh is not intended way to access docker containers.

EC2 keypair works in one instance but fails on other - Permission denied (publickey)

I have read many posts on this subject but none helped me solve my issue.
I have a machine amazon ec2 which I connect using this SSH command:
ssh -i /Library/AWS/glrpopulis.pem ec2-user#54.225.154.23
I've never had problems with this command until now. It just stopped working, the following message is displayed: Permission denied (publickey). out of nowhere!
I really can't understand why suddenly the same command I use almost everyday is failing to work. Probably I've changed something I wasn't supposed to, but I'm having a really hard time figuring out what.
I was creating a service for a web application (atlassian bamboo) when that happened the first time, but I'm not sure if this relates to the error.
I have reboot the machine a couple of times and tried over and over again, with no success.
The complete output with the -v option is displayed bellow:
mac-pipo:~ felipereis$ ssh -v -i /Library/AWS/glrpopulis.pem ec2-user#54.225.154.23
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 54.225.154.23 [54.225.154.23] port 22.
debug1: Connection established.
debug1: identity file /Users/felipereis/.ssh/id_rsa type 1
debug1: identity file /Users/felipereis/.ssh/id_rsa-cert type -1
debug1: identity file /Users/felipereis/.ssh/id_dsa type -1
debug1: identity file /Users/felipereis/.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 OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com 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: Server host key: RSA 19:ef:f1:2b:56:dd:86:ec:42:65:ff:1d:6b:64:0f:f3
debug1: Host '54.225.154.23' is known and matches the RSA host key.
debug1: Found key in /Users/felipereis/.ssh/known_hosts:12
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/felipereis/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /Library/AWS/glrpopulis.pem
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/felipereis/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
UPDATE:
* I have just tested and I'm able to use the same key (glrpopulis.pem) to connect to a different ec2 instance, so maybe is something going on the first machine
Sounds like the keys under ~/.ssh/authorized_keys got messed up or the file got deleted.
Try the following:
Stop your EC2 instance
Detach your root Volume (/dev/sda1) -- Assuming this is Volume A
Spin up a new EC2 instance of the same type and same credentials.
Attach Volume A to that new instance as /dev/sdf
ssh connect to his new instance.
mkdir -p /mnt/xvdf
mount /dev/xvdf /mnt/xvdf
cp ~/.ssh to /mnt/xvdf/home/ec2-user/.
chmod 700 /mnt/xvdf/home/ec2-user
chmod 600 /mnt/xvdf/home/ec2-user/authorized_keys
Shutdown new instance
Detach Volume A on new instance
Reattach Volume A on /dev/sda1 on original instance.
Start original instance.
You should be able to login now.
Depending on your AMI, the public key might be being added to the authorized_keys file of a different user to ec2-user.
To find out, you can view the boot log for the instance in the EC2 console, and it should output the username that cloud-init is using as the "default user". Mine has a line like this:
ci-info: +++++++++++++++++++++Authorized keys from /home/ec2-user/.ssh/authorized_keys for user ec2-user++++++++++++++++++++++
You can also try logging in as root as that will sometimes give an error like 'Please login as the user "ec2-user" rather than the user "root".'
This happened to me, and it was because I had updated my version of cloud-init, which is what adds the public key to authorized_keys. The default config file (/etc/cloud/cloud.cfg) was replaced, causing the default user to change from "ec2-user" to "cloud-user".
I fixed this issue by changing the system_info section of the new /etc/cloud/cloud.cfg to this:
...
system_info:
...
default_user:
name: ec2-user
sudo: ALL=(ALL) NOPASSWD:ALL
...
You can then create a new AMI from that instance, and it should setup ec2-user correctly again.

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