C:\Users\PaulM>ssh pi@proxy55.rt3.io -p 32481
kex_exchange_identification: Connection closed by remote host
Connection closed by 3.67.0.82 port 32481
When doing sudo apt-get upgrade on new Raspberry Pi 5
RemoteIt wont work anymore!
Please check.
use -v -v -v on the ssh connect ssh
ssh -v -v -v -v pi@proxy55.rt3.io -p 32481
make sure the firewall rules didn’t change, make sure when on the PI you can still ssh to localhost IE ssh pi@127.0.0.1
My thought is maybe they have blocked localhost access for some reason, Not sure which OS are you using also.
Also make sure SSHD is running, maybe it didnt restart after upgrdae.
Not enough information to know.
If you are using the Raspberry Pi Imager and a standard Raspberry Pi OS, SSH is not turned on by default. This would require you to be on the same LAN as the RPi and to know the LAN IP of the RPi OR to have a monitor and keyboard connected to the RPi.
This is their current instructions https://www.raspberrypi.com/documentation/computers/remote-access.html#ssh
We have two Raspberry Pi devices running on a local network. There is no firewall issue, and we have already reproduced the problem. When running:
sudo apt get upgrade
SSH, VNC, etc., all get blocked, and the Pi is no longer reachable, even using the local IP. It seems to be a permission issue or something similar.
The other Pi5, where we did no upgrade, is totally fine.
So looking at that debug the SSHD service is not returning a banner, so it looks SSHD is wedged. Is that pi available on the local network or from another device? I do not think this is a remote.it problem.
I do not believe it will be accessible even on the local lan
Probably not remoteit problem, maybe caused bei CI/CD of raspberry (for Pi5). Its for sure related to the upgrade command and you can easily reproduce yourself. I see also no solution to this, I will close the thread.
Thanks for trying.
Ok its defintely related to RemoteIt.
I have two Raspberry Pi devices on my local network, both connected to Remote.it. One device shows a key exchange error (kex) when trying to SSH, while the other is reachable. However, rebooting the reachable Pi also reboots the Pi with the kex error. It seems the identification or connection setup with Remote.it is causing conflicts between the devices.
Did you try to SSH to the unreachable device while on the LAN using its LAN address and not using a Remote.It connection?
Remote.It doesn’t touch the SSH service or the listening local port.
he error ssh_exchange_identification: connection closed by host occurs when the SSH connection is abruptly terminated by the remote host. This issue can arise from various causes. Here are some common ones:
- IP Blacklisting: Your IP address might be blacklisted or blocked by the remote host due to previous failed login attempts or security policies.
- SSH Daemon Configuration: There may be issues or restrictions configured in the SSH daemon (
sshd_config) on the server. This could include limitations on the number of simultaneous connections or specific rules that disallow your connection. - Host-Based Access Control: The server might be using TCP Wrappers (
/etc/hosts.allowand/etc/hosts.deny) to control access, and your IP address might not be allowed. - Firewall Rules: Firewalls or security groups on the server might be configured to drop your SSH connection. This could be at the server level or network level.
- Resource Limitations: The server might be experiencing resource constraints (like high load or insufficient memory), causing it to refuse new connections.
- Misconfigured Network: Network issues, such as misconfigured network interfaces, routing issues, or DNS problems, might prevent successful SSH connections.
- Corrupt or Missing SSH Keys: If the server expects SSH key-based authentication and the keys are missing, corrupt, or improperly configured, it may close the connection.
- MaxStartups Setting: The
MaxStartupssetting insshd_configmight be set too low, limiting the number of concurrent unauthenticated SSH connections.
To troubleshoot and resolve this issue:
- Check Server Logs: Examine the SSH server logs (
/var/log/auth.logor/var/log/secure) for detailed error messages. - Review Firewall and Security Group Rules: Ensure that your IP address is allowed to connect to the server.
- Verify SSH Configuration: Review the server’s SSH daemon configuration file (
/etc/ssh/sshd_config) for any restrictive settings. - Check Host-Based Access Controls: Ensure that your IP address is allowed in
/etc/hosts.allowand not denied in/etc/hosts.deny. - Restart SSH Service: Restart the SSH service on the server to apply any configuration changes (
sudo systemctl restart sshdorsudo service ssh restart). - Monitor Server Resources: Check the server’s resource usage (CPU, memory) and ensure it has enough resources to handle new connections.
- Verify Network Configuration: Ensure that network interfaces and DNS settings are correctly configured.
- Update SSH Client: Make sure your SSH client is up to date and correctly configured.
By systematically checking these areas, you should be able to identify and resolve the cause
When installing Remote.it on two Raspberry Pi 5s on the same local network, I can reboot both Pis by rebooting just one of them. This behavior is unusual and seems to indicate a problem with the network configuration or identification within Remote.it.
Are you rebooting the Pi locally or via a Remote.It connection? Did you clone your SD card?
It should not be possible to reboot both pis with a single reboot command issued directly to a Pi.
Can you please give exact details on how you are connecting to the Pi to reboot it and the command you are issuing?
Hi,
It appears that the issue is related to the new Raspberry Connect (Beta) Service. It seems there is an interference between Remote.It and Raspberry Connect.
https://connect.raspberrypi.com/
We are still investigating the exact cause of this interference.
Where can I find log files from remoteit service?
The logs for the remoteit daemon would be found in the syslog.
If you’re encountering the kex_exchange_identification error when trying to connect to a Raspberry Pi 5, it usually indicates an issue with the SSH connection. Here are some steps to troubleshoot and resolve the problem:
- Check Network Connection:
Ensure that your Raspberry Pi and the device you’re connecting from are on the same network and can communicate with each other.
- Ping the Raspberry Pi: Use
ping [Raspberry Pi IP address]from your PC to check if the Pi is reachable.
- Verify SSH Service:
Make sure the SSH service is running on your Raspberry Pi.
- Enable SSH:
- Connect a monitor and keyboard to your Raspberry Pi.
- Open a terminal and run
sudo raspi-config. - Navigate to
Interfacing Options>SSHand enable -
- Check for SSH Configuration Issues:
Ensure the SSH configuration on your Raspberry Pi is correct.
- Edit SSH Config:
- Open the SSH configuration file:
sudo nano /etc/ssh/sshd_config. - Ensure the following lines are present and not commented out:
- Open the SSH configuration file:
bash
Copy code
PermitRootLogin yes
PasswordAuthentication yes
- Save and exit the file, then restart the SSH service:
sudo systemctl restart ssh.
- Check for Firewall or Security Software:
Make sure no firewall or security software is blocking the connection.
- Raspberry Pi:
- Check if
ufw(Uncomplicated Firewall) is active and properly configured:sudo ufw status.
- Check if
- PC:
- Ensure that any firewall or security software allows SSH connections.
- Verify SSH Key Configuration:
If you’re using SSH keys, ensure they are correctly configured.
- Generate SSH Key (if needed):
ssh-keygen -t rsa -b 4096 -C "your_email@example.com" - Copy SSH Key to Raspberry Pi:
ssh-copy-id pi@[Raspberry Pi IP address]
- Update and Upgrade Raspberry Pi:
Ensure your Raspberry Pi is up to date.
- Update and Upgrade:
- Run
sudo apt updateandsudo apt upgradeto update and upgrade the system packages.
- Run
- Check SSH Logs:
Review the SSH logs for more detailed error messages.
- SSH Logs:
- Access the SSH logs:
sudo journalctl -u sshor check the log file:sudo nano /var/log/auth.log
- Access the SSH logs:
- Restart Raspberry Pi:
Sometimes a simple restart can resolve connectivity issues.
- Restart:
- Run
sudo rebootto restart your Raspberry Pi.
- Run
Example Troubleshooting Commands:
- Ping Test:
sh
Copy code
ping [Raspberry Pi IP address]
- Check SSH Service Status:
sh
Copy code
sudo systemctl status ssh
- Restart SSH Service:
sh
Copy code
sudo systemctl restart ssh
- Check SSH Logs:
sh
Copy code
sudo journalctl -u ssh
If these steps do not resolve the issue, you might need to provide more specific details about your setup and the exact error messages you’re encountering. This can help in diagnosing the problem more accurately.
4o
@Ba1ancer can you try using the connection again without any changes? Do not stop it, just re-launch it? It is possible that we got a not available and stop trying.
One of the Raspberry Pis where we previously encountered a KEX (Key Exchange) error has suddenly come back online.
We are now able to SSH into it and have attempted to determine what happened by checking the log files.
Could you please provide more specific guidance on which log files to check and where they are located to help us understand what might have caused the issue?
