All Questions(server)

I'm trying to configure my Gen 1 Cloud Key (CK) to allow passwordless authentication so I can run a bash script to download autobackup files. I'm able to SSH into the CK "manually" and also with my bash script using username/password, but this would store the credentials in clear text which I (obviously) don't want to do.

I have:

• generated the keys on my local machine (MBP Sequoia 15.1.1) with ssh-keygen -t rsa,
• copied the public key to the CK's ~/.ssh/authorized_keys file,
• modified /etc/ssh/sshd_config to include the following (uncommented) lines: RSAAuthentication yes, PubkeyAuthentication yes, and AuthorizedKeysFile .ssh/authorized_keys,
• restarted ssh on the CK with sudo systemctl restart sshd,
• checked permissions with chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.

But still no joy. SSH log says,

...
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /Users/Hank/.ssh/id_rsa RSA SHA256:KEY_VALUE_REDACTED
debug1: Will attempt key: /Users/Hank/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/Hank/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /Users/Hank/.ssh/id_ed25519 
debug1: Will attempt key: /Users/Hank/.ssh/id_ed25519_sk 
debug1: Will attempt key: /Users/Hank/.ssh/id_xmss 
debug1: Will attempt key: /Users/Hank/.ssh/id_dsa 
debug1: Offering public key: /Users/Hank/.ssh/id_rsa RSA SHA256:KEY_VALUE_REDACTED
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /Users/Hank/.ssh/id_ecdsa
debug1: Trying private key: /Users/Hank/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/Hank/.ssh/id_ed25519
debug1: Trying private key: /Users/Hank/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/Hank/.ssh/id_xmss
debug1: Trying private key: /Users/Hank/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password: 
...

and so I am still prompted for a password. I believe the clue to the problem lies with this line:

no mutual signature algorithm

Does this mean that the instances of SSH on the two devices are incompatible and thus using key-based auth is not possible? This seems like it should be straightforward, but something isn't quite right.

TLDR; The Unifi controller software supports SSH key-baed auth, but this only applies to attaching to network devices like APs, switches and routers. The CK is a client and it's apparently not possible to accomplish my goal via the controller software.

There's a fair bit of chatter surrounding this approach, but nothing seems to address this specific issue.

EDIT: I did find this, which is leading me to believe that my CK (which is admittedly ancient) may be the source of the problem. Upgrading ssh on the CK, while theoretically possible, is a suboptimal solution because I'd expect future firmware upgrades would overwrite any intermediate changes.

Is the answer to use something other than RSA?

EDIT2: Solution - FTF, here are the revised commands that worked in my case:

• Generate key pair: ssh-keygen -t ed25519
• Copy public key to server: ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
• Check permissions: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys
• Restart: sudo systemctl restart sshd (may not be required)

AWS provides support for installing python 3.11 in Amazon Linux 2023 containers.

However it isn't at all obvious how you install and run a compatible pytest in this case.

For example, if you do this:

dnf install -y pytest

the version of pytest installed is the 3.9 version which is compatible with the so-called system version of Python which is 3.9 but is not compatible with python3.11 installed via the supported method.

So what is the canonical way for installing a version of pytest which is compatible with the python3.11 as installed in the manner recommended by AWS?

I've setup a host to host setup where I only want the server ip exposed so anyone connected to the VPN can talk to the services on that server.

connections {
    rw {
      pools = rw_pool
      send_cert = always
      unique = no
      fragmentation=yes
      local {
        auth = pubkey
        certs = [CERT].pem
        id = [ID]
      }

      remote {
        auth = eap-mschapv2
        eap_id = %any
      }
      children {
        rw {
          local_ts  = [WAN IP OF SERVER]
          esp_proposals = chacha20poly1305-sha512, aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1
        }
      }
      send_certreq = no
    }
 }

The connection works an the requests are indeed coming from a VPN selected IP range, however, since i'm targeting the outfacing IP, wouldn't this still route the traffic over an un-secure channel after the IP exit?

Client config:

connections {
    home {
      version=2
      remote_addrs = [SERVER ADDR]
      vips = 0.0.0.0
      local {
        auth = eap-mschapv2
        eap_id = [ID]
      }
      remote {
        auth = pubkey
        id = [SERVER ID]
      }
      children {
        home {
          remote_ts  = [WAN IP OF SERVER]
          local_ts = dynamic
          #remote_ts  = 10.10.10.0/24
          start_action = start
        }
      }
    }
  }

A second smaller question, how would you make a host to site setup, where my server is a single entity in its network, but the other side is a fortigate router with a larger network behind it, would this setup work?

Thanks for the effort in advance!

EDIT: Ip problem solved by using ip to create a tun0 interface and using that as local_ts

Openvpn3 stopped working after I upgraded my Ubuntu 20.04 laptop from python3.8 to python 3.11

I get this error:

openvpn3-systemd[9972]: ModuleNotFoundError: No module named '_dbus_bindings'

I found that import dbus works fine with python3.8 but does not work with python3.11

I tried to make openvpn3 work by changing the default system python back to 3.8 using

sudo update-alternatives --config python

And I also verified that when I use python in the command line, it finds dbus,

python -c 'import dbus'

Restarting the service still fails with the same error. I edited the file /usr/libexec/openvpn3-linux/openvpn3-systemd so it prints the python version before trying to import dbus using these 2 lines at the top of the file:

import sys
print ('openvpn3-python-version-used: ' + sys.version)

And I see it is using python3.11

How can I change the service file /lib/systemd/system/[email protected] to force it to use the older python3.8 version?

Current service file:

[Unit]
Description=OpenVPN 3 Linux - VPN session for %I
After=dbus.service network-online.target
Wants=dbus.service network-online.target
Documentation=man:openvpn3-linux(7)
Documentation=man:openvpn3-systemd(7)

[Service]
Type=notify
PrivateTmp=true
ProtectSystem=true
ProtectHome=true
Environment="PYTHONUNBUFFERED=on"
ExecStart=/usr/libexec/openvpn3-linux/openvpn3-systemd --start %i
ExecReload=/usr/libexec/openvpn3-linux/openvpn3-systemd --restart %i
ExecStop=/usr/libexec/openvpn3-linux/openvpn3-systemd --stop %i

[Install]
WantedBy=multi-user.target

I have the following ClusterRoles defined:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-system
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - list
- nonResourceURLs:
  - '*'
  verbs:
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-nonsystem
rules:
- apiGroups:
  - '*'
  resources:
  - secrets
  - PersistentVolumes
  - Role
  - RoleBinding
  verbs:
  - list
- apiGroups:
  - '*'
  resources:
  - deployments
  - pods
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- nonResourceURLs:
  - '*'
  verbs:
  - list

I use the following RoleBindings to assign a user the above ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: theuser-nonsystem-role-binding
  namespace: nonsystem-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployer-nonsystem
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: theuser

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: theuser-kube-system-role-binding
  namespace: system-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployer-system
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: theuser

However, they are able to run a kubectl -n [NAMESPACE] get secrets -o yaml and see all the secrets. I would expect this call to be forbidden based on the ClusterRole specifications above.

Am I missing or misunderstanding something here? Why can the user "get" secrets?

UPDATE: Please note: my issues is NOT that they can list secrets. My issue here is that the user can "get" secrets (different verbs!)