1

I'm having some issues SSH'ing to a server when logged into a particular VM.

From my local PC, I can log in to the server just fine using the command ssh -i .ssh/[my private key] username@domain.

If I then SSH into another unrelated server which also has the same private key and run the above command it will also log in just fine in to the server.

But, when I SSH into a particular OpenStack VM (again has the same private key) on the unrelated server and then SSH in to the server from there I start getting prompted for a passphrase. But a passphrase hasn't been set for the key so inevitably I get a "Permission denied (publickey)." error.

To double check, I removed the private key from the VM and scp'd the private key from my PC into it again and tried the same command I still get prompted for a passphrase.

In other words:

  1. PC - SSH - Server1 = Works fine
  2. PC - SSH - Server2 - SSH - Server1 = Works fine
  3. PC - SSH - Server2 - SSH - Virtual Machine - SSH - Server 1 = Asks for a passphrase

What could be the reason behind this? It's definitely the right private key I'm using and it has the appropriate permissions.

Edit - Output of ssh -v -i .ssh/[my private key] username@domain as requested

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /.ssh/[my private key].ppk type -1
debug1: key_load_public: No such file or directory
debug1: identity file /.ssh/[my private key].ppk-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to xxx.xxx.xxx.xxx:22 as '[my username]'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ZiugTjR5fM0E3evOwHoePFKspDQChA0Ab6L0q88KP/g
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /home/centos/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/[my private key].ppk
Enter passphrase for key '/.ssh/[my private key].ppk':
Enter passphrase for key '/.ssh/[my private key].ppk':
Enter passphrase for key '/.ssh/[my private key].ppk':
debug1: No more authentication methods to try.
Permission denied (publickey).
  • Rerun the problematic ssh command with an added -v. It may tell you what is going wrong. If you can't figure it out, copy and paste the output into your question. – jw013 Jun 8 '18 at 14:37
  • 1
    maybe could you check in VM's sshd logs (/var/log/secure?) for reject reason. – tonioc Jun 8 '18 at 14:38
  • @jw013 I've pasted the output into my question – RoyalSwish Jun 8 '18 at 15:00
  • @tonioc I've checked them but there are no errors or any form of rejection reason – RoyalSwish Jun 8 '18 at 15:00
  • 1
    Consider SSH Agent Forwarding instead of populating same private key over multiple servers - this way authentication will forwarded through multi-hop connections. It is -A (ForwardAgent option). – Tagwint Jun 8 '18 at 15:06
3
Enter passphrase for key '/.ssh/[my private key].ppk':

"ppk" is the extension used by the PuTTY key generation tool. I presume the key file was generated using the putty tool. Unfortunately, the OpenSSH ssh utility doesn't read the PuTTY key file format. sshis asking for a passphrase because it will do that any time it can't parse a key file.

You can use the putty key tool to export the key in OpenSSH format. You should end up with two files, my-private-key and my-private-key.pub. The .pub file contains the public key portion which is installed on the remote system. The other file contains the private key which you use with the ssh command.

Alternately, you could use the OpenSSH ssh-keygen utility to generate a new key.

  • Sorry if I'm misunderstanding you but are you saying the VM can't parse the keys or Server 1? If you're saying Server 1, that doesn't make sense because I can log in just fine using the same private key on my local PC and on Server 2. If, however, you're saying the VM can't parse the keys that also doesn't make sense because my colleagues who both have PuTTY gen keys can log in just fine in to Server 1 via the VM themselves; it's only me that can't – RoyalSwish Jun 8 '18 at 16:36
  • 1
    The issue is with the ssh command whose output you added to the question. If I understand your narrative correctly, you ran that command on the Openstack VM? Anyway, the core issue is that you're trying to use a putty format key file with the OpenSSH ssh utility. If it works for your colleagues, it could be that they're using the putty utility instead of ssh. Or else they are using a copy of the key file converted to the OpenSSH format, as I suggested in the answer. – Kenster Jun 8 '18 at 16:51
  • Ah okay, gotcha! Luckily with PuTTY Gen you can load the private key previously generated and then export it as an OpenSSH key without having to setting up a new key-pair. You're correct, it needed to be OpenSSH standard and my colleagues must have done the same. FYI, I was also using MobaXterm client which is PuTTY based which explains why it could use the PuTTY Private Key to SSH to Server 1 and must also have the ability to work through a single SSH but not a second, which might be the reason it stopped at the VM level. – RoyalSwish Jun 8 '18 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.