Ubuntu Core Image - Unable to SSH into Raspberry Pi 3

Question

I created install Ubuntu Core on a Raspberry Pi 3.

I followed the instructions here: https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3

I made it all the way to a screen that says what my host fingerprints are, and that I could login using:

ssh [email protected]

It asked me for a password so I pressed 'Enter' since the instructions explicitly state, "without a password".

This failed so I tried entering the UbuntuOne password and the ssh private key password. It still failed.

I ran ping 192.168.XX.XX and received successful pings from the Pi.

So I ran ssh -vvv [email protected] and got the following (usernames and IPs sanitized).

OpenSSH_7.3p1, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /c/Users/XYZ/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "192.168.XX.XX" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.XX.XX [192.168.XX.XX] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/XYZ/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.XX.XX:22 as 'pi-user'
debug3: hostkeys_foreach: reading file "/c/Users/XYZ/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /c/Users/XYZ/.ssh/known_hosts:1
debug3: record_hostkey: found key type RSA in file /c/Users/XYZ/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 2 keys from 192.168.XX.XX
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa,[email protected],ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Mj32uvE1Ubzbf8GxRzbj+Dxnsg78muYv4tq1CmyQNSY
debug3: hostkeys_foreach: reading file "/c/Users/XYZ/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /c/Users/XYZ/.ssh/known_hosts:1
debug3: record_hostkey: found key type RSA in file /c/Users/XYZ/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 2 keys from 192.168.XX.XX
debug1: Host '192.168.XX.XX' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/XYZ/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /c/Users/XYZ/.ssh/id_rsa (0x0)
debug2: key: /c/Users/XYZ/.ssh/id_dsa (0x0)
debug2: key: /c/Users/XYZ/.ssh/id_ecdsa (0x0)
debug2: key: /c/Users/XYZ/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
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: Trying private key: /c/Users/XYZ/.ssh/id_rsa
debug3: no such identity: /c/Users/XYZ/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /c/Users/XYZ/.ssh/id_dsa
debug3: no such identity: /c/Users/XYZ/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /c/Users/XYZ/.ssh/id_ecdsa
debug3: no such identity: /c/Users/XYZ/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /c/Users/XYZ/.ssh/id_ed25519
debug3: no such identity: /c/Users/XYZ/.ssh/id_ed25519: No such file or directory
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
[email protected]'s password:

Not sure what the try next. Also, it seems strange that once Ubuntu loads on the Pi it remains at the ssh login screen and will not accept CTRL + C or keyboard input. It seems to be enforcing SSH-only interaction.

Answer 1

Here is the solution that worked for me.

Use ssh-keygen instead of puttygen.

I noticed that the output of ssh-key ends with <username>@<hostname>, but that the output of puttygen ends with <name assigned in puttygen form>.

The ssh-keygen command was used as follows:

ssh-keygen -t rsa -b 4096

I also changed the <username>@<hostname> to <ubuntu-one username>@<192.168.XX.XX>. I did this before copying it to my Ubuntu One account. Not sure if that is required or not.

Name the file id_rsa instead of ubuntu-one like I did originally.

When I ran ssh with the -vvv option I noticed this:

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: /c/Users/XYZ/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51

It turns out that ssh only looks for the public key on my local machine expecting the default name of id_rsa. I named my key differently, and this caused the receive packet: type 51. According to the SSH Protocol Standard RFC4252, "Type 51 stands for SSH_MSG_USERAUTH_FAILURE. This means that the request failed, or more authentications are needed."

Answer 2

I had the exact same issue. Followed many tutorial on the web. at the end, I became creative... I created the ssh keys using keygen in ubuntu. Imported the pub key in Ubuntu One (a must). After failing 100% of the time with putty, I decided to give a try with a different ssh client. I dl and used Bitvise ssh client. I imported my private key (not sure it was necessary). I than set the target machine and specified to use the ssh keys only (vs ssh keys+password). That is because during the key creation, you need to add a password that is always requested anyway. And BANG.. I got the password request as expected and I was in. And I could enable the SSL.. :-) Thought that might be helping others....

