[SOLVED].ssh folder permission gets changed

jl2 · 2023-04-16 09:00:10

Hi,
when i want to connect to my home server i get this error:

hostkeys_find_by_key_hostfile: hostkeys_foreach failed for /home/janluca/.ssh/known_hosts: Permission denied

because of that I get this:

The authenticity of host 'server (2a02:21b4:88a9:c300:ba18:7fd3:68d8:4e6b)' can't be established.
ED25519 key fingerprint is SHA256:ZW8Lu1c5mQ3qd6o9BfQRLM6cUtEP+Le/OGDd5Fqi9iU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

It's pretty anoing.
something keeps changing the permission of my .ssh folder to this:

drwx------  2 root    janluca     4096 Apr 14 20:16 .ssh

i always change it back with

sudo chown -hR janluca:janluca .ssh/

But after a reboot or after some time, the permissions are reset. It doesn't happen if I logout my local machine.

What is doing this and how do I make it stop? What is doing this and how do I make it stop?

Last edited by jl2 (2023-04-18 07:57:47)

seth · 2023-04-16 11:54:28

https://wiki.archlinux.org/title/Audit_framework

jl2 · 2023-04-16 13:33:30

audit=1 | kernel parameter,
-w /home/janluca/.ssh/ -p a -k root | added to /etc/audit/audit.rules
augenrules --load
reboot

sudo ausearch -k root returns:

Error opening /var/log/audit/audit.log (No such file or directory)

even if i chown janluca:janluca .ssh (which should be logged, as far as i understood)

am i missing something?

note that sudo dmesg | grep audit | wc -l gives me 660 lines...
but (even after chown...) sudo dmesg | grep .ssh gives me nothing

Last edited by jl2 (2023-04-16 13:39:01)

seth · 2023-04-16 14:11:02

https://wiki.archlinux.org/title/Audit_ … stallation

For userspace support install audit and start/enable auditd.service.

systemctl status auditd.service

jl2 · 2023-04-16 15:27:39

time->Sun Apr 16 17:20:22 2023
type=PROCTITLE msg=audit(1681658422.522:217): proctitle=63686F776E006A616E6C7563613A6A616E6C756361002E737368
type=PATH msg=audit(1681658422.522:217): item=0 name=".ssh" inode=2621471 dev=103:04 mode=040700 ouid=0 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1681658422.522:217): cwd="/home/janluca"
type=SYSCALL msg=audit(1681658422.522:217): arch=c000003e syscall=260 success=yes exit=0 a0=ffffff9c a1=55a3d0cfaf90 a2=3e8 a3=3e8 items=1 ppid=2770 pid=2771 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3 comm="chown" exe="/usr/bin/chown" subj=unconfined key="ssh"
----
time->Sun Apr 16 17:22:19 2023 
type=PROCTITLE msg=audit(1681658539.112:233): proctitle=6C73002D6C002D2D636F6C6F72002D41
type=PATH msg=audit(1681658539.112:233): item=0 name=".ssh" inode=2621471 dev=103:04 mode=040700 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1681658539.112:233): cwd="/home/janluca"
type=SYSCALL msg=audit(1681658539.112:233): arch=c000003e syscall=191 success=no exit=-61 a0=7ffc8121d580 a1=563defc22061 a2=0 a3=0 items=1 ppid=1805 pid=3598 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined key="ssh"
----
time->Sun Apr 16 17:22:45 2023 
type=PROCTITLE msg=audit(1681658565.586:130): proctitle=2F7362696E2F617564697463746C002D52002F6574632F61756469742F61756469742E72756C6573
type=SYSCALL msg=audit(1681658565.586:130): arch=c000003e syscall=44 success=yes exit=1080 a0=3 a1=7ffc70e16f60 a2=438 a3=0 items=0 ppid=499 pid=509 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl" exe="/usr/bin/auditctl" subj=unconfined key=(null)
type=CONFIG_CHANGE msg=audit(1681658565.586:130): auid=4294967295 ses=4294967295 subj=unconfined op=add_rule key="ssh" list=4 res=1
----
time->Sun Apr 16 17:23:18 2023 
type=PROCTITLE msg=audit(1681658598.666:200): proctitle=6C73002D6C002D2D636F6C6F72002D41
type=PATH msg=audit(1681658598.666:200): item=0 name=".ssh" inode=2621471 dev=103:04 mode=040700 ouid=0 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1681658598.666:200): cwd="/home/janluca"
type=SYSCALL msg=audit(1681658598.666:200): arch=c000003e syscall=191 success=no exit=-61 a0=7ffc5b746880 a1=55d7ca279049 a2=0 a3=0 items=1 ppid=2010 pid=2137 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined key="ssh"
----

