[SOLVED] Pi3b: ssh connection refused

Geremia · 12-29-2023, 05:44 PM

SARPi Project - Slackware ARM on a Raspberry Pi, Notes for Pre-installation needs to be updated to note that, as the Raspberry documentation says:

Quote:

For headless setup, SSH can be enabled by placing a file named ssh, without any extension, onto the boot partition of the SD Card. When the Raspberry Pi boots, it looks for the ssh file. If it is found, SSH is enabled and the file is deleted. The content of the file does not matter; it could contain text, or nothing at all.

Geremia · 12-29-2023, 06:00 PM

Hmm… I'm still getting

Code:

ssh: connect to host 192.168.1.118 port 22: Connection refused

even with the ssh file.

I think I might need to create userconf.txt.

Geremia · 12-29-2023, 06:10 PM

Even with that, I'm getting "connection refused". I've even tried static IP address, too.

It's not stuck at the rainbow screen; it shows the console on the monitor I connected to HDMI, but I still can't SSH to it.
The ethernet lights flash, and the router DHCP is assigning it an IP address.

I'm using a Raspberry Pi 3b with sarpi3_64-installer_slackcurrent_22Dec23_sp1.img.xz

Exaga · 12-30-2023, 09:37 AM

Quote:

Originally Posted by Geremia

SARPi Project - Slackware ARM on a Raspberry Pi, Notes for Pre-installation needs to be updated to note that, as the Raspberry documentation says:

There is a 'How To install Slackware ARM on a Raspberry Pi' tutorial available if you're having any difficulties installing using the SARPi software. Raspberry Pi OS works that way with a file named 'ssh' in the /boot directory, but not Slackware Linux. They are two completely different and seperate operating systems.

I think the most helpful part of the SARPi installation tutorial for you right now might be: https://sarpi.penthux.net/index.php?p=preinstall

Quote:

In the event that you do not have a screen/monitor/tv to connect to your Raspberry Pi, it's possible to boot the Slackware ARM installer with networking enabled and a specified keyboard layout (locale) in order to login and perform the installation remotely via ssh (i.e. from another computer). It's just a matter of editing the 'cmdline.txt' file on the boot partition of the microSD card (see this example) before you boot your Raspberry Pi with it. So, if you wanted to perform a remote installation, you would insert the following code into the cmdline.txt file:

kbd=us nic=auto:eth0:dhcp

Alternatively, if your network does not have DHCP enabled you should specify an IP address and netmask. In this example the IP address is 192.168.1.100 and the netmask is 255.255.255.0 (24-bit netmask):

kbd=us nic=auto:eth0:static:192.168.1.100:24

Of course, you should specify your own IP address, netmask, and keyboard layout here. See this keymaps list for supported keyboard layouts and select one which suits your own keyboard configuration (e.g. kbd=es , kbd=fr , kbd=de , kbd=it , kbd=ru , etc.). So, when you boot the Slackware ARM installer on the Raspberry Pi you will not be required to enter a keyboard map and networking will already be configured. You can simply login remotely via ssh as 'root' user and just hit the ENTER key when asked for a password. If you're installing Slackware ARM remotely then some parts of this tutorial may not apply to you, so you'll have to work around those areas. ;-)

To boot the Slackware ARM installer normally, with a US keyboard layout, just leave the cmdline.txt file unmodified.

Example cmdline.txt file for reference: https://slackware.uk/sarpi/extra/cmdline.txt

Exaga · 12-30-2023, 12:05 PM

Quote:

Originally Posted by Geremia

Even with that, I'm getting "connection refused". I've even tried static IP address, too.

It's not stuck at the rainbow screen; it shows the console on the monitor I connected to HDMI, but I still can't SSH to it.
The ethernet lights flash, and the router DHCP is assigning it an IP address.

I'm using a Raspberry Pi 3b with sarpi3_64-installer_slackcurrent_22Dec23_sp1.img.xz

"Connection refused" usually means you've used a valid IP address but port 22 isn't ready to accept connections. I've found that this happens often if I try to login before sshd has initialised fully.

Geremia · 12-30-2023, 06:20 PM

