I’m reaching out here in the off chance that someone has had the same problem as I’ve been running into for about a year now. I have a raspberry pi (using the default OS) with an external SSD mounted. My hope is to use this as a general shared drive for my household using SSHFS. I have configured my router to grant the Pi a static local IP address, and we have shared SSH keys. So far so good.
My problem is that after a period of time, the drive won’t mount. Using SSH in terminal I also get the error: “ssh: connect to host 192.168.X.XYZ port 22: No route to host”
I’ve checked the router settings and the Pi is connected using the correct IP address.
So far I’ve resolved the problem by reconnecting the Pi to the wifi router, restarting the Pi and/or restarting the router. All of these steps work. Of note, I have changed wifi routers in the meantime and the problem has persisted so it is clearly not the router that is at fault.
In the off chance that anyone has this problem, would you be able to direct me how to solve it? The “solutions” so far need to be repeated at least once a day.
Yes I’m using raspbian. I can use the Pi just fine when interacting with it using a monitor, keyboard, mouse etc. It is fully connected to the internet via the wifi network and the correct Wlan country has been selected (not sure how this practically matters?). Using an ethernet cable would be impractical given the layout of my home.
The drive is mounted via USB using whatever default configuration raspbian OS provided - I didn’t mess with the defaults. It is mounted at /media/pi/[DRIVE_NAME]. The issue arises when I try to mount the drive over SSHFS to my laptop and other devices on my home network. After a few hours, the SSH connection drops and I cannot SSH into it any more. Meanwhile, the Pi is connected to the network just fine. I disconnect the Pi from the router (using the Pi’s interface) and reconnect it again, and it works just fine - there is no need for a restart or anything like that. Then a few hours later it starts glitching again…
I may be just conflating issues but I experience the same glitching with KDE connect as well, both on Android and IOS. After a few hours I can’t connect to the raspberry pi, even though it is still actively connected to the wifi network…
Every situation is a little different, but here are a couple of things you might want to check.
what specific static address are you giving the RPi ? In my personal experience, I have found an address in the middle to upper range ( the last triad between 175 to 250 ) works best. Some routers prefer / reserve the lower range for DHCP. My router prefers approx 101 to 120 for DHCP addresses with 105 seeming to have special favor with my Linksys router.
in your /etc/fstab make sure the USB SSD is specifically listed with the UUID and not a partition label.
I just remembered, a Dlink router I once had required one to get into the router settings and specify a range of addresses for the router to reserve for static IPs.
Thanks - it seems that I have everything set up correctly. The pool of assignable IP addresses is between 192.168.0.100-200, and I have assigned the Pi a local IP address within that range. It also appears that this is the very same IP address my device is using. That said, I posted here after resetting the network connection so everything is working as it should. I’ll run some more diagnostics tomorrow when everything is not working…
The inevitable happened - I stopped being able to remotely interface with the pi using SSH, VNC Viewer, KDE connect etc. However, I ran the above commands and nothing had changed. The pi was using the same local ip address etc, and was connected to the internet. It’s very strange.
That didn’t work - bear in mind I’m not using EOS on the raspberry pi, just on my laptop. I also did not post here in the expectation of getting EOS technical support, just to know if anyone has had this problem as a lot of people in the community have raspberry pis. I’ve searched high and low on the internet and it seems that a lot of pi users have this problem, but none of the solutions offered work. So this was really a last act of desperation.
The output of the first part of the command is:
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,email@example.com
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# UserKnownHostsFile ~/.ssh/known_hosts.d/%k
SendEnv LANG LC_*
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
# Ciphers and keying
#RekeyLimit default none
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
# Change to yes if you don't trust ~/.ssh/known_hosts for
# Don't read the user's ~/.rhosts and ~/.shosts files
# To disable tunneled clear text passwords, change to no here!
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
# Kerberos options
# GSSAPI options
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# no default banner path
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
IPQoS cs0 cs0