1

Is there a way how you can check what auth method the user which just logged in to an account were using?

I like to print out a warning after login if someone is using a password instead of a keyfile.

Sure one solution is to check the ssh-logs. But is there a nicer way to do this? Since looking up logs could impact performance depending on the log size and method you use to gather this information.

We are using SUSE and Ubuntu.

3

You could add a directive to the authorized_keys entry for a key to add a value to the environment for sessions where that key was used. This is from the sshd documentation:

environment="NAME=value"
Specifies that the string is to be added to the environment when logging in using this key. Environment variables set this way override other default environment values. Multiple options of this type are permitted. Environment processing is disabled by default and is controlled via the PermitUserEnvironment option.

So the authorized_keys entry might look like this:

environment="SSHKEY=bob_key" ssh-rsa AAAAB3NzaC...iQ== bob@bobspc

When the user's .bashrc runs, the presence or absence of the SSHKEY variable would indicate whether that particular key was used to authenticate or not.

This is obviously not a general-purpose solution. You'd have to annotate every key entry in every authorized_keys file with this directive. And the user could subvert the check if he had access to alter his .bashrc, authorized_keys, or .ssh/rc files.

  • I'll give it a try, becuase this is pretty much what we want. Even if the user could disable the warning, it is still better then nothing. – Kevin Urbainczyk Aug 10 '18 at 7:20
1

The shell doesn't know (or care) how you authenticated. sshd will log messages, if configured (via SyslogFacility and LogLevel), to a configurable location (syslog/rsyslog), so you will have to check those logs, if they exist, to find out how the user authenticated.

Look in those logs for:

... sshd[...]: Accepted keyboard-interactive/pam for $USER from ... port ... 

or

... sshd[...]: Accepted publickey for $USER from ... port ...

to determine whether they used password (keyboard-interactive) or key authentication.

You might consider summarizing the sshd logs and sending a separate report (via email?) to the users who have logged in via password recently.

  • This would be working fine if you have root access and / or the user can access this logfile. In my case we just got some sudos. Since we don't know the users mail address, we need to inform the user right after the login. I was hoping the SSHD will set something like an environment variable. – Kevin Urbainczyk Aug 9 '18 at 13:46
  • My answer's a long way of saying "no, it doesn't". Well, it does, but only SSH_CLIENT, SSH_CONNECTION, and SSH_TTY, none of which have the information you want. – Jeff Schaller Aug 9 '18 at 13:50
  • :( Thanks for the fast reply. I will mark your answer as "accepted" since it is the best way to work-a-round. – Kevin Urbainczyk Aug 9 '18 at 13:56
  • Don't feel any rush to accept my answer; it's only been an hour. I could imagine workarounds that might come closer to your Question, such as a separate process that parses the logfiles and generates a text which is then read in by some custom code in the .bashrc files. I'm just pointing out that there's no direct route. – Jeff Schaller Aug 9 '18 at 14:07
1

Newer versions of OpenSSH (I think starting with 7.6) allow the configuration option ExposeAuthenticationMethods. If set to pam-and-env, you can get an environment variable SSH_USER_AUTH set that includes information about the authentication method(s) used. This may include multiple values, when multi-factor authentication is utilized. The default setting (consistent with earlier OpenSSH versions) is never, implying that you would need to resort to log scanning or other methods, if you cannot alter sshd_config or are running an earlier OpenSSH version.

  • We are still on OpenSSH 7.2 :( - But i will try this on ubuntu, since this would be perfect for our case.. – Kevin Urbainczyk Aug 10 '18 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.