I am trying to ssh in to a google compute engine using gcloud and this used to work fine. But for some reason I have been hitting a wall for a while now. It works fine from the console. The instance is box-standard default instance.
I keep getting
google compute ssh test
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).
and more verbosely
google compute ssh test -vvv
...
bug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mike/.ssh/google_compute_engine
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fpSHA256:bW6Bpi2N67+MIGbRkfLRcdl5ghxQWOAtiRiYazy1JXU
debug3: sign_and_send_pubkey: RSA SHA256:bW6Bpi2N67+MIGbRkfLRcdl5ghxQWOAtiRiYazy1JXU
sign_and_send_pubkey: signing failed: agent refused operation
I have tried with a fresh project, but the same result. Re-installed google cloud sdk, same result. I must be missing some setting value, but I have no idea what I am missing. I have ssh keys (the standard ones created by gcloud, called google_compute_engine(.pub) in my .ssh directory.
Any suggestions would be appreciated.
Cheers, Mike
After trying loads of things, I found that
sudo apt-get autoremove gnome-keyring
ssh-add -D
a reboot resolved this.
Related
Configuring SSH Keys from ePass2003 to access servers.
I have a guest ubuntu 16.04 on VirtualBox, i am able to SSH server 1 from VM but while SSH to server 2 from server 1, getting below error.
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:M0HzYuvGQ8LcKpJIGPgQDrN6Xs8jpyjH4wRQdslGeV
debug3: sign_and_send_pubkey: RSA SHA256:M0HzYuvGQ8LcKpJIGPgQDrN6Xs8jpyjH4wRQdslGeV
**sign_and_send_pubkey: signing failed: agent refused operation**
When i run ssh-add -l on server 2, i can see the below output.
$ ssh-add -l
error fetching identities for protocol 1: agent refused operation
2048 SHA256:M0HzYuvGQ8LcKpJIGPgQDrN6Xs8jpyjH4wRQdslGeV /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so (RSA)
I have made AllowAgentForwarding yes in /etc/ssh/sshd_config file. But still no luck in getting SSH connection to Server2 from Server1.
If anyone can help me getting through this would be great.
Thanks in Advance !!
I'd just like to add that I saw the same issue (in Ubuntu 18.04) and it was caused by bad permissions on my private key files. I did chmod 600 on the relevant files and the problem was resolved. Not sure why ssh-agent didn't complain about this until today.
I was able to get the fix for connection issue with SSH Keys. I had to make changes in SSH config files at location /etc/ssh/ssh_config and ~/.ssh/config
$ cat ~/.ssh/config
Host *
Compression yes
ForwardAgent yes
ForwardX11Trusted no
GSSAPIAuthentication no
PreferredAuthentications=publickey
and
$ cat /etc/ssh/ssh_config
Host *
ForwardAgent yes
ForwardX11Trusted yes
HashKnownHosts yes
GSSAPIAuthentication no
GSSAPIDelegateCredentials no
After above changes, restart ssh-agent and do ssh-add.
$ eval $(ssh-agent)
$ ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
I hope this should work with you all as well if you come across such issues.
We only need to execute this time.
eval "$(ssh-agent -s)"
Ssh-add
That's OK.
kind of random, but make sure your network isn't blocking it. I was at a hotel and I couldn't ssh into a server. I tried connecting in through my phones hotspot and it worked immediately. Give a different network a try as a quick way to trouble shoot.
Well, I have 2 computers call 120 and 110. I am trying to configure a ssh connection without password from 110 to 120. This is what i have done in the 120:
1- ssh-keygen -t rsa
2- scp ~/.ssh/id_rsa.pub root#110:.ssh/authorized_keys
and then in the 110:
1- chmod 700 ~/.ssh/authorized_keys
This steps don't work because it keeps asking for the password. So, I tried to do the opposite, from 120 to 110 and doing exactly the same thing it works.
I also change the PermitRootLogin yes in the /etc/ssh/sshd_config file of both computers.
I am out of ideas. Any suggestion?
EDIT:
This is what I got using ssh -vv:
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
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: Next authentication method: password
root#192.168.1.120's password:
Try running this (after generating the key):
ssh-add
Env:
VM A : the machine I want to access with out password
VM B : I want to access VM A without password from the machine
Problem Description:
As I want to access VM A from VM B without password, I want first inject VM B's public key into VM A, but I still need password if I use ssh-copy, so I try to inject the file by mount.
The steps:
Start VM A from LiveCD
Mount VM A's root disk(contains the OS)
Create an authorized_keys file under ${mount_point}/root/.ssh/
Cat the VM B's public key into the authorized_keys file
Stop the VM A and remove the LiveCD then start the VM A again
Access the VM A from VM B by command
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o PasswordAuthentication=no root#9.112.224.130
Results:
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
But after I did following commands, it works (file mode are all 600 and not difference with diff command)
mv authorized_keys authorized_keys_bak
cp authorized_keys_bak authorized_keys
so I try to inject it again, but for this time, I create an empty authorized_keys file before start from LiveCD, and skip the step 3, other step are all the same, for this time the VM B can access VM A without password
Questions:
The property for authorized_keys and authorized_keys_bak are all the same, why one works, one not works?
I authorized_keys can works only when I create the file not mount from LiveCD?
ssh-copy-id will ask you password one time to inject the keys into remote system.
Logs which you have shown is from ssh client. We would need ssh server logs as well to check why ssh server is not able to verify user credentials.
From client logs, we can say, it has tried for publickey based (without password) authentication but it failed (means rejected by server). So remaining method is "keyboard-interactive" (which is supported by server) but client doesn't support it so no authentication method to try so it failed.
Can you also check following things for working & non-working scenerio
check user's publickey on client and server which is used for authentication
on client -> /users//.ssh/id_rsa.pub
on server -> /etc/ssh/authorized_keys (check entry for your username)
I'm trying to get gitolite to work and have been stuck for hours. CentOS 6 server on my LAN.
I finally got ssh -vvv gitolite to work with this config file
Host gitolite
User gitolite
HostName srv
Port 2002
IdentityFile ~/.ssh/srv_gitolite_openssh
BUT it only works when I do this on the server to debug
sudo service sshd stop
sudo /usr/sbin/sshd -Dd
When sshd is running as a service, the connection fails.
http://pastebin.com/UHVS1sSK
Why does it work when I manually run sshd, but not with sshd as a service? It seems to use the same sshd_config file, because it uses the same port number. Also, my username gitolite is in the AllowUsers part of the config.
The success case looks like this:
http://pastebin.com/x4TcrG4R
Update: Here are the server-side logs
fail as a service: http://pastebin.com/Xce2k2x5
success: http://pastebin.com/jYgiDhEm
highlights from the fail case are below. Shouldn't the "key_from_blob" be the same in both cases? I've tried removing the command part of the authorized_keys and it still fails as a service.
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x7f72b6e93350
debug1: temporarily_use_uid: 505/505 (e=0/0)
debug1: trying public key file /var/lib/gitolite/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 505/505 (e=0/0)
debug1: trying public key file /var/lib/gitolite/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for gitolite from 192.168.1.201 port 57488 ssh2
debug3: mm_answer_keyallowed: key 0x7f72b6e93350 is not allowed
debug3: mm_request_send entering: type 22
highlights from the success case:
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x7f4d79de18b0
debug1: temporarily_use_uid: 505/505 (e=0/0)
debug1: trying public key file /var/lib/gitolite/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug3: secure_filename: checking '/var/lib/gitolite/.ssh'
debug3: secure_filename: checking '/var/lib/gitolite'
debug3: secure_filename: terminating check at '/var/lib/gitolite'
debug2: key_type_from_name: unknown key type 'command="/var/lib/gitolite/bin/gitolite-shell'
debug3: key_read: missing keytype
debug2: user_key_allowed: check options: 'command="/var/lib/gitolite/bin/gitolite-shell gitolite",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBrEOo5blAUXXSwXdxUxTOhBDHcjw2OzxGg6Vu4drzmUYL5uPxjWLGzuzcNkrYmlVqXr5UBqeSbkZh9W/0lLMcmiv5FLdIQ+J2m5lqHsEJLS8FImfJxfo2/LvboFy0NFOxF8GaHxeIWFp+YmwAlogO9gi1zgXK99DGc15W/edYwCw==
'
debug1: matching key found: file /var/lib/gitolite/.ssh/authorized_keys, line 2
Found matching RSA key: ae:92:1d:a7:7b:ec:75:7a:19:ac:28:75:b0:cc:27:8f
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f4d79de18b0 is allowed
I suspect the keys are working in both cases.
But running sshd as a service is different than running it from the current session: see "Why would I use “service sshd reload” in preference to “service sshd restart”?".
The service cancels all inherited environment variables, and keep only PATH and TERM.
Gitolite uses a forced command registered in ~gitolite/.ssh/authorized_keys, and there must be an environment variable missing (when sshd is run as a service) which prevents the execution of the command.
There was a similar case with "public key authentication fails ONLY when sshd is daemon":
SELinux is likely the cause.
The .ssh dir is probably mislabeled.
Look at /var/log/audit/audit.log. It should be labeled ssh_home_t.
Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.
My friend and I are trying to get ssh access on his server working from external networks. He is running Debian 7.1. He can access the server from the internal network but every time I try to access his server (of course from an external network), I get the following error.
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
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: /Users/MyUser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/MyUser/.ssh/id_dsa
debug3: no such identity: /Users/MyUser/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
MyUser#HisServer.com's password:
debug3: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
Permission of ~/.ssh/ is 700 and ~/.ssh/* is 600. He has
RSAAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
UsePAM yes
included in his sshd_config.
Port checker says that Port 22/tcp is open. Strangest thing is that we can't find any history of access in the log. sudo grep ssh /var/log/* only shows his activity.
Thus, I suspect it's the router's config that's causing the problem, but shouldn't we be able to ssh if the port is open?
You need to configure your router or DSL modem to port forward port 22 to the IP address of your server on port 22.
A simple test to do to check if it is a connectivity issue is to telnet on port 22:
telnet xxx.xxx.xxx.xxx 22
where the x's represent the external IP address of your router.
Maybe this will help.
Try to use your external ip adres find your ex.ip adress on http://www.whatismyip.com/.
I've sit for almost 4 weeks to find out not to use my 192.168.x.xxx adress
but to use the external one 88.67.xx.xxx.
Excuse me for my television english.
The reason why we couldn't ssh from external networks was because my friend had a "nested LAN".
It turns out that his apartment had its own LAN, so even after he port-forwarded tcp/22 to his server's private IP address (within his home's LAN), external access got stuck at the apartment's LAN.
He could have paid around $30 per port to open ports with numbers larger than 1000, if I remember correctly, but he figured it wasn't worth it, so we basically gave up.
You can use Corkscrew to tunnel ssh traffic through HTTP. No need to pay that ridiculous $30.