it happend somewhere between the 1st and 3rd.
1) chown => set permissions to janluca:janluca
2) ls -Al => check the changes
a reboot at 2023-04-16 17:22:43
3) ?, aparently auditctl, which is strange => wasn't me
4) ls -Al => permissions are root:janluca

btw somebody should rehaul the wiki page, sudo augenrules --load overwrites /etc/audit/audit.rules

Last edited by jl2 (2023-04-16 15:37:49)

seth · 2023-04-16 15:52:58

3 adds the rule.

The change happens offline, ie. during the shutdown or boot process.
Reboot into some live distro to see whether the ownership has already changed.

jl2 · 2023-04-17 06:46:12

It hasn't, so it must happen during boot.
[probably not helpful] I just realized it also happens on my server, but it doesn't bother there.

Last edited by jl2 (2023-04-17 07:03:19)

seth · 2023-04-17 07:25:21

Boot only the rescue.target (2nd link below), see whether the ownership is still good. If yes, start the audit service and then isolate the multi-user.target (and then the graphical one)
Do you use systemd-homed?

jl2 · 2023-04-18 07:34:39

rescue.target => root:janluca

I realized that the problem was that the /root folder is a symlink to /home/janluca.
I had done that because I hate configuring the root shell twice.
I removed the symlink and added one for the /root/.config folder.

I guess it's normal that the /root/.ssh permissions get changed on startup, right?

Last edited by jl2 (2023-04-18 07:37:42)

seth · 2023-04-18 07:42:42

I realized that the problem was that the /root folder is a symlink to /home/janluca.
I had done that because …

… your brain temporarily completely dropped out.

I removed the symlink and added one for the /root/.config folder.

… and has not yet fully restarted. WTF. Undo that!

I hate configuring the root shell twice.

Source a common config from /etc/myshell.rc or whatever.

I guess it's normal that the /root/.ssh permissions get changed on startup

For most people it will just stay at the relevant permissions …

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

frostschutz · 2023-04-18 07:52:41

it could be systemd, /usr/lib/tmpfiles.d/provision.conf

# Provision SSH key for root
d- /root :0700 root :root -
d- /root/.ssh :0700 root :root -
f^ /root/.ssh/authorized_keys :0600 root :root - ssh.authorized_keys.root

this sets permissions for /root /root/.ssh and may even populate an authorized_keys file from systemd credentials

but in general, you can't cross symlink homedirs. the file ownerships will end up all wrong. you can put your configs in a git then use git clone, pull, etc. to give each user their own copy. or just copy them manually...

Arch Linux

#1 2023-04-16 09:00:10

[SOLVED].ssh folder permission gets changed

#2 2023-04-16 11:54:28

Re: [SOLVED].ssh folder permission gets changed

#3 2023-04-16 13:33:30

Re: [SOLVED].ssh folder permission gets changed

#4 2023-04-16 14:11:02

Re: [SOLVED].ssh folder permission gets changed

#5 2023-04-16 15:27:39

Re: [SOLVED].ssh folder permission gets changed

#6 2023-04-16 15:52:58

Re: [SOLVED].ssh folder permission gets changed

#7 2023-04-17 06:46:12

Re: [SOLVED].ssh folder permission gets changed

#8 2023-04-17 07:25:21

Re: [SOLVED].ssh folder permission gets changed

#9 2023-04-18 07:34:39

Re: [SOLVED].ssh folder permission gets changed

#10 2023-04-18 07:42:42

Re: [SOLVED].ssh folder permission gets changed

#11 2023-04-18 07:52:41

Re: [SOLVED].ssh folder permission gets changed

Board footer