3

Running a debian variant (osmc)

What I'm trying to do:

  • Disable ssh through password, requiring both key and google authenticator; That's all working
  • But now I'm trying to only require the 2 factor authentication from outside local network (it's easier for backup scripts but if there's another, better, way to do this please do say)

Currently using putty & pageant from a windows box to test, just in case it's relevant

So I'm using the solution here - https://serverfault.com/questions/799657/ssh-google-authenticator-ignore-whitelist-ips

What's now happening - When I connect from outside the network it still requires the 2 factor authentication as required From inside the network it looks like it recognises the key but then errors with "Further authentication required".

Many thanks in advance for any help

sudo systemctl status ssh

Aug 25 19:51:36 mosmc sshd[10528]: error: PAM: Permission denied for osmc from beast
Aug 25 19:51:36 mosmc sshd[10528]: Failed keyboard-interactive/pam for osmc from 192.168.21.3 port 54330 ssh2
Aug 25 19:51:36 mosmc sshd[10528]: error: Received disconnect from 192.168.21.3: 14: No supported authentication methods available [preauth]

Cat of files below (where it mentions a script I've just scripted the install of this media box as my messing keeps breaking it)

    osmc@mosmc:~$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port XXXXXXX #changed by sshinstall
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2

# Inserted hostkeys by ssh-install script
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
#End of inserted code
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel VERBOSE #edited by script

# Inserted ftp by ssh-install script
# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
Subsystem internal-sftp  /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
#End of inserted code

# Authentication:
LoginGraceTime 120
PermitRootLogin no #edited by script
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes #edited by script

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no #edited by script

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*


# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of PermitRootLogin without-password
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.

# Inserted google-auth settings by ssh-install script
AuthenticationMethods publickey,keyboard-interactive:pam
KbdInteractiveAuthentication yes
# Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.
UseLogin no
#End of inserted code
UsePAM yes

access-local.conf

osmc@mosmc:~$ cat /etc/security/access-local.conf
# only allow from local IP range
+ : ALL : 192.168.21.0/24
+ : ALL : LOCAL
- : ALL : ALL

pam.d

osmc@mosmc:~$ cat /etc/pam.d/sshd
# PAM configuration for the Secure Shell service

# Inserted PAM settings by ssh-install script
auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf
auth required pam_google_authenticator.so
#End of inserted code

# Standard Un*x authentication.
#@include common-auth #commented out  by sshinstall

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
@include common-account

# SELinux needs to be the first session rule.  This ensures that any
# lingering context has been cleared.  Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close

# Set the loginuid process attribute.
session    required     pam_loginuid.so

# Create a new session keyring.
session    optional     pam_keyinit.so force revoke

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session    required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale

# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context.  Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open

# Standard Un*x password updating.
@include common-password
  • Change auth [success=1 default=ignore] pam_access.so to auth success pam_access.so. – HostFission Aug 26 '17 at 8:49
  • Thanks but that seems not to be it Both ask for the verification code but then fail. Could I check what your thoughts were on that please? I'll have a further look into that area in the meantime – beardedfool Aug 26 '17 at 16:47
  • Tried auth success=1 pam access.so accessfile=/etc/security/access-local.conf as well Externally asks for code but fails (access denied). Internally just fails straight away Am I right in what this line is doing... check the IP against the access file and then skip 'success=n' lines. If so that difference in the behaviour of internal and external seems to suggest it's recognising that it's on the internal network, just that it doesn't have enough authorisation methods to satisfy the login conditions (guess??) I'm not sure why it makes the external fails now though? – beardedfool Aug 26 '17 at 17:11
2
auth [success=done default=ignore] pam_access.so accessfile=/etc/security/access-local.conf

Seems to be the answer. Editing this as I learn more.

From http://linux-pam.org/Linux-PAM-html/sag-configuration-file.html

success=done

done equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application.

default=ignore

ignore when used with a stack of modules, the module's return status will not contribute to the return code the application obtains.

from - https://serverfault.com/questions/134471/success-n-control-syntax-in-pam-conf-pam-d-files#134488

success=1 skips a line.

If someone else wants to write a better answer that explains what's happening - I'll happily accept that.

Thanks to Hostfission for pointing me at the right part.

0

@beaderdfool, thanks for your hard work. I'm ressurecting to identify that your answer worked, but I was able to authenticate with ANY password. I played around a bit and came up with the following hacky solution:

auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/access.conf
auth sufficient pam_google_authenticator.so
auth required pam_unix.so

the first line uses the rules in access.conf. If that matches, success=1 will skip the next line. In other words: a match on the local network will skip the google authenticator, and will next try a required password match from pam_unix.so

On the other hand: if pam.access.so doesn't match, google_authenticator will run and it is sufficient if that passes...meaning it doesn't care about anything else in the stack, ie pam_unix.so and won't require an additional password.

My setup is thus:

  • Local network only requires a username and a password;
  • All others require a private key (set up in /etc/sshd_config) and google authenticator

I would have left a comment but not enough street cred.

  • Glad to have helped Just to comment that using keys means I don't even need to login from the network and makes it all very pleasant to use - but you know your use case. – beardedfool May 15 '18 at 11:34

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.