1. 19

  2. 6

    I’m not sure I understand the idea here.

    We are supposed to generate unencrypted keypairs and leave the private keys floating around on our systems in the hopes of catching SSH key abuse?

    1. 5

      Putting sshd in debug3 log mode does log ssh keys used. Have done that before, and a little log parsing can get you far. No need for a special script.

      1. 1

        This sounds much better. It would be very nice if SSH could detect honeykeys and log them with ERROR level.

        1. 1

          Configure ssh to log to syslog, and filter honeykey messages to a separate log file that you alert on. You can then discard the extra debug messages in your syslog config.

      2. 3

        I use this feature to give people accounts on my network, but having them log in to my SSH Bastion without ever being able to run a command on the bastion.

        1. 1

          I’d rather have built-in honeykey support in SSH to log out the suspicious attempt without exposing any attack surface. That could be used routinely on production systems.

          1. 1

            This doesn’t give the attacker a shell. It forces the command “/usr/local/bin/honeykey kulinacs@honeypot” to run and then disconnects the session.

            1. 2

              Updated, thanks. I’m a quite concerned about the proposed implementation. There are too many moving parts around executing a script.

              1. 1

                If it wasn’t a script but a statically linked binary (no dependencies) would that be better? Using command in authorized_keys is an extremely common way to automate tasks that need to be remotely prodded

                1. 2

                  Slightly. There’s still a lot of code being executed to create a user session and SSH is not perfect: https://www.cvedetails.com/vendor/120/SSH.html

                  Look at all the parameters in “2”: https://research.kudelskisecurity.com/2013/05/14/restrict-ssh-logins-to-a-single-command/

                  Parsing logs as @raymii suggested sounds 10x times safer.

                  1. 2

                    Authorized key command can be useful, but for security I’d rather use a chroot without root and just the thing the user needs to do. With authorized key command you have to be careful, if you allow too much, the user might be able to append or edit the authorized key file and give themselves other permissions.

                    Every solution has its use but I often try to look at what’s behind the question to build a better solution. In this case, information gathering and notification, which in my opinion can be done by parsing logs. Then you don’t even need a user on your system and can just check the log for that specific key.