Headless install - Sarpi - Pi 2 B - SSH Connection Refused
 

Trying to run a headless install on my Pi with the latest Sarpi image (monitor, keyboard, mouse to do a regular install isn't an option for the time being), but I can't get it to allow me to establish an ssh connection; all attempts are met with a "Connection refused on port 22" error.

I've checked several times, using all combinations of IP, hostname, root, and no username, but the response is always the same. I verified that the router has granted a dhcp lease to the Pi (reports a hostname of slackware.lan) and has no active firewall rules.

I get ICMP replies without any trouble, tcpdump shows my SYN being met with an immediate RST, and nmap reports no open ports found on the Pi. The physical layer is about as simple as I can get without doing a direct NIC to NIC connection between the client and the host:

Router
WAN port - Not connected to any device
LAN port 1 - client
LAN port 2 - Pi
Address assignment: DHCP

Both devices are assigned addresses on the same /16, no traffic delivery problems seen on client or router.

Given all of this, I suspected that there's something going on with the Pi that's causing sshd to not run, and confirmed multiple times that the required changes are present and there's no additional whitespace or linebreaks in the cmdline.txt configuration (as per the information detailed in the "Notes for Pre-installation" page on the Sarpi project site). I saw the Raspbian folks need an empty file named 'ssh' in the root directory for their headless install procedure; adding this had no effect on the behavior.

I'm pretty much stumped here, I gotta say. The only thing I haven't tried is a NIC to NIC setup, eliminating the router from the equation. I've not done that, though, since there's no indication (that I see, at least) of this being a problem at the network layer. All the symptoms point to there being no ssh server running on the Pi, but I'm not familiar enough with how these images work to gain any direct insight without either a remote session, or peripherals I don't have access to.

Any of y'all got any suggestions on where I could go from here?

Have you sshd running and the default /etc/ssh files? Do you need to generate keys? You might do if you did some kind of incomplete inatall

If you plug in a keyboard, & monitor, can you talk the other way?

The installer uses Dropbear and generates its own key at boot.

I am not familiar with how SARpi is configured to boot the installer, but to configure the installer to bring up networking and SSH you need this in the APPEND line to set the Kernel cmdline values:

Dropbear will start its SSH server but *only* if the network interface has an IP address.
I've seen it in the past where it took several seconds to obtain an IP via DHCP, so the dhcp client backgrounded the IP solicitation task whilst the OS continued to boot. When the dropbear loader runs, it didn't detect an IP and subsequently did not start the SSH server. The IP was eventually assigned to the interface but it was too late.
If you already have that nic= setting above, it may be that you're running into the situation I just described. If not, you'll need a serial cable or monitor and kb, or hack the installer to make it start dropbear regardless.

I have had problems recently logging onto a freshly installed slackware. It was due to ssh authorisation being set to PAM.
edit /etc/ssh/sshd_config and change UsePAM to no.

It might be that because connection refused is a result of you connecting and not being authorised.

Dunc.

Excellent point! I hadn't considered that at all. I'll edit the text file and the router's config here in a sec and see if taking DHCP out of the mix has any effect on things. Here's hoping!

Very good info for me to keep in mind, though I'm not sure I'm encountering that situation quite yet, because it appears as though the port isn't even open at all (per nmap and initial SYN packets being immediately met with a RST). It looks as though the server side isn't even reaching the point where it evaluates the login info, as it's just resetting any connection attempts it receives and the initial TCP handshake fails to even be completed.

I'll get the DHCP middleman cut out of the mix here and report back with the results shortly. Thanks for the suggestions!

Alright, so a bit of a (non-)update:

Manually setting the IP in cmdline.txt now results in a total lack of response from the Pi, despite the arp table in the router having a correct entry to associate the IP and the Pi's MAC. The Pi's NIC shows the activity led getting triggered each time a packet is sent it's way, but no response comes from it, whether I attempt to ping it, ssh to it, run a portscan on it, whatever.

I went one further and just cut the router out of the mix altogether, used a straight-through cable to connect the pi directly to my laptop's NIC. I got no ARP reply from the Pi at all, entered an entry for it manually, and got the same results as before.

At that point, I cleared out the partition that was created when the image was flashed to the SD card and unzipped the contents of the "boot" zip file to it. I added the static IP settings as before, this time using the exact same address as the example (I had previously set 235 as the value of the last octet), plugged it back into the router after it wouldn't answer my laptop directly, and at that point it finally worked just fine.

In short, it's working, but I'll be danged if I can tell you why it wasn't before. . . Thanks for trying to take a crack at this, y'all. Sorry I couldn't come back with some closure here, but at least it's working!

Get the RazPi to a monitor and keyboard and do the sensible basics. Are you using network manager or init scripts? What's the Distro? Do you need spoonfeeding or do you know what you're doing?

I'm pretty sure all those questions were answered over the course of this thread, if not in my initial post. As I had said in the beginning of the thread, peripheral attachment was not an option due to lack of physical devices. The problem wasn't that I needed help figuring out how to do an installation; the problem was that an installation method SARPi supports should have been working, but was not, and I was trying to identify the root cause of the behavior.

Regardless, the point is moot, as my previous post confirmed the issue has been cleared, and the title of the thread updated accordingly. While I appreciate the offer, spoon-feeding does not appear to be necessary.

Good info Stu. I pretty much covered it on this page (and elsewhere in the installer guide) : https://sarpi.penthux.net/index.php?p=preinstall