(Solved) SSH+SCP server/client for Slacko 5.4... please

[Walter Dnes]

I went through something similar with Lucid Puppy, but the custom pet that solved the problem there doesn't work on Slacko 5.4. I hope this doesn't come off sounding like a rant...

• Tried ssh'ing in from Gentoo desktop to Slacko notebook
• No connection at all
• Investigation shows there is no ssh/sshd binary... period. There's a /etc/init.d/sshd file, but no sshd binary
• Searching for SSH in package manager turned up 3 packages, of which 2 are allegedly already installed
• So I installed openssh_srv-6.1-i486 (the one that wasn't installed)
• Restarted sshd; that part worked
• ssh'ing from desktop gets "Connection refused"
• "PermiRootLogin yes" is allegedly the default, but I set it explicitly in sshd config
• Restarted sshd and can now log in
• Next step is to copy files via scp
• Look Ma, no scp; I can't copy files to or from the notebook.

Now what? Like the subject says, I need ssh and scp client+server for Slacko 5.4. Note that I searched all Slacko repos, and did not "Trim Fat" when installing.

[rufwoof]

Generally its considered better practice to use ssh keys, which involves ssh-keygen (you run that and it creates a private key in your ~/.ssh folder along with a public key (.pub suffix). Typically a copy of that .pub key is inserted into the ~/.ssh/authorized_keys file under the userid that you ssh into, on the box (sshd server) that you ssh to. The sshd server also needs to be configured to use that (typically by editing /etc/ssh/sshd_config appropriately).

Entering passwords to ssh connect to a remote system can relatively easily be eavesdropped (key logger etc.) so be typing a password in you risk compromising that remote system. Keys better secure the system as a hacker would need to obtain your private ssh key. If however a hacker can eavesdrop, then likely they could also grab your private key ... so what I do is reverse ssh (reverse sshfs mount), from a secure server to my system.

That all aside, Puppy is towards one extreme end of 'OS'. Very modular and cut to the bone. At the other end, OpenBSD for instance, the kernel, command, programs ...etc. are all considered a single entity, the 'base' system. That includes all documentation (man pages) etc. (openbsd consider textual errors in man pages to be equal to any software/code bug). That 'base' system is tested as a whole (security audited etc.). Puppy/Linux in contrast is very modular. Linux is the kernel, on top of which any programs of the developers choice are added. In the case of Puppy much of documentation is stripped out, along with many programs. Standard X11 for instance (X) includes xterm, xclock, xeyes, twm window manager ...etc. most if not all pup's have stripped those out,

So its a case of having to find (or compile) the elements that have been stripped out of your Pup in order to reinstate that functionality. Which in some cases can be a bit of can-of-worms (dependencies/missing libs etc.). Made more difficult by the absence of man pages/documentation. So often a case of repeated try running a command/program from the command line, see what it complains about and addressing those issues (adding something else) .. before trying again - until it seems to be working OK. If you're lucky, then there may be a pet or sfs that can be used (loaded), but the sfs you use might appear to work in some cases, but not be fully compatible - which could introduce security risks. Easier to use a sfs/pet, but in some cases better to compile things for yourself (grab a copy of whatever you need from the likes of github, load your pup's devX sfs, and compile as needed).

From a very cursory glance - perhaps something like https://github.com/openssh/openssh-portable Can't vouch for/against that, just the produce of a very quick search.

[Walter Dnes]

Generally its considered better practice to use ssh keys, which involves ssh-keygen (you run that and it creates a private key in your ~/.ssh folder along with a public key (.pub suffix). Typically a copy of that .pub key is inserted into the ~/.ssh/authorized_keys file under the userid that you ssh into, on the box (sshd server) that you ssh to. The sshd server also needs to be configured to use that (typically by editing /etc/ssh/sshd_config appropriately).

Yes I'm aware of all that, but even Gentoo linux permits root login at the install stage so that I can push id_rsa.pub over to the new install, and move it to .ssh/authorized_keys, after which I again disallow root login

I think I have things under control now. Further searching found "dropbear", weird name for an ssh client-server. After first installing it, ssh attempts got...

Unable to negotiate with legacyhost: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

...as per https://www.openssh.com/legacy.html I've set up .ssh/config on my desktop like so...

Host thimk
KexAlgorithms +diffie-hellman-group1-sha1
User root

After setting /etc/init.d/rc.dropbear executable, I now get dropbear's sshd and can ssh/scp to the notebook.