I am trying to set up a new ssh key for a gcloud instance. I followed the instructions here verbatim (https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys), generating a new key, putting the public rsa-ssh key with my username on the SSH Keys section of the Metadata tab in the Google Cloud Platform interface, and setting the appropriate permissions for my public and private keys with chmod.
I am getting an error which ends as follows, when attempting to ss using the -vvv verbose flag:
...
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/erickofman/.ssh/salsadb
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
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 have (with a co-worker) ensured that my public key is contained within the authorized_keys file in the server's .ssh folder. Thinking that perhaps something was just stale, I also tried restarting the ssh server using service sshd restart to no avail.
I also tried setting up ssh using the gcloud tool, same result.
I have the correct role/permissions for the site from what I can tell.
This is what the log looks like on the server side:
admin#awesome-website:~$ tail /var/log/auth.log
Nov 15 20:40:16 awesome-website sshd[18846]: input_userauth_request: invalid user ekofman [preauth]
Nov 15 20:40:17 awesome-website sshd[18846]: Connection closed by 10.100.100.10 port 90001 [preauth]
Nov 15 20:41:17 awesome-website sshd[18848]: Connection closed by 200.200.20.20 port 90002 [preauth]
Been banging my head on this for a bit, any help much appreciated!
Whelp, turns out that new ssh keys do not get incorporated unless a full instance restart is effected. Not ssh server restart, but a full instance restart (stop gcloud instance, then start gcloud instance). It doesn't say this in the documentation, good to know for future reference.
Per this make sure you're .ssh/authorized_keys in your user's directory.
You also want to ensure your .ssh directory and authorized_keys have the proper permissions set. (700 and 600 respectively).
sudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/authorized_keys
Related
My host is mac and I create ubuntu 14.04 using VirtualBox.I am trying to ssh to its root account having set a password for root.
when I execute ssh -vvv root#ip and input my password.
Following is debug infomation:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
how can I connect my virual machine?
The SSH daemon does not allow root logins by default.
You must just add this line to your /etc/sshd_config file:
PermitRootLogin yes
Be careful! ssh to root does not log what's happening.
It is better to have a user with sudo permissions. This gets logged for later investigation.
I've used ddev auth ssh to add my ssh identities to my DDEV-Local projects.
But when I use ssh to connect to an external host, ssh example.com I get "Too many authentication failures"
Received disconnect from 174.127.116.22 port 22:2: Too many authentication failures
Disconnected from 174.127.116.22 port 22
When I use ssh -v example.com I see it trying six different keys before giving up with the "Too many authentication failures":
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:LrokWMbl1bD0vV0z7Qpn4HLd168NYSIAbqsek6aXIaE agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:ecpRhfcaRWS8EfmYyLuJ81ayhyPWAZd9MG3mKOUKMqA agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:07LrVlDSWu4r+4Eb6WP8FpWYYcREw7IcGm4rtp5v+Ws agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:6L9cIsLlu858CPgb5zZ3v3+5p808uNencyAxJ0S9wOM agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:HwksLkZqEXAK6Zo21+y/C508Mjx2I7EvUQWFScKHsAQ agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:dsGaELF0OPNyQfIYZoEyI+dP3AQqh5r+15iUwfalNtc agent
Received disconnect from 174.127.116.75 port 22:2: Too many authentication failures
Disconnected from 174.127.116.75 port 22
How can I solve this problem? Note that I have 10 different private keys in my ~/.ssh directory.
It seems ssh wasn't designed for use with loads and loads of private keys, but some people end up with lots of them anyway. (Note that you can use a single private key for many, many purposes; all you share with the world or an external service is the public key, which does not give away any information about the private key.)
Since ddev auth ssh is setting up an ssh agent for you, and there doesn't seem to be a way to make ssh choose a specific identity from among the identities provided by the agent, you'll need to use one of two workarounds.
Workaround #1: Use just a few keys
You could, of course, winnow down the number of keys in your ~/.ssh directory to 6 or fewer (6 is the default in sshd on the server side for MaxAuthTries). But let's assume you don't want to do that.
Create a directory, maybe ~/ddev-ssh-keys. In that directory, either copy or symlink the 6 keys you use most often. So cd ~/ddev-ssh-keys && for item in goodkey1 goodkey2 ... googdkey6; do ln -s ~/.ssh/$item; done (or any way you want to accomplish the linking or copying).
Now ddev auth ssh -d ~/ddev-ssh-keys and the ddev-ssh-agent will only have those 6 keys. If they're the right keys to solve most of your problems, you should be good with this approach.
Workaround #2: Copy keys into the container using .ddev/homeadditions
This workaround will let you actually copy the key(s) you want into the web container. This isn't probably as secure as the first approach (because you should never really copy your private keys anywhere), but it works.
If you really want the keys in the container (as opposed to using the agent), then mkdir -p .ddev/homeadditions/.ssh && cp ~/.ssh/<yourimportantkey(s)> .ddev/homeadditions/.ssh && chmod 700 .ddev/homeadditions/.ssh && chmod 600 .ddev/homeadditions/.ssh/*. You can then use the .ddev/homeadditions/.ssh/config file any way you want, including specifying keys.
This answer is adapted from https://github.com/drud/ddev/pull/2224
This is an extension of rfay's Workaround #2, to make it more secure. You can use the public part of a key pair to specify which private key you want to use from the ssh agent. So, instead of copying your private keys into the .ddev/homeadditions/.ssh folder, just copy the pub keys. For example, mkdir -p .ddev/homeadditions/.ssh && cp ~/.ssh/*.pub .ddev/homeadditions/.ssh && chmod 700 .ddev/homeadditions/.ssh && chmod 600 .ddev/homeadditions/.ssh/*.
Technically, you don't even need to 'chmod 600' the key files since they're the pub keys, but it does add some security.
You can then specify the key to use on the command line:
ssh -i ~/.ssh/id_rsa.pub example#example.com
ssh -o IdentityFile=~/.ssh/id_rsa.pub example#example.com
Or you can specify the IdentityFile in your .ssh/config file.
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.
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)
Again I have a question about an ssh issue:
On a embedded system (no display, no keyboard) my only login interface was ssh. Telnet is disabled too. (I am currently trying to enable it with only little hope...)
My only interaction at the moment is receiving a ping answer and browsing my shared files via smb://!
ssh's answer is always:
$ ssh -vvvvl root 192.168.0.3
OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
debug1: Connection established.
debug1: identity file /home/simon/.ssh/id_rsa type -1
debug1: identity file /home/simon/.ssh/id_rsa-cert type -1
debug1: identity file /home/simon/.ssh/id_dsa type -1
debug1: identity file /home/simon/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-8
debug1: match: OpenSSH_4.3p2 Debian-8 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
But I direct access to the hdd through pulling it out of the device and manipulating files on it while it is connected to another machine.
One of my last steps before I logged off and get locked out was sudo rm /etc/ssh/*host*key* followed by dpkg-reconfigure openssh-server, what failed because dpkg-reconfigure was not found. So I guess the problem is, that the keys are deleted.
My question is now: how can I off-shore create keys and provide them to sshd without running any command on the target system OR how can I make sshd let me log in without having a key?
Thanks for your help if there is any..?!
You can generate a new set of host keys on a handy Linux system as follows:
ssh-keygen -t rsa -b 2048 -f ssh_host_rsa_key
ssh-keygen -t dsa -b 1024 -f ssh_host_dsa_key
When ssh-keygen asks you for a passphrase, hit Enter without typing anything. Host keys must have an empty passphrase.
This creates the following files in your current directory:
ssh_host_rsa_key
ssh_host_rsa_key.pub
ssh_host_dsa_key
ssh_host_dsa_key.pub
You can then mount your device's hard drive and copy these four files into etc/ssh.
Note that when you try to ssh to the system afterwards, your ssh client will complain that the keys are different than expected, and probably refuse to connect. If you're running the OpenSSH client, you can correct this by using ssh-keygen again:
ssh-keygen -R <your_server_hostname>
ssh -vvvvl root 192.168.0.3
should be:
ssh -vvvvl root#192.168.0.3
I don't know if that is just a typo you made while posting on stackoverflow or if you typed it in on the command line.