After automativ update to TurrisOS 5.1.0 the ssh connection is not working.
ssh: connect to host 192.168.1.1 port 22: Connection refused
The luci process does not show any ssh process. Restarting ssh services does not have any effect. Whats goes wrong?
have you looked at the system logs after ssh restart?
there are no ssh related syslog entries. only some of rainbow button script.
even if you restart or stop/start ssh?
yes. there are no messages within the syslog.
I can confirm this bug on Turriss Omnia since update to version 5.1, but in my case it is not related to ssh service only but to firewall. All incomming TCP IPv4 traffic which is enabled in firewall exception is denied even exception. IPv6 TCP connection to same service on same WAN port is OK. Can someone advice how to report this behavior to bugzilla?
@pichlhuber is this Omnia migrated from 3.x? Or was it already shipped with TOS 4.0+ or flashed by medkit? We added migration of SSH config and it might be possible that it executed at your node if you did migration and kept tos3to4 package in your system (that is common mistake as you might have done opkg install instead of required opkg-cl install). In other case I have no idea why ssh is not starting in your case. Do you have serial cable to access shell that way to debug that?
@mino that is for sure some other problem. Are you sure that includes all IPv4 traffic? Is that on LAN side? You should check default policy if that is on LAN side (it should be ACCEPT unless you changed it). In case it is WAN then are you running dynfw-client? Is it possible that you blocked yourself by scanning router or by accessing minipot/honeypot?
Hi all, I have same problem at 2 Omnia boxes on 2 different locations / networks / providers (xDSL and WiFI incomming). Both boxes was TOS 4.0+ HBS initially and slowly (HBS) migrated to TOS 5.1 (updated by my approval). SSHD runs OK, I can reach both boxes by IPv6 on any way (LAN, WAN, openVPN), but IPv4 incomming TCP (eg. ports 22, 80, 443) works only from LAN and openVPN but same connection to WAN is denied. SSHD service works on all interfaces. But same problem is if I try to reach any other IPv4 TCP service on WAN (22, 80, 443).
Its almost default configuration, no network scan (NMAP …) It is running this service:
python3 /usr/bin/sentinel-dynfw-client --ipset turris-sn-dynfw-block
SSHD is listening: 0.0.0.0:22 and *:22
firewall config is:
…
firewall.@zone[1]=zone
firewall.@zone[1].name=‘wan’
firewall.@zone[1].network=‘wan’ ‘wan6’
firewall.@zone[1].input=‘REJECT’
firewall.@zone[1].output=‘ACCEPT’
firewall.@zone[1].forward=‘REJECT’
firewall.@zone[1].masq=‘1’
firewall.@zone[1].mtu_fix=‘1’
firewall.@zone[1].sentinel_dynfw=‘1’
firewall.@zone[1].sentinel_fwlogs=‘1’
firewall.@zone[1].sentinel_minipot=‘1’
firewall.@zone[1].haas_proxy=‘1’
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].src=‘lan’
firewall.@forwarding[0].dest=‘wan’
…
firewall.wan_ssh_turris_rule=rule
firewall.wan_ssh_turris_rule.name=‘wan_ssh_turris_rule’
firewall.wan_ssh_turris_rule.target=‘ACCEPT’
firewall.wan_ssh_turris_rule.dest_port=‘22’
firewall.wan_ssh_turris_rule.proto=‘tcp’
firewall.wan_ssh_turris_rule.src=‘wan’
It was OK until TOS 5.1 update.
My Omnia was shipped (this spring) with firmware 4.x.
This behaviour occur after automatic update from 5.0.x to 5.0.
In my case this issue starts last week since TOS 5.1 upgrade (HBS), it was OK until 5.0. Automatic updates should be approved, yesterday I tried to approve second box and same issue. Omnia was also shipped (last winter) with firmware 4.x.
So this is still an open issue but no fix there?
So my actual workaround is to rollback a pre-update snapshot and deactivate automatic updates until this bug is fixed.