i'm use centos 5.9.
after installing gitlab by this link ssh not working.
before install gitlab ssh correctly working.
i'm using this server localy and other services such as elastix and apache,mysql installed on server.
appeare this error :
OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.88.23 [192.168.88.23] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x00000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.88.23:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01#openssh.com,ssh-rsa-cert-v00#openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01#openssh.com,ecdsa-sha2-nistp384-cert-v01#openssh.com,ecdsa-sha2-nistp521-cert-v01#openssh.com,ssh-ed25519-cert-v01#openssh.com,ssh-dss-cert-v01#openssh.com,ssh-dss-cert-v00#openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 3111/6144
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:7J6JOe94H9PedNKlx6yG/wMy6ZYC8iB74WdOVGDgY7A
debug1: Host '192.168.88.23' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 3102/6144
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil)),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).
Setting 700 to .ssh and 600 to authorized_keys solved the issue.
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
I had the same issue while using vagrant. So from my Mac I was trying to ssh to a vagrant box (CentOS 7)
Solved it by amending the /etc/ssh/sshd_config PasswordAuthentication yes then re-started the service using sudo systemctl restart sshd
Hope this helps.
Setting PasswordAuthentication to yes, is not the best way to go ,
is not as secure as using private and public keys for authentication !
First make sure that that you have the fallowing permissions set, on the server side.
First check your home dir (SERVER SIDE)
[vini#random ~]$ ls -ld ~
drwx------. 3 vini vini 127 Nov 23 15:29 /home/vini
if it is not like this, run
chmod 0700 /home/your_home
Now check .ssh folder
[vini#random ~]$ ls -ld /home/vini/.ssh/
drwx------. 2 vini vini 29 Nov 23 15:28 /home/vini/.ssh/
if it is not looking like this, run
chmod 0700 /home/your_home/.ssh
now make sure that authorized_keys looks like this
[vini#venon ~]$ ls -ld /home/vini/.ssh/authorized_keys
-rw-------. 1 vini vini 393 Nov 23 15:28 /home/vini/.ssh/authorized_keys
or just run
chmod 0600 /home/your_home/.ssh/authorized_keys
After that go to /etc/ssh/sshd_config
For best security set
PermitRootLogin no
PubkeyAuthentication yes
keep as yes for testing purposes
PasswordAuthentication yes
Make sure that
ChallengeResponseAuthentication no
Comment those lines for GSSAPI
# #GSSAPIAuthentication yes
# #GSSAPICleanupCredentials no
Make sure that is set to UsePAM yes
UsePAM yes
now restart sshd service
systemctl restart sshd
on the client side
cd /home/your_home/.ssh
generate new keys; setting a password is optional but is a good idea
ssh-keygen -t rsa -b 2048
copy pub key to your server
ssh-copy-id -i id_rsa.pub user_name#server_ip
start ssh agent
eval $(ssh-agent)
ssh-add /home/user/.ssh/your_private_key
now your are good to go !
ssh user_name#server_ip
if everything works just fine
make a backup of your private key and then deny PasswordAuthentication
PasswordAuthentication no
Restart you server
now anyone trying to ssh into your server, without your keys should get
vini#random: Permission denied (publickey).
keep script kids away from your business, and good luck
As everybody else has already said you need to edit /etc/ssh/sshd_config and change PasswordAuthentication no to PasswordAuthentication yes
I ran into this problem setting up a Vagrant box - so therefore it makes sense to script this and do it automatically in a shell provisioner:
sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config;
sudo systemctl restart sshd;
The isssue is the username for most publickey errors on centos instances on AWS.
For Permission denied (publickey,gssapi-keyex,gssapi-with-mic):
its pretty simple. Just change your username from centos to ec2-user and the issue is solved.
Thank me later :)
please make sure following changes should be uncommented, which I did and got succeed in centos7
vi /etc/ssh/sshd_config
1.PubkeyAuthentication yes
2.PasswordAuthentication yes
3.GSSAPIKeyExchange no
4.GSSAPICleanupCredentials no
systemctl restart sshd
ssh-keygen
chmod 777 /root/.ssh/id_rsa.pub
ssh-copy-id -i /root/.ssh/id_rsa.pub user#ipaddress
thank you all and good luck
I had the same problem. In my case, macOS doesn't load my SSH keys, but I fix it with:
ssh-add <SSH private key>
ssh-add <SSH public key>
I couldn't connect to a Droplet on DigitalOcean, but the subsequent commands work for me.
You can go to the forum here.
According to the line debug1: Authentications that can continue: publickey,gssapi-with-mic , ssh password authentication is disabled and apparently you are not using public key authentication.
Login to your server using console and open /etc/ssh/sshd_config file with an editor with root user and look for line PasswordAuthentication then set it's value to yes and finally restart sshd service.
Tried a lot of things, it did not help.
It get access in a simple way:
eval $(ssh-agent) > /dev/null
killall ssh-agent
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa
Note that at the end of the ssh-add -L output must be not a path to the key, but your email.
In Centos 7
Error : publickey,gssapi-keyex,gssapi-with-mic
Ans : Root access to vi /etc/ssh/sshd_config and change the PasswordAuthentication ( no ) to yes.
2 . Restart the sshd services
root> systemctl restart sshd.service
Logon into local id via putty without key.
As a few others have mentioned, make sure you are using the right private key when you ssh into your server. I had multiple ssh private keys set up in my directory, so it was defaulting to a different key. To ssh with the correct key call it out in your CLI call ssh centos#IP-ADDRESS -i YOUR-PATH-TO-KEY, in my case the path was ~/.ssh/id_rsa
Nobody has mention this in. above answers so i am mentioning it.
This error can also come if you're in the wrong folder or path of your pem file is not correct. I was having similar issue and found that my pem file was not there from where i am executing the ssh command
cd KeyPair
ssh -i Keypair.pem ec2-user#244.255.255.255
I know this is an old question, but thought I'd add my fix in the pot.
I was getting the same error trying to connect to Amazon Linux from Ubuntu. The solution was to simply change this:
ssh-add -c <key_location>.pem
to this:
ssh-add "<key_location>.pem"
... pretty simple change there got me in.
fixed by setting GSSAPIAuthentication to no in /etc/ssh/sshd_config
Maybe you should assign the public key to the authorized_keys, the simple way to do this is using ssh-copy-id -i your-pub-key-file user#dest.
And I think this will clearify the cause of posted problem, actualy this is bug of pssh itself (contains inside "askpass-client.py"). It is pssh's lib file. And there is documented issue for -A case:
https://code.google.com/archive/p/parallel-ssh/issues/80
There are two possible resolutions to use version of pssh containing this bug in case you forced to use passphrase for private key access:
Correct your "askpass-client.py" as described in link listed before in my post.
Using your favorite pass keeper.
Thnks for attention, hope it helps!
I try
rm ~/.ssh/id_rsa.pub
then it work!
First a password login has to be established to remote machine
Firstly make a password login
you have to enable a password login by enabling the property ie) PasswordAuthentication yes in sshd_config file.Then restart the sshd service and copy the pub key to remote server (aws ec2 in my case), key will be copied without any error
Without password login works if and only if password login is made first
copy the pub key contents to authorised keys, cat xxx.pub >> ~/.ssh/authorized_keys
This can happen if you are missing the correct id_rsa key set up in authorized_keys for an AWS instance.
Exact error I got (this article came up when I googled the error):
ec2-user#X.X.X.X: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Note: If you have many keys, you have to either specify the key on the ssh command line or else add it to you ssh-agent keys (see ssh-add -l). Only the first 6 keys from ssh-agent may work - the default sshd MaxAuthTries config value is 6.
Hope, this will help someone. Problem I encountered is, I was completely using wrong key with the IP. Make sure you are using the right key for the right IP
For me it is a completely mistake, someone copy paste the key into the same row with another key, after separating them into two different lines then it works again, so check if your authorized_key file has similar mistakes !
I had same issue Permission denied (publickey, gssapi-keyex, gssapi-with-mic) earlier.
I had to go /etc/ssh/sshd_config to add the user user into AllowUsers section, then restarted sshd service.
Let me share with you how I did it and I am sure you will find good answer here.
Make sure the following
Step 1. You have Public DNS (IPv4) from aws E.g ec2-IPV4.us-east-2.compute.amazonaws.com
Step 2. You remember where your your_secret_key_is.pem E.g its better to keep it far from root of the known folders like Downloads, Desktop or Documents
Step 3 Open terminal and add the command sudo ssh -v -i path-to-key.pem ec2-user#host
ec2-user is important because it for some linux server it is the username
sudo it needs permission to execute
host It is Amazon Public DNS (IPv4) (copy step 1)
Find more info here
Permission denied (publickey)
seems like an issue generated by the ssh client rather than the ssh server in my case.
Here's what caused my problem and how I solved.
The problem source is I used sudo to generate the keys like this:
sudo ssh-keygen -t ed25519 -f ~/.ssh/serverA_ed25519_key
This automatically set the owner of these key files to root only, so my current user doesn't have permission to read the keys.
Now solution #1 is change the file ownership to your current user. This's what I did.
sudo chown CURRENT_USER ~/.ssh/serverA_ed25519_key
Solution #2 would be just run ssh client with sudo when you try to connect to the ssh server.
Finally, a trick to find the source of problem with ssh client.
ssh -v -o IdentitiesOnly=yes -i ~/.ssh/serverA_ed25519_key me#serverA
This let me focus on the problem by:
show verbose info by -v flag.
the -o option and -i ~/.ssh/serverA_ed25519_key force ssh client to try with this key ONLY, not all the keys you have.
I also have this error info : Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Using cmd: ssh -i "~/.ssh/old.pem" user#ip cause the error.
Problem is old.pem has been deprecated, after changing to newest pem file,
the error disappears.
In my case, I was using wrong username. Fixed that and the issue got resolved.
The issue is simple, the owner for the key should be one in case if windows ( Just remove other users and keep only one or deny other users permissions) for linux/Mac just do a chmod 400 as this will only give read permission only to the user and no permission to groups or public.
I run into this strange error whiles connecting from my Mac(host) to a CentOS(7.9) guest. I had to explicitly passed the key file to the ssh client ssh root#ip -i private_key_file before connection was successful.
Earlier on, I had enabled the following after the usual key generation with ssh-keygen and copying with ssh-copy-id
PermitRootLogin yes #Logging in with root, it was set by default
PasswordAuthentication no
I decided against using the default name provided by ssh-keygen though the generated file was saved at the same location as the default.
I left the other default values untouched.
Don't forget to restart sshd on the remote machine.
I got Sucess !!
I've copied my ssh_keys from my other machine and tryed to log to my AWS EC2, but it failed:
sign_and_send_pubkey: signing failed for RSA "/home/xxxx/.ssh/my_rsa" from agent: agent refused operation
ec2-user#bla-blah-blah.zzzzz.amazonaws.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
The solution was:
cd $HOME/.ssh
ls -l
-r-x------ 1 xxxx xxxx 1766 May 4 09:13 id_rsa
-r-x------ 1 xxxx xxxx 405 May 4 09:13 id_rsa.pub
-rw-r--r-- 1 xxxx xxxx 444 May 6 17:18 known_hosts
Optional command:
rm known_hosts
chmod 400 id*
ssh -i ./id_rsa.pub ec2-user#bla-blah-blah.zzzzz.amazonaws.com
Last login: Fri May 6 19:09:48 2022 from 123.456.77.9
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
Just run this to add your key to localhost of current user.
ssh-copy-id localhost
Related
Local Setup
I created a public and private SSH key via the ssh-keygen command.
I decided to setup the private key locally first, before setting it up on my repo's gitlab CI.
I setup the public key on the server (in this case, another gitlab repo, but this may change in the future and shouldn't affect the question).
I successfully communicated with the server locally via the following command (in this case I am using SSH via git, but this again may change in the future):
git clone git#gitlab.com:...../......git
GitLab CI Setup
I then decided to setup the private key and communication on gitlab CI.
Inside my repo, I navigated to Settings -> Continuous Integration -> Variables, and added the following environment variables:
SSH_DEPLOY_PRIVATE_KEY - I used to same private key that I used locally
SSH_KNOWN_HOSTS
I took the gitlab.com known host from my local computer's ~/.ssh/known_hosts file
gitlab.com,35.231.145.151 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=
I then setup the SSH inside .gitlab-ci.yml:
script:
- apt-get install openssh-client -y
- eval $(ssh-agent -s)
- echo "$SSH_DEPLOY_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
- mkdir -p /.ssh && touch /.ssh/known_hosts
- echo "$SSH_KNOWN_HOSTS" >> /.ssh/known_hosts
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
This seemed to work fine and I got the following message: Identity added: (stdin) (runner#....)
I then added the same git clone command to communicate with the server, and it failed with the following error:
Cloning into '......'...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Testing locally still works. I used the same commands above to setup the SSH locally (except I used pacman -S openssh to install instead).
How do I fix this?
Edit
I'm aware that I can execute ssh-keyscan directly in the GitLab CI and this should in theory solve the problem, but from what I know, this is susceptible to man-in-the-middle attacks. I'm trying to find a more secure solution.
Edit 2
After running ssh-keyscan directly in the GitLab CI, I get the same error message.
Verbose output is the same:
$ GIT_SSH_COMMAND="ssh -vvv" git clone git#gitlab.com:..../.....git deployed
Cloning into 'deployed'...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Edit 3
Seems to be connected to the internet. Plus apt-get install wouldn't work otherwise.
Edit 4
I don't understand why this is such a difficult task. I followed this article and am doing everything correctly. There seems to be plenty of other similar questions, which also do not have any answers. Is this just an issue with GitLab CI that we have no control over?
I'm also now thinking that it has something to do with the fact that the SSH server is another GitLab repo. Maybe GitLab CI blocks SSH connections within the same network. Not sure why but it's a possibility. Also don't know how you'd connect without SSH.
Edit 5
The verbose output clearly was not working using GIT_SSH_COMMAND, so I tried an ssh connection without git:
ssh -vvvv git#gitlab.com
Log output:
OpenSSH_6.7p1 Debian-5+deb8u5, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug2: ssh_connect: needpriv 0
debug1: Connecting to gitlab.com [35.231.145.151] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "gitlab.com" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01#openssh.com,ecdsa-sha2-nistp384-cert-v01#openssh.com,ecdsa-sha2-nistp521-cert-v01#openssh.com,ssh-ed25519-cert-v01#openssh.com,ssh-rsa-cert-v01#openssh.com,ssh-dss-cert-v01#openssh.com,ssh-rsa-cert-v00#openssh.com,ssh-dss-cert-v00#openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,chacha20-poly1305#openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,chacha20-poly1305#openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: chacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com
debug2: kex_parse_kexinit: chacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup umac-64-etm#openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm#openssh.com none
debug2: mac_setup: setup umac-64-etm#openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm#openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35
debug3: load_hostkeys: loading entries for host "gitlab.com" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: load_hostkeys: loading entries for host "35.231.145.151" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
The second-last line indicates that it's trying to communicate with the terminal using the /dev/tty file. Of course, this script is running in a non-interactive manor so it fails. Shouldn't it be using my key instead of requesting a passphrase from the terminal?
You may need to try setting the mode to 644 rather than 700. 644 is what is suggested in the Verifying the SSH host keys documentation, and is also what SSH uses for this file by default. Some parts of SSH are very particular about this - I'm not sure if known_hosts is particular.
The docs also mention you should set the value of SSH_KNOWN_HOSTS variable to the entire output of ssh-keyscan since there are multiple keys.
EDIT:
The following .gitlab-ci.yml worked for me on GitLab.com. Note the use of ~/.ssh/ rather than /.ssh/.
image: ubuntu:latest
test_job:
script:
- apt-get update
- apt-get install openssh-client git-core -y
- eval $(ssh-agent -s)
- echo "$SSH_DEPLOY_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
- mkdir -p ~/.ssh && touch ~/.ssh/known_hosts
- echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
- git clone git#gitlab.com:gitlab-org/gitlab-ce.git
A server can have multiple signatures in case of load balanced server. Ideal way is to change
- echo "$SSH_KNOWN_HOSTS" >> /.ssh/known_hosts
to
- ssh-keyscan www.gitlab.com >> /.ssh/known_hosts
I wouldn't recommend using the same private key. Both for security reasons and because it might cause other problems. Also, make sure the authorized_keys file contains the public key on the server you want to access, otherwise the whole thing can't work.
I'm assuming you've followed a guide along the lines of this one?
Hope this does something.
So, I'm going through this tutorial (Running Hadoop on windows using cygwin...) to setup hadoop on my WINDOWS (please don't ask why I would use Linux). So I got to this point that I need to SSH to my localhost and test the SSH using Cygwin, but it closes the connection and says:
Connection closed by 127.0.0.1
I've googled a lot but couldn't find any proper answer for my problem.
P.S.: I'm running cygwin on Windows 7 professional x64
any idea?
BTW, Here is a sample run:
$ ssh -v localhost
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/Soroush/.ssh/id_rsa type 1
debug1: identity file /home/Soroush/.ssh/id_rsa-cert type -1
debug1: identity file /home/Soroush/.ssh/id_dsa type -1
debug1: identity file /home/Soroush/.ssh/id_dsa-cert type -1
debug1: identity file /home/Soroush/.ssh/id_ecdsa type -1
debug1: identity file /home/Soroush/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0
debug1: match: OpenSSH_6.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 19:2d:f6:84:4d:e5:0d:d4:5e:e6:e5:a4:6a:3c:ea:8b
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /home/Soroush/.ssh/known_hosts:1
debug1: ssh_ecdsa_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,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/Soroush/.ssh/id_rsa
Connection closed by 127.0.0.1
When you installed Cygwin and ran ssh-host-config, you might have created user cyg_server. So when you are connecting to ssh, you need to use the user cyg_server#localhost.
When you run ssh with that user, it will ask you for the password that you provided when you ran ssh-host-config.
$ ssh cyg_server#localhost
cyg_server#localhost's password:
Last login: Mon Dec 31 01:14:44 2012 from ::1
cyg_server#polorumpus ~
$
I hope it will be useful.
It looks like the key isn't being accepted. Check that /home/Soroush/.ssh/id_rsa.pub has been added to /home/Soroush/.ssh/authorized_keys
I would also check that
RSAAuthentication yes is set in /etc/ssh/sshd_config
I had to do these to fix the problem:
chown <USERNAME> /var/log/sshd.log
chown -R <USERNAME> /var/empty
chown <USERNAME> /etc/ssh*
chmod 755 /var/empty
chmod 644 /var/log/sshd.log
Note that the is my desired user name, not cyg_server.
I Found this post relating to my issue, but it turned out that my cyg_server account did not have administrator privilege.
I had the same problem, and it was generated by Putty authentication agent (Pageant): it was running with a private key. For some reason, it tried to use it to connect to localhost. If I closed Pageant (or removed the key), I could ssh to localhost.
But as I wanted to have Pageant running (to be a client of other ssh servers), I managed to modify the local sshd service, so that it 'ignored' in some way Pageant, to accept connections:
Modify /etc/ssh/sshd_config:
PubkeyAuthentication no
Now, it works
I had to use the 64-bit version of Cygwin to get this to work.
Note: I'm not a newb, and I've done this a gazillion times, but for some reason today it decided not to work.
I keep getting the Permission denied (publickey). error message when trying to connect to github via SSH or when trying to clone a repo, even after remaking the ssh key and adding it to "SSH Keys" in my account.
This is what I tried to do ten times today without success:
make a key with ssh-keygen.
open ~/.ssh/id_rsa.pub with Gedit or Notepad++ and copy the contents.
Go to account settings on github.com
Go to SSH Keys
Click on the Add Key button.
give the key a title
paste the key into the key box.
Save the key (enter my github password to verify).
And now, when I try doing ssh github.com it just won't work.... What in the world? Am I just too tired right now or am I missing something?
Here's the output from ssh -vvv github.com
OpenSSH_5.9p1, OpenSSL 1.0.0f 4 Jan 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/trusktr/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/trusktr/.ssh/id_rsa type 1
debug1: identity file /home/trusktr/.ssh/id_rsa-cert type -1
debug1: identity file /home/trusktr/.ssh/id_dsa type -1
debug1: identity file /home/trusktr/.ssh/id_dsa-cert type -1
debug1: identity file /home/trusktr/.ssh/id_ecdsa type -1
debug1: identity file /home/trusktr/.ssh/id_ecdsa-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.9
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "github.com" from file "/home/trusktr/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/trusktr/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01#openssh.com,ssh-rsa-cert-v00#openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01#openssh.com,ssh-rsa-cert-v00#openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01#openssh.com,ecdsa-sha2-nistp384-cert-v01#openssh.com,ecdsa-sha2-nistp521-cert-v01#openssh.com,ssh-dss-cert-v01#openssh.com,ssh-dss-cert-v00#openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64#openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64#openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib#openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc#lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc#lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64#openssh.com,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64#openssh.com,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 510/1024
d ebug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
debug3: load_hostkeys: loading entries for host "github.com" from file "/home/trusktr/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/trusktr/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "207.97.227.239" from file "/home/trusktr/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/trusktr/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/trusktr/.ssh/known_hosts:16
debug2: bits set: 497/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/trusktr/.ssh/id_rsa (0x14cce60)
debug2: key: trusktr#rocketship (0x14ce2b0)
debug2: key: /home/trusktr/.ssh/id_dsa ((nil))
debug2: key: /home/trusktr/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/trusktr/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: trusktr#rocketship
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/trusktr/.ssh/id_dsa
debug3: no such identity: /home/trusktr/.ssh/id_dsa
debug1: Trying private key: /home/trusktr/.ssh/id_ecdsa
debug3: no such identity: /home/trusktr/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
The GitHub ssh setup mentions testing your GitHub connection with:
$ ssh -T git#github.com
That follow the ssh uri syntax (also illustrated in "this answer").
But you did:
ssh github.com
(without any user). In that case, ssh reverts to the SCP syntax, which relies on a ~/.ssh/config file, with a section "github.com", to list:
the user
the hostname
(and optionally the public key location, but by default it will try ~/.ssh/id_rsa.pub)
To change it to a regular SSH URL, don't edit directly your .git/config file, as shown below.
Use the command git remote set-url:
git remote set-url origin git#github.com:username/repo.git
I had a similar problem, github did not use my SSH key. I always had to enter my username and password.
I've been looking at .git/config, under [remote "origin"] there was:
url = http://github.com/path/to/repository
or
url = https://github.com/path/to/repository
I changed the line into
url = ssh://git#github.com/path/to/repository
and then it worked.
After creating a config file (~/.ssh/config) it worked. This is what I had to put in it:
Host github.com
User git
Port 22
Hostname github.com
IdentityFile ~/.ssh/id_rsa
TCPKeepAlive yes
IdentitiesOnly yes
Thanks to #VonC for leading me to there in the comments.
I don't get why I never needed this before though.
If it works for other repositories, but not one in particular, then you are probably using the wrong remote url(i.e. https instead of git#github.com)
First, double check that your git ssh connection is working:
ssh -T git#github.com
If it works, check your remote:
git remote -v
it will display something like this:
origin https://github.com/ownername/repo(fetch)
origin https://github.com/ownername/repo(push)
where ownername is either your username or your organization name (the "owner" of the repository).
If the remotes indicate https at the beginning, then you need to change this url with:
git remote set-url origin git#github.com:ownername/repo.git
Go here for more details.
I was getting some weird line ending issue in Windows when copying the clone address from github.
Note the extra character before git. It was NOT appearing in my console. It was invisible.
git clone git#github.com:user/repo.git ./docker
Cloning into './docker'...
Warning: Permanently added the RSA host key for IP address '140.82.XXX.X' to the list of known hosts.
\302\226git#github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
It took me a while to notice the \302\226 before git in the response. Once I saw that, I backspaced before git# and made sure there was just a space there and it worked.
This is what worked for me:
git remote set-url origin git#github.com:<YOUR-USERNAME>/<YOUR-REPOSITORY>.git
Change the items in the <> and run the command, and then try a git push.
Github.com's page on managing remote repositories helped me.
GitHub recently underwent an audit of ALL keys. Go to the key section of your account to re-approve it.
For ssh you need to change the url. Open up the git config file and change the url to
url = git#github.com:username/repository.git
Another possible cause is permissions.
This weekend I have had the same problem with a new laptop and been unable to push to github even though my ssh key has been in Github for years.
The permissions on your ~/.ssh/ directory should be 700 and your id_rsa and id_rsa.pub should be 600
When I copied my keys to the new laptop my permissions were too permissive.
More info: https://help.ubuntu.com/community/SSH/OpenSSH/Keys
Worked for me after below:
git remote set-url origin git#github.com:username/repo.git
ssh -T git#github.com
I had a similar issue when moving from Windows 7 to Windows 10 using Git for Windows.
I had my SSH keys for a Gitlab of our company running on my old computer and using this ssh command in the Windows cmd or the Git Bash worked fine (with git.my_server.com replaced by the Git server domain) - so my Windows was able to use the key, but Git for Windows was not:
ssh -T git#git.my_server.com
(which displayed: "Welcome to GitLab, #my_username!). However, when trying to clone, push or pull with git, I got the "Permission denied (publickey)" error message.
I initially couldn't find the location/environment of the SSH keys that Git uses, so I tried to copy/paste the ssh keys into this environment by using the Git Bash:
Open the Git Bash from the Windows Start Menu (not from a directory). Enter
pwd
I later found out that this returns the location of your ssh keys. In my case this returned '/u/', which was a network drive mounted as "U:\" in my Windows account.
Type cd .ssh, then dir. This may list your currently existing id files, like id_rsa and id_rsa.pub. I deleted these files since I didn't need them anymore (you might want to skip this if you successfully used other SSH keys on your installation, e.g. for other Git Servers):
rm id_rsa
rm id_rsa.pub
Create a new id_rsa file (if you have an existing id_rsa file, you can also use another name, like id_rsa_gitlab_my_username or something like that. Add .pub to this name for the public key):
vi id_rsa
and press the 'i' on your keyboard to switch to text insertion mode. Now copy the content of your private key file (I had mine in C:\Users\my_windows_username.ssh\id_rsa and used Notepad++ to copy the complete content, Windows notepad works fine as well).
Press Escape on your keyboard to exit text insertion mode, then enter ':' and 'x', then Enter to save the file. Repeat this for the public key file.
If you use multiple SSH keys or used another name for the id_rsa file, you should also create a 'config' file or copy the content of your existing configuration file:
vi config
(Again, press 'i', insert text, press ':', 'x', then Enter.)
My file looks like this (use your server, user and SSH file name):
#SCC Gitlab
Host git.my_server.com
HostName git.my_server.com
User git
IdentityFile ~/.ssh/id_rsa
Now my Git for Windows was able to push, pull and clone without problems again.
First, try this (changing your email address as needed)
ssh-keygen -t rsa -b 4096 -C "you#yourdomain.com"
If you're creating using Cygwin, there might be confusion about the home directory, which is what happened for me, as I was referring to (copying to GitHub) an old/incorrect key from a different directory.
So in case this happens for you, after creating the key, do:
$ explorer .
Which will pop up a windows explorer window, showing your full/absolute path. That's when I saw the ~ directory was actually my Cygwin directory
C:\Program Files\cygwin64\home\{your_username}\.ssh
I was then able to copy my private SSH key and paste in GitHub, and cloning, etc.. then worked.
I had a similar problem on Gnome. Configuration was alright but keys weren't added to ssh-agent. A reboot did the trick. Gnome Keyring uses it's own ssh-agent.
In my case it was because I have 2 users, both had an SSH key. The first one that was authenticated wasn't the one I needed. So I deleted the SSH key from it.
This command helped me understand which user is being used because of it's output:
ssh -T git#github.com
you need to edit remote URL settings, just follow this step:
Open Terminal.
Change the current working directory to your local project.
List your existing remotes in order to get the name of the remote you want to change.
$ git remote -v
Change your remote's URL from HTTPS to SSH with the git remote set-url command.
change USERNAME and REPOSITORY as yours.
$ git remote set-url origin git#github.com:USERNAME/REPOSITORY.git
Verify that the remote URL has changed.
$ git remote -v
Verify new remote URL
now will shows:
origin git#github.com:USERNAME/REPOSITORY.git (fetch)
origin git#github.com:USERNAME/REPOSITORY.git (push)
After this you will never found Permission denied (publickey) and your push will run okay.
In .git/config I changed
[remote "origin"]
url = https://path/to/the/repo.git
to
[remote "origin"]
url = git#github.com:path/to/the/repo.git
It started working without any problem.
In addition, if you have previously cloned your project before setting up your SSH key, recloning will solve the problem. Ensure that your local repository is up to date with your remote repository.
In my case, it was related to DNS mapping (bitbuket was not pointing to the correct IP) I fixed it with doing a simple trick (i overwritten the IP address to point when looking for bitbucket.org)
open and edit /etc/hosts in ubuntu (in case of any other OS please look how can you can do the same)
sudo vim /etc/hosts
and add the following line (in the case of GitHub or any other website look for the IP and do the mapping accordingly)
18.205.93.2 bitbucket.org
and then it'll resolve the issue
i just spun up an AMI with amazon and I'm able to SSH in just fine using the key created by amazon. I've added a user to the system and set their password and when I try to log in i get "Permission denied (publickey)." when connecting to the server.
spoofy#shell:~$ ssh -v spoofy#honey-aws-west
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to honey-aws-west [50.1.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/spoofy/.ssh/id_rsa type -1
debug1: identity file /home/spoofy/.ssh/id_rsa-cert type -1
debug1: identity file /home/spoofy/.ssh/id_dsa type -1
debug1: identity file /home/spoofy/.ssh/id_dsa-cert type -1
debug1: identity file /home/spoofy/.ssh/id_ecdsa type -1
debug1: identity file /home/spoofy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian- 1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 2f:80:ab:9d:38:35:ae:eb:a2:bf:bc:20:1f:d9:89:62
debug1: Host 'honey-aws-west' is known and matches the RSA host key.
debug1: Found key in /home/spoofy/.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: 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: /home/spoofy/.ssh/id_rsa
debug1: Trying private key: /home/spoofy/.ssh/id_dsa
debug1: Trying private key: /home/spoofy/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).
I know that normally its a permissions problem in this situation but I've checked those and they seem fine.. also given that i can ssh -i blah.pem in .. i'm guessing it may be a different issue? here is the sshd_config
# Package generated configuration file
# See the sshd(8) manpage for details
# What ports, IPs and protocols we listen for
Port 1337
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
the user is not a super user..but does have sudo access.
I assume you mean that you cannot log in to this new user using a password.
First you need to check that ssh_config allows users to log in using a password. Depending on your default setup it may not be a default option.
Also if your new user has superuser permissions, it may also be blocked from loggin in using a password.
UPDATE:
You need to set one or both of these to yes. I don't remember the second, so try the first one.
ChallengeResponseAuthentication no
PasswordAuthentication no
I'm not clear if you are trying to log in with or without a password. If you are trying to log in with a new user account and no password, you need to add the public key for your user to the .ssh directory authorized_keys file.
If your user is named 'spoofy', go to
/home/spoofy/.ssh/
and here create a file called authorized_keys with your public key in it.
Then you should be able to log in with
$ ssh spoofy#ec2-#####.amazonaws.com
I have a longer writeup here.
http://thekeesh.com/2011/05/setting-up-user-accounts-password-authentication-and-ssh-keys-on-a-new-ec2-instance/
this worked for me:
ssh-keygen -R <server_IP>
to delete the old keys stored on the workstation
also works with instead of
then doing the same ssh again it worked:
ssh -v -i <your_pem_file> ubuntu#<server_IP>
on ubuntu instances the username is: ubuntu
on Amazon Linux AMI the username is: ec2-user
I didn't have to re-create the instance from an image.
You may have to run restorecon in the system
restorecon -r /home/*/.ssh
use super user or try command in root account.
example :
su ssh -v -i /path/key.pem username#IP_machine
I have been trying to connect from one EC2 instance to another using ssh public keys and have been having a very tough time.
Here is the scenario:
I need to have box 2 scp a file from box 1 in a script. This script will need to be able to scp without a password so I need to setup public keys.
On box 2 I ran ssh-keygen –t rsa and generated id_rsa and id_rsa.pub
I copied id_rsa.pub to box 1
I moved id_rsa.pub to .ssh and ran cat id_rsa.pug >> authorized_keys
I changed permissions of all .ssh directory to 700 on both boxes and the files themselves to 600.
I have changed the sshd_config settings on box 1 to:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
And then restarted ssh
/sbin/service sshd restart
When I try to scp or ssh into box1 from box1 I get the error:
Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat#tomcat1.****.com's password:
Any ideas?
I made that change and tried scp to tomcat1 and it failed. Here is the output:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, 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
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
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
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password
Your authorized keys line should be
AuthorizedKeysFile %h/.ssh/authorized_keys
The server is looking in the wrong directory for your server.
UPDATE - FIXED IT
restorecon -R -v -d /root/.ssh
This is a known issue with RH where directories get mislabelled and PAM prevends sshd from reading authorized_hosts when run as init script. You'll see the errors if you stumble across /var/log/audit/audit.log. Rare it seems but painful when it happens!
More details at https://bugzilla.redhat.com/show_bug.cgi?id=499343
ORIGINAL POST
I've just hit what looks like exactly this problem. I had a poorly tuned VirtualBox (I hadn't told vbox to use 64bit) -- which when I cloned and restarted (in vbox RedHat 64-bit mode), started asking me for a password.
The original image was fine -- with identical settings -- so I think the suggestion of being networking-related might be relevant, or else to do with server keys.
The weird thing however is that if on the box, I kill the sshd process which autostarted, then manually run /usr/sbin/sshd as root, I can log in passwordless fine. A silly workaround, but usable.
So it is an /etc/init.d/sshd issue. But I haven't been able to track down what it is ... have tried chucking out most of the stuff in that script but it still prompts for password when invoked as /etc/init.d/sshd start but not when at /usr/sbin/sshd.
Maybe these comments can help, and someone can then help further!?
Try removing box1 IP from ~/.ssh/known_hosts, so it renews. Perhaps ssh disables key authentication due to possible 'man in the middle' attack.
If it won't help, add line
GSSAPIAuthentication no
in your /etc/ssh/ssh_config file.
I think this link will solve your problem and I use it to solve my ssh not login problem. The keypoint is to run
ssh root#node02 'restorecon -R -v /root/.ssh'
this command will fix SE
http://blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/
After following previous steps I had to set the permission to ".." in the .ssh folder:
Once I had for ~/.ssh:
drwx------ 2 build build 4096 Nov 4 14:35 .
drwx------ 6 build build 4096 Nov 4 14:34 ..
-rw------- 1 build build 400 Nov 4 14:35 authorized_keys
It worked!
Thanks. Damian
I had the exact same problem and have been scratching my head for an entire afternoon.
It turned out to be a small sshd_config file issue.
first, change access mod on .ssh folder of the remote host to user access only.
chmod 700 ~/.ssh
next, go to /etc/ssh/sshd_config, change StrictModes yes to StrictModes no. If it's commented out, then specifically add StrictModes no into the file.
That solved the issue.
And one more thing I just found, I had to edit the .ssh/authorized_keys file to and make hostname fully qualified. Otherwise, I couldn't use the fully qualified name in the scp/ssh command. Now both fully qualified (like "host.company.com") & the relative name ("host") work, given that both hosts are in the "company.com" domain. ssh-keygen created the public key file with just the hostname.