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.
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.
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
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.
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.