sudo -i support within ssh command

[gberche-orange]

Thanks for sharing your work within the community !

We're running kubernetes k3s disto on top of nodes managed by cloudfoundry bosh infrastructure, see https://bosh.io/ and https://github.com/orange-cloudfoundry/k3s-wrapper-boshrelease for more background.

In our environment, the kubernetes nodes are reached by ssh using a guest user which has sudo/su permissions, but whose account is not configured for user interaction (e.g with crictl in path)

server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~/test# ./kubectl-nsenter --use-node-name=false --user guest -n kube-system coredns-66f786f4cb-ghcvk /coredns 
time="2025-07-10T10:07:06Z" level=fatal msg="cannot access containerd socket \"/run/containerd/containerd.sock\": no such file or directory"
nsenter: failed to parse pid: '/coredns'
./kubectl-nsenter: failed to execute ssh command: failed to run child process "ssh": exit status 1server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~/

kubectl-nsenter/internal/containerinfo/containerinfo.go

Line 16 in e73f233

exec crictl inspect --output go-template --template={{.info.pid}} %[1]s;

In our environment, the following sequence succeeds

ssh guest@192.168.116.224
sudo -i
crictl inspect --output go-template --template={{.info.pid}} 028df9c85f9db;
218035

Would it make sense to support such environments, by adding the possibly to sudo -i prior to run the discovery commands ?

[pabateman]

Thanks for the issue!

Please provide your current kubectl-nsenter version. If it's lower than 1.2.0, I recommend upgrading to the latest version (1.2.1), as version 1.2.0 introduced the -i flag for the sudo command.

[gberche-orange]

Thanks for your quick reply. I had indeed tested with version 1.2.1.

./kubectl-nsenter-linux-amd64 -v
kubectl-nsenter version v1.2.1

#93 seems to use sudo -i <command>, while in our environment, I suspect the login shell execution is required for the crictl command to succeed (aka different behavior with sudo -i; and then executing the command interactively). I'll try to reproduce with more details.

sudo --help
  -i, --login                   run login shell as the target user; a command may also be specified

[gberche-orange]

I confirm that in our environment, sudo -i <cmd> does not source the ~/.profile script

server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~$ id
uid=1001(guest) gid=1003(guest) groups=1003(guest),997(admin),1000(vcap),1001(bosh_sshers),1002(bosh_sudoers)
server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~$ sudo -i sh -c "crictl ps"
sh: 1: crictl: not found

whereas interactively it does

server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~$ sudo -i
server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~# id
uid=0(root) gid=0(root) groups=0(root)
server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~# crictl ps | head
CONTAINER           IMAGE               CREATED             STATE               NAME                     ATTEMPT             POD ID              POD
e3c09b2bf6247       629ada1caf104       12 days ago         Running             cilium-operator          9                   30bcfa412f1be       cilium-operator-d889c6b44-5n459

server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~# ls -al
total 78020
-rw-r--r--  1 root  root     3177 May 16 01:34 .bashrc
-rw-r--r--  1 root  root      199 Jul  3 13:50 .profile

server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~# cat .profile     
# ~/.profile: executed by Bourne-compatible login shells.
                                                   
if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc                                                                                       
  fi                                                                                                  
fi                                                                                                    
                                                   
mesg n 2> /dev/null || true
. /var/vcap/jobs/k3s-server/bin/envrc

server/11aa3763-7a95-47ad-8089-7399a97a2d0d:~# cat .bashrc                 
# ~/.bashrc: executed by bash(1) for non-login shells.         
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)

Thanks again for your past response on this issue. Feel free to close this issue if this seems too specific to our environment.