0

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 pi-user@192.168.XX.XX

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 pi-user@192.168.XX.XX 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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,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: curve25519-sha256@libssh.org,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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,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: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
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
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
pi-user@192.168.XX.XX'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.

  • also check the file permissions on your Key files, cant remember off top of my head what they should be, but I know SSH server under ubuntu is very particular about them being accessible only by the user to which they belong. – shawty Apr 21 '17 at 22:22
  • @shawty The device seems to remain the SSH Login screen and doesn't seem to allow me to access it locally. How do I get to the console on the local pi so that I can actually check file permissions? – nu everest Apr 22 '17 at 23:00
  • You probably can't; even if they did give you a login screen, the account it sets up has no password (not an empty password, but no password available at all) so you wouldn't be able to log in on the console. – Curt J. Sampson Apr 23 '17 at 2:12
  • Ok, so I just had a read of that page you linked too, and all I can say is WHY UBUNTU, WHY? just why do you have to make it so complicated. There's no reason to force someone to log in remotely using SSH on a device they have in front of them. @nueverest do yourself a BIG favor. Go here: raspberrypi.org/downloads and grab Raspbian (It's a debian distro just like Ubuntu), then go here (If your using windows) raspberrypi.org/documentation/installation/installing-images/… to learn how to put Raspbian on your SD card. Then.... – shawty Apr 23 '17 at 12:43
  • , hook up a keyboard, monitor and mouse and boot your Pi, default name is "pi" default password is "raspberry". There is absolutely NO REASON why Ubuntu should A) be forcing you to create a password in their online service (Unless they own the Pi your logging into) and b) NO reason why you can't just use your Keyboard, Mouse and monitor locally if you have the device on the desk in front of you. As a long time user of Ubuntu I'm shocked that they choose to take this approach to trying to control how you use your Raspberry Pi. – shawty Apr 23 '17 at 12:46
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."

  • 1
    1. There is no ssh-key program; you mean ssh-keygen. 2. The "name" at the end of the public key is just a comment and has no effect on its usage. 3.The ssh client needs to read the private key, not the public key. 4. Ssh looks for the private key in in /.ssh/id_rsa and some other places, but, as I mentioned in my other post, you can use the -i option to load it from anywhere, or you can load it into an agent for more convenient use. 6. Your problem was almost certainly what you didn't mention: your Putty-generated private key was in .ppk format. – Curt J. Sampson Apr 23 '17 at 1:44
0

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
pi-user@192.168.XX.XX's password:

The instructions state:

This device is registered to . 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.

  • I sanitized the login name to pi-user for security purposes to post this question on the site. I am using my actual ubuntu one username for ssh, and it matches the screen I see on the Pi. – nu everest Apr 22 '17 at 22:52
  • Ok. It wasn't at all obvious clear, since you didn't say you were doing sanitization until several paragraphs later, that looked as if it applied only to the pasted debug output, and you sanitized with XX or XYZ there. – Curt J. Sampson Apr 23 '17 at 1:38
0

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!

0

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

-1

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

ssh -i /path/to/private_pikey user@x.x.x.x
  • We're looking for long answers that provide some explanation and context. Don't just give a two-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed or you risk to get down votes. And please take the short Tour and visit the Help Center to get an idea how things work here. – Ingo Feb 21 at 12:57

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.