One possible solution to remove persistent keys from ssh-agent (or gpg-agent). Worked for me!

Very nice dropbear setup explanation, including key transferral and hardening.

Two remarks:

You can add your key to ~/.ssh/authorized_keys for individual users as usual with openssh - perhaps this is a thing only for newer dropbear versions? The given path would then be for root/system-wide access.

In order to disable password auth for systems that do not have uci, you can add -s as startup parameter, e.g. through editing /etc/default/dropbear field (though probably a better file than in 'default'). see here

Don't forget to restart after operations /etc/init.d/dropbear restart (though it will just invoke systemctl on systemd devices)

Sish is a great ngrok alternative to expose any locally hosted app over the web. With Sish you create temporary secure tunnels to locally hosted applications and allow others to intereact with the app with a publicly accessible web address. Its great to quickly expose a development app server without needing to deploy it and setup reverse proxies or mess around with firewalls. Sish can also be used to expose any TCP connection - e.g MySQL DB.

Connecting ipad to raspberry (over usb vnc, so latency should be minimal) to enable a linux desktop experience (ssh or vnc).

Then connect a keyboard and you should be off to the races.

linux - Integration of afuse user-level automounter with sshfs as a systemd service spawned from login for local users - Unix & Linux Stack Exchange

Ends up creating a folder on the home directory which automatically creates virtual directories, e.g. if you ls to folder/user@server.com it will ssh to the respective server and mount it. Only works with key-based authorization (afaik) and you need to have the server mounted or connected at least once before to add it to known hosts (or disabled known hosts, but I don't recommend that).

I am having some troubles with it (stuck shell on opening a new terminal) which I believe is due to the service type being forking but sshfs/ssh not quite forking into the background.
A simple systemd mount unit (with systemd-automount) also works well.

Exhaustive list, with pros and cons, of access to nextcloud files.

Includes a little 'push' function to send stuff directly to your nextcloud folders which could be adapted to different use cases.

Not mentioned: S3 primary storage on Nextcloud

lsync can act as a repeatable rsync replacement. Under the hood it utilizes rsync (though there is an advanced rsyncssh integration available which does not re-transfer files over rsync that already exist on the target machine).

Ideal for local-remote scenarios, where changes occur on one machine and should be replicated on another (e.g. mirroring project directory and code changes, automatically pushing them to remote development environment for compilation/testing/building)

DigitalOcean guide here

Setting up dropbear, especially to only take public ssh keys instead of password authentication.

Dropbear does not support ED25519 keys. It will simply ignore them in the keyfile.

Here's a quick guide on How to Set Up Multi-Factor Authentication for SSH on Ubuntu 20.04. Click here for a step-by-step guide.

Type ~. (i.e. tilde, period) at the beginning of a line. In other words, press Enter, then ~, then .. (In some languages, you may need to press Shift or Alt to enter the ~ character.)

Generate a GPG key-pair, and convert it to an SSH key for authentication with your Linode.

A chat bot that can manage your team's SSH accounts - keybase

• Keyxchange/Keys/Ciphers/CipherAuthorizations -- which to choose and which to lose (carefult to not lock yourself out)
• 2Factor Authentication for SSH setup (through an app like GoogleAuth or Aegis)
• Bastion Host automation (automatically making a 'jump' through a required firewall in-between to your destination host)
  "If you're doing 16 hops in-between, sending a single byte of data will cost you about 200MB of data sending" ??
• Client Hardening (closes 2 2016 CVES, fixed in OpenSSH 6.1p-2)
  • turn of UseRoaming * in client (i.e. ssh config)
• Debugging SSH
  • ping first -- maybe the network connection just does not work? ;)
  • ssh -v <host> or -vv or -vvv - verbose connection descriptions as they happen
  • are your options sticking, do they have the right order? ssh -G <host> -- see which options apply to the connectionon
• Legacy systems (solaris, iris, hpux, nextstep, ...)
  • make a separate ssh/config entry for your specific legacy boxes, setting the options
  • nice way to 'add' to usual options, just do e.g. KexAlgorithms +diffie-hellman-group1-sha1 in the config

The SSH configuration influences the security of your Linux system. This guide helps you to secure your OpenSSH server and client configuration.

Trap bots in an endless loop -- but you have to run ssh on a different port to your usual

Adding two factor authentication to your ssh server.

Fixing connection issues for blog automatic deployment

Problems:

• ssh will say publickey denied (even though it is the correct public key)
• Server will close the ssh connection on port 22 apparently without any errors
• User is potentially locked out of their account (if trying to use another account than main ssh connection)

Possible fixes:

• Check the keys first of all, are they in the corrent places on the server (authorized_keys) for the correct login account, with the correct permissions (u+rw, go-rwx for private, u+rw, go+r for public key)

• logging into the correct ip, with the correct user (-l username) and identityfile? (-i file)

• check the client log (ssh -vv or -vvv) and server logs (often sudo cat /var/log/auth.log) for error messages (see checking sshd logs )

• are the errors concerning kex algorithms? -> setting kex/cipher , enable legacy diffie-hellman

• errors concerning a locked account? -> unlocking account for public ssh key access

problems seem to be mainly created by server hardening through e.g. dev-sec hardening role