Gitlab, Permission denied (publickey), version 6-4 stable - ssh

Permission denied (publickey). fatal: Could not read from remote
repository.
Please make sure you have the correct access rights and the repository
exists.
Gitlab version 6-4 stable
root#gitlab:/home/git/gitlab# sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
System information
System: Ubuntu 12.04
Current User: git
Using RVM: no
Ruby Version: 2.0.0p353
Gem Version: 2.0.14
Bundler Version:1.5.2
Rake Version: 10.1.0
GitLab information
Version: 6.4.3
Revision: 38397db
Directory: /home/git/gitlab
DB Adapter: mysql2
URL: http://gitlab.xxx.xxx
HTTP Clone URL: http://gitlab.xxx.xxx/some-project.git
SSH Clone URL: git#gitlab.xxx.xxx/some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 1.8.0
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git
root#gitlab:/home/git/gitlab# sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
Checking Environment ...
Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes
Checking Environment ... Finished
Checking GitLab Shell ...
GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
update hook up-to-date? ... yes
update hooks in repos are links: ...
Alexander / Test ... repository is empty
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.2.12
Send ping to redis server: PONG
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
projects have namespace: ...
Alexander / Test ... yes
Projects have satellites? ...
Alexander / Test ... can't create, repository is empty
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.5)
Checking GitLab ... Finished
And trying to push
root#gitlab:/home/git/repositories/test# git push origin master
Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and
the repository exists.
shh -vv git#xxx.xxx
alex#xxxxxxx:~$ ssh -vv git#gitlab.xxx.xxx
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013
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 gitlab.xxx.xxx [192.168.0.40] port 22.
debug1: Connection established.
debug1: identity file /home/alex/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2047
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2047
debug1: identity file /home/alex/.ssh/id_rsa-cert type -1
debug1: identity file /home/alex/.ssh/id_dsa type -1
debug1: identity file /home/alex/.ssh/id_dsa-cert type -1
debug1: identity file /home/alex/.ssh/id_ecdsa type -1
debug1: identity file /home/alex/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
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: ecdsa-sha2-nistp256-cert-v01#openssh.com,ecdsa-sha2-nistp384-cert-v01#openssh.com,ecdsa-sha2-nistp521-cert-v01#openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01#openssh.com,ssh-dss-cert-v01#openssh.com,ssh-rsa-cert-v00#openssh.com,ssh-dss-cert-v00#openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm#openssh.com,aes256-gcm#openssh.com,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-gcm#openssh.com,aes256-gcm#openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-sha1,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-sha1,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,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: 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,ssh-dss,ecdsa-sha2-nistp256
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
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Host 'gitlab.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /home/alex/.ssh/known_hosts:30
debug1: ssh_ecdsa_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/alex/.ssh/id_rsa (0x7f8d86afa4f0),
debug2: key: /home/alex/.ssh/id_dsa ((nil)),
debug2: key: /home/alex/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alex/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 276
debug2: input_userauth_pk_ok: fp xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.xxx.xxx ([192.168.0.40]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
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.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LC_PAPER = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_ADDRESS = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_MONETARY = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_NUMERIC = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_TELEPHONE = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_IDENTIFICATION = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_MEASUREMENT = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_TIME = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_NAME = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 100 id 0
PTY allocation request failed on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to GitLab, Anonymous!
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
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
Connection to gitlab.xxx.xxx closed.
Transferred: sent 4088, received 2432 bytes, in 0.3 seconds
Bytes per second: sent 14872.5, received 8847.8
debug1: Exit status 0
alex#xxxxx:~$ ssh git#gitlab.xxx.xxx
PTY allocation request failed on channel 0
Welcome to GitLab, Anonymous!
Connection to gitlab.xxx.xx closed.
I tried with 5.4 stable and the same problem on production server.
But when for the sake of interest I installed 5.4 on local test server with virtual box and It works fine. Now I am even had compared everything, but It does not push on production server. Looks like this problem is related to SSH.
I searched already a lot, but all solutions I tried did not work in my case. I have already no idea, feels like it is kind of software bug...
I will appreciate any help. Thanks in advance!
Kind regards,
Alex

Try also pushing to the https url instead of the ssh this can save you lot of trouble - for example use this:
git remote add origin https://gitlab.com/someuser/algorithm-excercises.git
instead of:
git remote add origin git#gitlab.com:someuser/algorithm-excercises.git

I found this after searching alot. It will work perfectly fine for me.
Go to "Git Bash" just like cmd.
Type ssh-keygen
Press enter.
It will ask you to save the key to the specific directory.
Press enter. It will prompt you to type password or enter without password.
The public key will be created to the specific directory.
Now go to the directory and open .ssh folder.
You'll see a file id_rsa.pub. Open it on notepad. Copy all text from it.
Go to https://gitlab.com/profile/keys .
Paste here in the "key" textfield.
Now click on the "Title" below. It will automatically get filled.
Then click "Add key".
Now give it a shot and it will work for sure.

Hi I had a similar problem (it was after adding new ssh key to a newly created user)
I fixed it regenerating authorized_keys which was corrupted
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file.
Do you want to continue (yes/no)? yes

I posted an answer to a similar question
Why does ssh connection to gitlab not work (while http push and clone work fine)?
which involves adding your public key to
/home/git/repositories/.ssh/authorized_keys

open your terminal and make public key:
ssh-keygen -t rsa -C "yourmail#mail.com" -b 4096
go to your ssh rsa folder in your system:
on Mac go to GO to Folder and type this address:
~/.ssh
then open it with text editor and copy the key
then go to gitlab setting shh key and pate it there
https://gitlab.com/profile/keys/2346923
then try again
git push -u origin master

Adding .ssh folder in repositories worked for me so I have done this:
sudo -u git -H ln -s /home/git/.ssh /home/git/repositories/
Now all users can add the key from gitlab web and use ssh.

Make sure you have an existing SSH key pair in local.
Go to your home directory, then go to the .ssh/ subdirectory. If the .ssh/ subdirectory doesn't exist,
you are either not in the home directory, or you haven't used ssh before.
If not exist, You need to Generate an SSH key pair in .ssh/ subdirectory:
cd ~
cd .ssh/
ssh-keygen -t ed25519 -C "<comment>"
Then just press enter to finish.

Related

SSH Host Key Verification Failed inside GitLab CI

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.

ansible permission denied, but ssh with key works

UPDATE: Thanks for the feedback guys. As expected, it turned out to be a bonehead mistake on my part. I was not specifying the correct username when I was running the ansible command. If you run ansible without any user (-u), then it will use your current system username. In my case that was swill when I wanted to run it as root.
This is now working:
ansible all -m ping -u root
I am pretty baffled at this point. I can ssh into the box using the public key without any problems, but when I try to use ansible to connect I get no love.
Note: I am using <ip_address> as the IP as to not expose my actual IP address...
My local /etc/ansible/hosts has the following
<ip_address>
I can ssh into the remote box using my default ssh key:
$ ssh root#<ip_address>
I setup ssh on my remote box using:
$ cat ~/.ssh/id_rsa.pub | ssh <user>#<ip_address> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
The contents of my remote /etc/ssh/sshd_config file is:
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# 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
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# 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
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no
Here is what I am getting when I try to connect with ansible...
swill:ansible swill$ ansible all -m ping -vvvv
<<ip_address>> ESTABLISH CONNECTION FOR USER: swill
<<ip_address>> REMOTE_MODULE ping
<<ip_address>> EXEC ssh -C -tt -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath="/Users/swill/.ansible/cp/ansible-ssh-%h-%p-%r" -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 <ip_address> /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1435804031.59-82833056078245 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1435804031.59-82833056078245 && echo $HOME/.ansible/tmp/ansible-tmp-1435804031.59-82833056078245'
<ip_address> | FAILED => SSH Error: Permission denied (publickey).
while connecting to <ip_address>:22
It is sometimes useful to re-run the command using -vvvv, which prints SSH debug output to help diagnose the issue.
swill:ansible swill$ ssh -C -tt -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath="/Users/swill/.ansible/cp/ansible-ssh-%h-%p-%r" -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 <ip_address> /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1435804031.59-82833056078245 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1435804031.59-82833056078245 && echo $HOME/.ansible/tmp/ansible-tmp-1435804031.59-82833056078245'
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/swill/.ssh/config
debug1: /Users/swill/.ssh/config line 4: Applying options for <ip_address>
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/swill/.ansible/cp/ansible-ssh-<ip_address>-22-swill" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to <ip_address> [<ip_address>] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug3: timeout: 9958 ms remain after connect
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/swill/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/swill/.ssh/id_rsa type 1
debug1: identity file /Users/swill/.ssh/id_rsa-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.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "<ip_address>" from file "/Users/swill/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/swill/.ssh/known_hosts:134
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: 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,ssh-dss-cert-v01#openssh.com,ssh-dss-cert-v00#openssh.com,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm#openssh.com,aes256-gcm#openssh.com,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-gcm#openssh.com,aes256-gcm#openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-sha1,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-sha1,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib#openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib#openssh.com,zlib,none
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-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm#openssh.com,aes256-gcm#openssh.com,chacha20-poly1305#openssh.com,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-gcm#openssh.com,aes256-gcm#openssh.com,chacha20-poly1305#openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc#lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-sha1,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160#openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-ripemd160-etm#openssh.com,hmac-sha1-96-etm#openssh.com,hmac-md5-96-etm#openssh.com,hmac-md5,hmac-sha1,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,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-etm#openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com zlib#openssh.com
debug2: mac_setup: found hmac-md5-etm#openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com zlib#openssh.com
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: 129/256
debug2: bits set: 528/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 5c:c8:5f:d3:24:fe:ca:e2:05:03:12:d6:cb:42:d2:91
debug3: load_hostkeys: loading entries for host "<ip_address>" from file "/Users/swill/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/swill/.ssh/known_hosts:134
debug3: load_hostkeys: loaded 1 keys
debug1: Host '<ip_address>' is known and matches the RSA host key.
debug1: Found key in /Users/swill/.ssh/known_hosts:134
debug2: bits set: 505/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: /Users/swill/.ssh/id_rsa (0x7f8482500680), explicit
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,gssapi-keyex,hostbased,publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: ,gssapi-keyex,hostbased,publickey
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/swill/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
I would appreciate it if someone could help me see why I am an idiot and can't figure this out. :) Thanks...
I was facing a related issue:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
The problem was the permissions with the server (ssh). I corrected it with giving the correct permissions to the .ssh and authorized_keys file, as shown below :
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Login to Bluemix VM suddenly asks for password

I have created a VM with a public ssh key.
Once is it created, I am able to login with the private ssh key:
ssh -i cloud.key ibmcloud#129.41.xxx.xx
After some successful logins, suddenly when trying to login with the same command I am asked for a password:
$ ssh -i cloud.key ibmcloud#129.41.xxx.xx
ibmcloud#129.41.133.80's password:
Do you know why is this happening?
I have removed and recreated the VM with same behaviour. After some successful logins, it started to ask for a password.
[EDITED] Added -vv verbose info:
.........
.........
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 12:05:44:27:ab:c9:98:5f:45:ab:1d:d7:e0:ca:ba:3a
debug1: Host '129.41.xxx.xx' is known and matches the ECDSA host key.
debug1: Found key in /home/xxxx/.ssh/known_hosts:11
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: cloud.key (0x6000686e0), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: cloud.key
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Thanks!
Make sure that there are no typos in your command . For example a typo in the IP address can inadvertently point you to another VM where your key would not work and it would fallback to using a password. If that's not the case then your best bet is to get more details about why you're being prompted for a password. Try the following command:
$ ssh -vv -i cloud.key ibmcloud#129.xxx.xxx.xxx
The will give a detailed trace of the command as it's negotiating with your VM and give you some indication of why it's bypassing your keyfile and falling back to using a password instead. If the cause of the behavior is still not clear after you try this, post the output of the command above.
Answering my own question.... the issue was a colleague changed home directory permissions to 777 and for some reason SSH thinks that is not secure and doesn't authenticate although -vv parameter doesn't say anything about it.
Hope this helps others.
ssh ibmcloud#129.xxx.xxx.xxx
That should work. If it doesn't, generate a new ssh key, copy it to clipboard with xclip or pbcopy, then paste it in Bluemix (Create a VM > new SSH key > Import > paste ssh key).

Scp fails in one direction for admin but is successful with root user

I am able to do a scp from server A to another server B using admin but the same admin is not able to send files back from server B to server A. I used scp -vv and the detials look as below:
Can a admin not scp files in some cases? if so how do I check the previlidges?
Executing: program /usr/local/bin/ssh host 140.199.280.888, user adm, command scp -v -t /home/adm/test
OpenSSH_4.3p2, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to 140.199.280.888 [140.199.280.888 port 22.
debug1: Connection established.
debug1: identity file /home/pro/.ssh/identity type -1
debug1: identity file /home/pro/.ssh/id_rsa type -1
debug1: identity file /home/pro/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '140.199.280.888' is known and matches the RSA host key.
debug1: Found key in /home/prov/.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,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pro/.ssh/identity
debug1: Trying private key: /home/pro/.ssh/id_rsa
debug1: Trying private key: /home/pro/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
adm#140.199.280.888's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t /home/adm/test
Setting up release specific environment variables...
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug2: fd 6 setting O_NONBLOCK
debug2: fd 7 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending command: scp -v -t /home/adm/test/
debug2: channel 0: request exec confirm 0
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Setting up release specific environment variables...
debug2: channel 0: read<=0 rfd 6 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
adm#pro% debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug2: channel 0: rcvd eof
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
How could I resolve this. Or wht am I missing here.
This looks like a known issue .bashrc and scp (excacly output from bash and non interactive shell). I solved this problem by modifying the part of .bashrc to execute only for interactive shell
case $- in
*i*) # interactive shell
alias cc='clearCache.sh'
echo 'Alias:
cc - clear cache
;;
esac
Links to such problems:
http://www.linuxquestions.org/questions/linux-server-73/strange-scp-error-and-fail-664945/
https://bugzilla.redhat.com/show_bug.cgi?id=20527
https://serverfault.com/questions/485487/use-bashrc-without-breaking-sftp

ssh server close connection after password attempt

I am trying to access to remote server via ssh. I couldn't do it via ssh command in CLI, but with same credentials I can access via putty ssh.
I am using ubuntu 12.04.
I don't have access to ssh server, so I can't change sshd config file.
Access to ssh server is possible form other machines via ssh CLI command, but from my mashine this is not working. Credentials are proper because I can connect via putty, and I don't get any message from server when I enter password. It just close connection.
command i use to connect via ssh in CLI is:
ssh -vv someuser#somehost.com
This is output:
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
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 somehost.com [53.52.81.241] port 22.
debug1: Connection established.
debug1: identity file /home/djuki/.ssh/id_rsa type -1
debug1: identity file /home/djuki/.ssh/id_rsa-cert type -1
debug1: identity file /home/djuki/.ssh/id_dsa type -1
debug1: identity file /home/djuki/.ssh/id_dsa-cert type -1
debug1: identity file /home/djuki/.ssh/id_ecdsa type -1
debug1: identity file /home/djuki/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug2: fd 3 setting O_NONBLOCK
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-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
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: 125/256
debug2: bits set: 514/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA e5:55:0d:1a:0e:2e:c5:03:db:05:c3:85:af:cf:bd:cd
debug1: Host 'somehost.com' is known and matches the RSA host key.
debug1: Found key in /home/djuki/.ssh/known_hosts:1
debug2: bits set: 499/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/djuki/.ssh/id_rsa ((nil))
debug2: key: /home/djuki/.ssh/id_dsa ((nil))
debug2: key: /home/djuki/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /home/djuki/.ssh/id_rsa
debug1: Trying private key: /home/djuki/.ssh/id_dsa
debug1: Trying private key: /home/djuki/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
someuser#somehost.com's password:
debug2: we sent a password packet, wait for reply
Connection closed by 30.52.83.243
First you can try with ssh -o GSSAPIAuthentication=no someuser#somehost.com ; it should make the Unspecified GSS failure messages disappear.
Then, if you are able to connect with putty, you can connect and then run sshd in debug mode on a higher port (you do not need to be root to do that, but you need no firewall blocking all the ports) :
/usr/sbin/sshd -d -e -p1234
and then you can try to connect in CLI with
ssh -p 1234 someuser#somehost.com
and you will see, in your putty session, the reason why the server closes the connection.
Check /etc/ssh/sshd_config for one of the following,
LoginGraceTime and make sure that is set to a time limit that you can enter your password. Otherwise it will close the connection if your request doesn't get authenticated within the timeframe. (example: this will give you a 1min window, LoginGraceTime 60)
"UseDNS no" will make sure sshd would not try to resolve the hostname. If the ssh client computer and the server are using two different nameservers and they point to different IPs for the same hostname might end up locking you out. So "UseDNS no" would resolve such problems.
"PasswordAuthentication yes" will make sure the SSHd accepts user entered passwords.
That's all I have come across for this issue.