Can't ssh into RasPi 3 with osmc

I have a RasPi 3 with a freshly installed OSMC. I’d like to use this as a little home server as
well (perhaps with OwnCloud, NextCloud or Cozy) - otherwise I could have
chosen OpenElec. But this way I definitely need shell access.

I installed OSMC 2016.05-1 from the image via Win32DiskImager; after starting the RasPi,
installation went well, including the WiFi connection. After a few
unspectacular adjustments of the media center surface, I wanted to
connect via SSH.

I configured a PuTTY session and tried to connect, using the standard user and password (osmc). However, after being prompted for the password, there is no reaction anymore, and the connection is terminated.

When I enter a wrong password, I’m prompted again; once the password is correct, the connection breaks down.

The ssh client from my Ubuntu 14.04 LTS netbook can’t login, either; after giving the password, nothing happens anymore.

I managed to put some excerpt from the journalctl sshd log to termbin.

journalctl -u sshd didn’t work (the output was empty), so I took the complete output and preserved all sshd lines and a few more.

I first gave a wrong password (20:41:45), then the correct one (20:41:48).

Could the problem hide in the following final lines?

Jun 21 20:41:48 osmc sshd[777]: Starting session: shell on pts/0 for osmc from 192.168.178.26 port 52907
Jun 21 20:41:48 osmc sshd[778]: debug1: Setting controlling tty using TIOCSCTTY.

I tried a question on StackExchange, but no answers so far.

Which special PuTTY session adjustments do I need?

Or is there some bug in the OSMC version 2016.05-1?

Versions:

  • OSMC 2016.05-1
  • PuTTY 0.61, then updated to 0.67

Without ssh access, osmc is of no use for me. I’d need to use 2 RasPis - one for OpenElec, and one for the little home server.

1 Like

So after you press enter when you entered your password really nothing happens? No new line? No text? No blinking cursor?

Is your Raspi connected via Wifi or cable? Maybe there is a problem with your wifi connection…

Could you please run tcpdump on your Ubuntu system, while connecting via SSH to osmc?
Something like

tcpdump -n port 22 and src host 192.168.178.30

This will show if there is any traffic coming from your Pi when successfully authenticated, or if it stops at all.

I have a very similar problem and it turns out it is my router’s firmware. It cannot establish an SSH terminal session wirelessly! The authentication is successful but then nothing happen until it timeouts.

To check, connect your RPi3 with ethernet cable and try to SSH. If it work then it’s exactly my scenario. Check with your router’s provider if they have new firmware update. In my case, I’m using an old 8+ years router and I’m saving to change it.

In the meantime, if you can attach a keyboard directly to your RPi3, you can simply press ESC in the boot time and this will take you to OSMC terminal and you log in with the user account “osmc”.

How long are you waiting before you give up ?

Check your DNS server settings on the Pi. When you log in using SSH a reverse dns lookup is done on the IP address of the connecting client before the login is allowed to complete. If you have a non-working DNS server configured it will hang for a long time waiting for a response.

There is a known bug in OSMC where if you have multiple DNS servers assigned by DHCP, they are used in the reverse order. If your last assigned DNS server is not actually valid or working this may cause you an issue when other devices on the network don’t see an issue.

We’re not aware of any bugs like what you describe affecting ssh in osmc.

By the way you can log into the console on OSMC by booting with the CTRL key held when you first see the blue OSMC splash screen - being able to log in locally and test in the other direction (such as doing dns lookup testing) might help locate the problem.

Well, there is a new line, but no text. The cursor blinks (now that I enabled blinking), but if I type more, there is no echo.

and it turns out it is my router’s firmware.

Unlikely. It is a Fritz!Box 7170, and I have used it for wireless ssh connections to RasPi devices before. I just now verified it works to connect to my RasPi 1B with OpenElec 6.0.3.

To check, connect your RPi3 with ethernet cable and try to SSH.

No luck so far (but it is probably not your scenario anyway). ifconfig tells me about lo and wlan0 only; when I disable wlan0 and enable eth0, I don’t get an IP address. I tried two cables, but, as I said: I think it is another problem anyway.

What does this mean? What exactly did you “configure”? Because I’ve never had to enter anything but the IP and port into PuTTY and never had an issue.

After about 20 seconds, PuTTY tells me “Software caused connection abort”.

Here is my LANG=C ifconfig output: http://termbin.com/fik4; the FritzBox (being the gateway) acts as a DNS server.

I’m afraid that’s not the cause.

I installed dnsutils to have nslookup. My DNS server works fine. A reverse lookup of 192.168.178.1 gives me the gateway, a lookup of 19.168.178.28 my requesting computer.

Well, I simply saved it (hostname, and sometimes a preconfigured user name). It doesn’t make a difference. I tried to suppress the private key which I use for several other systems, but this doesn’t make a difference, either.

How many DNS servers do you have configured, and did you test all of them with nslookup to make sure they all give the same result ? It doesn’t sound like you did.

Try testing a reverse lookup of your connecting client using each DNS server.

Another thing you can try is adding an /etc/hosts entry on the Pi for the hostname and IP address of the connecting client. If this fixes the problem then it is indeed reverse DNS related.

You do not need to Use putty. My main machine is Elementary OS and I gave no problems SSH into the rpi3… Just use terminal to SSH osmc@ip.addrrss.number. I DO have problems trying g to use putty from the Ubuntu based machine.

Connected via WiFi. I never had problems with this before - ssh connection to my Pi 1B works nicely. On this Pi3 I directly installed OSMC (w/o NOOBS), so I didn’t try other systems on it yet. IMO, it is not a WiFi problem but related to sshd binary or setup. DNS is fully functional (see my other reply).

I tried this (little gotcha: without sudo, I got a confusing error message), and tried it without the port spec as well:

0 packets captured
0 packets received by filter
0 packets dropped by kernel

DNS is perfectly fine. There is exactly one DNS server, AFAICS, which is the automatically via DHCP configured Fritz!Box. I double-checked now during troubleshooting - nslookup works fine. I can connect to my RasPi 1B via ssh without any problem.

IMO the problem is not related to PuTTY. Trying to connect using the ssh client of my Ubuntu 14.04 netbook doesn’t work, either.

Exit to command line with keyboard as instructed in the Wiki, then run

sudo -s
DSA_KEY="/etc/ssh/ssh_host_dsa_key"
RSA_KEY="/etc/ssh/ssh_host_rsa_key"      
ECDSA_KEY="/etc/ssh/ssh_host_ecdsa_key"
ED25519_KEY="/etc/ssh/ssh_host_ed25519_key"
rm -f $DSA_KEY
rm -f $RSA_KEY     
rm -f /etc/ssh/*_key*
ssh-keygen -f $DSA_KEY -N '' -t dsa
ssh-keygen -f $RSA_KEY -N '' -t rsa
ssh-keygen -f $ECDSA_KEY -N '' -t ecdsa
ssh-keygen -f $ED25519_KEY -N '' -t ed25519
sudo reboot

You probably unplugged your device unexpectedly during first boot

AFAIK, PuTTY is Windows-only; on Linux, you have the usual ssh client which is installed by default.

An easier way to do this would be to log in at the local console and run:

sudo /usr/bin/ftr

Then reboot.

Yes, but that will also regenerate DBus keys. Won’t hurt – but I would avoid that personally. It will also try and preseed and that data may be stale.

But that is not harmful ? And if indeed the power was unplugged during the initial ftr run, then we can’t trust anything set up by ftr to be working correctly. So best to run it again to be sure.