Here's the debug output:

Code:

$ ssh -vvv root@192.168.1.118
OpenSSH_9.6p1, OpenSSL 3.2.0 23 Nov 2023
debug1: Reading configuration data /home/Geremia/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 192.168.1.118 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/Geremia/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/Geremia/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.118 [192.168.1.118] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: connect to address 192.168.1.118 port 22: Connection refused
ssh: connect to host 192.168.1.118 port 22: Connection refused

Exaga · 12-31-2023, 12:10 AM

Quote:

Originally Posted by Geremia

Here's the debug output:

That's very strange.

The error output mentions the system you’re connecting from with regards to: '~/.ssh/known_hosts' -> '/home/Geremia/.ssh/known_hosts && '~/.ssh/known_hosts2' -> '/home/Geremia/.ssh/known_hosts2 - I would delete those keys and try to login again.

Code:

debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling

I would ignore the above output. Even I see this on a system that's working 100% as expected.

Something on the system you're trying to connect from may be causing the issue. The type of authentication being used, for example.

There has been quite a number of changes and updates to how OpenSSH works in recent times. The Release Notes offer further insight:

Quote:

OpenSSH 9.6 was released on 2023-12-18. - https://www.openssh.com/releasenotes.html

OpenSSH 9.6 now bans most shell metacharacters from user and hostnames supplied
via the command-line. This countermeasure is not guaranteed to be
effective in all situations, as it is infeasible for ssh(1) to
universally filter shell metacharacters potentially relevant to
user-supplied commands.

ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
They will now use DSCP AF21 for interactive traffic and CS1 for
bulk. For a detailed rationale, please see the commit message:
https://cvsweb.openbsd.org/src/usr.b...onf.c#rev1.284

Code:

root@iana:~# slackpkg search openssh
[ installed ] - openssh-9.6p1-aarch64-1

root@iana:~# ssh -v localhost
OpenSSH_9.6p1, OpenSSL 3.2.0 23 Nov 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_9.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6
debug1: compat_banner: match: OpenSSH_9.6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:22 as 'root'
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
(root@localhost) Password:
Authenticated to localhost ([::1]:22) using "keyboard-interactive".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: pledge: fork
Last login: Sun Dec 31 07:37:35 2023 from 192.168.10.24

root@iana:~# w
 08:39:50 up  2:58,  2 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    192.168.10.24    07:37    3.00s  0.18s  0.17s ssh -v localhost
root     pts/1    ::1              08:33    3.00s  0.01s  0.00s w

root@iana:~# exit
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
logout
debug1: channel 0: free: client-session, nchannels 1
Connection to localhost closed.
Transferred: sent 32440, received 34784 bytes, in 447.6 seconds
Bytes per second: sent 72.5, received 77.7
debug1: Exit status 0

Google indicates such issues as yours might be related to how your router manages Quality of Service [QoS]. To check if it's the case, add the the option '-o IPQoS=none' to your SSH connection request:

Code:

ssh -o IPQoS=none -vvv root@192.168.1.118

Do you have any fail2ban or other firewall or iptables rules that only allows connections from a specific range of IP addresses, by any chance?

Have you tried connecting to the Pi using a different system, other than the one which produces this error?

I'm clutching at straws with this one. Really don't know what could be causing your SSH issue(s).

drmozes · 12-31-2023, 10:08 AM

Quote:

Originally Posted by Exaga

There has been quite a number of changes and updates to how OpenSSH works in recent times. The Release Notes offer further insight:

I'm uncertain about SARPi's alterations to Slackware, but the official Slackware Installer opts for Dropbear instead of OpenSSH. Dropbear fails to initiate if the network interface is notactive at the time of its invocation. There's no built-in mechanism for reattempting the execution, therefore any significant (probably <10 seconds) delay in the network interface activation will cause it not to start.

One workaround is to access the console directly via your monitor and keyboard. From there, you can manually start Dropbear:

Code:

/etc/rc.d/rc.dropbear start

By default, the Installer doesn't have a root password (simply press ENTER when prompted by the SSH client). However, if you've set a root password as a Kernel parameter ('instrootpw=yourpassword'), that will be required instead.