Answer 3

This failed so I tried entering the UbuntuOne password and the ssh private key password. It still failed.

Right. The only password you should have to type in is the one to decrypt your SSH key, if it's not already available in an agent. The key bits of the debug output are:

debug1: Trying private key: ...
...
debug1: Next authentication method: password
[email protected]'s password:

The instructions state:

This device is registered to <Ubuntu SSO email address>. Remote access was enabled via authentication with the SSO user Public SSH keys were added to the device for remote access.

The first thing this is telling you, when you examine the debug (or even non-debug) ssh output, is that you're trying to log in as the wrong user. The system appears to have configured an account with the same name as your Ubuntu SSO user name, and unless you log into ubuntu.com as pi-user, you've got it wrong. Use the right login name, as per the instructions on the site:

Once setup is done, you can login with SSH into Ubuntu Core, from a machine on the same network, using the following command:

ssh <Ubuntu SSO user name>@<device IP address>

The account has no password and you cannot do a password login, only a key login. So you'll need to use the key you uploaded to ubuntu.com.

If you're not familiar with how SSH keys work, there are about a zillion tutorials all over the Internet (none particularly good), including this short one and this longer one. You'll probably want to learn how to use ssh-agent for convenience, but if that seems too intimidating you can start just by making sure that the ssh client can find the file with your private key, specified with the -i option if all else fails.

Check which public keys were actually installed by going to the Ubuntu One SSH Keys settings. That will list the public key(s) you've uploaded; you need to find the corresponding private key file and use that. If you haven't uploaded any public keys I'm surprised that the install procedure didn't complain about this, but you can just go through the key creation process from one of the tutorials above, upload the public key, and then re-install. Instructions for creating and uploading your public key were also given at the start of the installation instructions.

Answer 4

If you've generated an SSH keypair with PuttyGen, the public key you can copy from the PuttyGen screen is in the correct format to use for this. The key comment field (which is at the end of the key in the text box) can be changed to anything you like as it's ignored by SSH. I suggest you use include the date and where or why you generated the key in order to make it easier to track what keys you've used where.

Double-clicking on the .ppk file for a previously generated key will not load PuttyGen, it will instead load the key into PAgent. To view or convert the key again after generation you need to click "Start" and type "puttygen" to find the program, click on it to start it, and then use File / Load public key to load it.

The .ppk private key file format used by Putty is not readable by OpenSSH, the SSH client usually used on Linux systems. To save a copy in a format that OpenSSH can read, click the Conversions menu and choose one of the Export OpenSSH key options. It doesn't generally matter whether you use the old or new OpenSSH format; all modern Linux systems can read both.

Once you have the private key in a format that OpenSSH can read, you can copy it to your Linux system. There are several default locations that ssh will try to read; ~/.ssh/id_rsa is the most common of these. However, you can use a file from any location by specifying it with -i, e.g., ssh -i path/to/private/key.

However, it's usually easier to use ssh-agent. There are detailed instructions all over the web for this, but the short summary is

ssh-agent -l      # Check if one is already running.
eval `ssh-agent`  # Only if not already running.
ssh-add path/to/private/key

One last note: please ensure you use a strong password on any SSH private keys. Remember, anybody who gets that file has access to system on which you've installed your public key!

Answer 5

Specifying the identity file at the command line fixed this issue for me:

ssh -i /path/to/private_pikey [email protected]

Answer 6

The fix for me was to open the key file with Pageant and have Pageant open in the background.

1. Open the Pageant program (comes with Putty) click on the minimized Pageant icon, and pick "View Keys", pick your key file, write the password, so Pageant "knows" where the private key is. Before I did this it did not even know where the key file was.

2. Connecting with ssh xxx@ip

3. Then Pageant popped up asking me I wanted to log in with my encrypted private key? I wrote the password to the encrypted private key and Bam Pageant entered what was needed to log in and I was in.