1

I am not familiar with sshd process; and I am trying to enable remote ssh login without password, and I have inserted my public key in ~/.ssh/authorized_keys on the server side, and it works on one of the remote system, not the other.

I noticed the following entries in my /etc/ssh/sshd_config on the non-working remote system,

#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile /var/ssh/%u/ak

since I have my public key inserted in .ssh/authorized_keys, I tried to change the above to

AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile /var/ssh/%u/ak

This seems to allow me to remote ssh without password, however, I noticed that the file was reset back every few hours, and I have to key in password for SSH again.

any idea what is happening with the config file here?

Thanks!

sqr
  • 113
  • 1
    Purely from the sshd perspective, it shouldn't matter whether it's commented or not, since that's the default value. However, it is concerning that it's being reverted periodically. That definitely should not be happening. The reason you can't use password-less login on one your systems is more likely to be a permissions issue. – Chris Davies Sep 17 '21 at 10:57
  • 1
    It is pretty common that some services require to change AK to /var. For example some web managed system need to modify AK from httpd, but usually security rules prevent httpd related process to access user home, thus it need to be in /var – Wang Sep 20 '21 at 08:27

1 Answers1

3

  • You could use tools implementing fanotify() kernel APIs. For instance fanotify-cmd works perfectly. There's no need to edit any system files or parse logs.

    ./fm -a /etc/passwd
checking for events FAN_ACCESS
mask: FAN_ACCESS, fd: 4, pid: 203188, file: /etc/passwd, command: bash 
mask: FAN_ACCESS, fd: 4, pid: 203190, file: /etc/passwd, command: 
mask: FAN_ACCESS, fd: 4, pid: 203321, file: /etc/passwd, command: ls --color=auto -l /etc/passwd

    Ubuntu and Fedora include fatrace which is a really nice well maintained utility.

    sudo fatrace --timestamp --filter=WD

  • Or you could useauditd. Since it's a system daemon, you'll need to edit an auditd system configuration file in /etc. There are plenty of manuals on the net how to use them, e.g. on stackexchange itself.

    inotifywait unfortunately doesn't work for this use case as it merely shows the files being accessed or modified, it doesn't show what process does it.

Artem S. Tashkinov
  • 29,025
  • thank you @Artem S. Tashkinov It turns out that there is puppet service running and always modifying my sshd config. – sqr Sep 20 '21 at 08:41
  • @sqr great! What did you use? inotifywait? You may mark my answer as an answer ;-) – Artem S. Tashkinov Sep 20 '21 at 08:43
  • Hi @Artem, inotifywait doesn't print out the process name which triggered the change, auditd does. Thanks! – sqr Sep 21 '21 at 12:32
  • @sqr I've known about fanotify() for years now but was always too lazy to find utilities using it. Looks like they exist and they are very easy to use. Could be useful for you. – Artem S. Tashkinov Sep 21 '21 at 13:17
  • thanks. I understand this is a system API instead of utility, so I have to write a short C program to use it? – sqr Sep 22 '21 at 14:26
  • The "tools" is a link to ready to use tools. "fanotify-cmd" is also a link to the tool whose output I've showed here which needs to be compiled but it doesn't need anything except g++ and glibc-devel. – Artem S. Tashkinov Sep 22 '21 at 17:49
  • thank you @Artem! – sqr Sep 23 '21 at 07:11
  • You're very welcome. I wish distros packaged fanotify-cmd because it's so much more powerful than inotifywatch. – Artem S. Tashkinov Sep 23 '21 at 07:36