Exaga · 12-31-2023, 10:16 AM

Quote:

Originally Posted by drmozes

I'm uncertain about SARPi's alterations to Slackware, but the official Slackware Installer opts for Dropbear instead of OpenSSH. Dropbear fails to initiate if the network interface is notactive at the time of its invocation. There's no built-in mechanism for reattempting the execution, therefore any significant (probably <10 seconds) delay in the network interface activation will cause it not to start.

One workaround is to access the console directly via your monitor and keyboard. From there, you can manually start Dropbear:

Code:

/etc/rc.d/rc.dropbear start

By default, the Installer doesn't have a root password (simply press ENTER when prompted by the SSH client). However, if you've set a root password as a Kernel parameter ('instrootpw=yourpassword'), that will be required instead.

Good to know Stu. I haven't made any alterations to the old initrd - just added a README which is a cut down text version of the installer guide.

Not had any issues with SSH login myself, and the dropbear method you've highlighted is included on https://sarpi.penthux.net/index.php?p=setupnic for those that might want to use it.

Thanks for this info. Hope it helps Geremia locate whatever is causing the problem.

[EDIT] on second thoughts if he's trying to install Slackware AArch64 users should be installing from the official documentation and software in any event. SARPi is just for playing around with.

mralk3 · 01-01-2024, 03:29 PM

The raspberry pi 3 had difficulty loading the installer for Slackware Aarch64. With 1GB of RAM you will have a difficulty booting up to a shell. Not enough memory and the installer loads everything into memory.

My solution has been to use the mini rootfs and to unpack the filesystem to a formatted SD card. You will be able to boot if you unpack the kernel packages to a boot partition and the mini rootfs to a root partition. Definitely include a swap partition as well.

You can easily put /boot on the SD card and the root (/) partition on a external usb hard drive or SSD. I always put a swap partition on my root disk rather than the SD card.

I haven't tested this hardware model for several months, YMMV. Let us know if you successfully install on the Pi 3b.

mralk3 · 01-01-2024, 03:37 PM

I forgot to mention that I was referring to the Slackware Aarch64 installer image.

I have no idea if sarpi has the same issue. Most likely sarpi uses less memory because it supports drivers in kernel or as modules just for the raspberry pi 3.

Exaga · 01-01-2024, 11:57 PM

Quote:

Originally Posted by mralk3

I forgot to mention that I was referring to the Slackware Aarch64 installer image.

I have no idea if sarpi has the same issue. Most likely sarpi uses less memory because it supports drivers in kernel or as modules just for the raspberry pi 3.

I'm going to guess that Geremia gave up on wasting time with SARPi and used the official installer, as it should be. That or the issues were resolved. Either way it would be nice to have some feedback eventually in order that other users with the same or similar issues may benefit from other people's experiences.

Geremia · 01-02-2024, 03:16 PM

Quote:

Originally Posted by Exaga

Code:

ssh -o IPQoS=none -vvv root@192.168.1.118

I deleted known_hosts and tried your command here, but I get the same "Connection refused" issue.
I'm using a DD-WRT router.

Geremia · 01-02-2024, 03:20 PM

Quote:

Originally Posted by drmozes

One workaround is to access the console directly via your monitor and keyboard.

I've installed Slackware on it, using an external keyboard and monitor. It boots fine, rc.sshd has the executable bit set, but it's not starting SSH for some reason.

Geremia · 01-02-2024, 03:46 PM

Quote:

Originally Posted by drmozes

One workaround is to access the console directly via your monitor and keyboard. From there, you can manually start Dropbear:

Code:

/etc/rc.d/rc.dropbear start

Thank you. That worked. It generated the SSH keys, etc.

I don't know why that didn't auto-run. The execute bit is set:

Code:

-rwxr-xr-x 1 root root 1776 Dec 22  2023 /etc/rc.d/rc.dropbear*

Update: I think I have an installation problem. It doesn't seem to be booting off the Linux partition I installed to… I didn't follow the configboot instructions 🤦 (It's been years since I last installed Sarpi.)

Now the boot process hangs at SMSC95xx ethernet. ☹