Bug#839278: oathtool: has no secure way to provide a key
On Fri, Nov 13, 2020 at 2:06 AM Simon Josefsson via OATH Toolkit general discussions wrote: > Thank you for the patch -- this makes sense. I'm not fond of the name > 'args-from-files' though. How about this behaviour: if the supplied > strings for KEY and/or OTP contain '/' or '\' the strings are treated as > names of files to be read, instead of data strings? And if the string > is '-' stdin is used. > '@filename' would be somewhat common, I think. Taking a slash to mean a filename also seems sensible, at least as long as you don't take base64 input too. But why backslash? Some might also like to be able to pass an fd number, to support piping. E.g. the '*-fd' options to gpg.
Bug#854284: Please package libpam-radius-auth 1.4.0
Package: libpam-radius-auth Version: 1.3.16-5 Severity: wishlish Upstream version 1.4.0 has some useful configuration options added, any chance to update the Debian package? http://freeradius.org/pam_radius_auth/ Thanks
Bug#807992: [OATH-Toolkit-help] Bug#807992: per user oath files
On 16.12. 15:44, Antoine Beaupré wrote: On 2015-12-16 06:21:01, Ilkka Virta wrote: Right, you are right of course. I do think it's critical to keep that file from being readable from random apps. The format *is* also a little brittle so it seems important to have standardized access as well... Maybe having a system similar to shadow passwords would be necessary here: there could be a secret file that can only be read by root (or with the right caps) and would need a special tool (oath.passwd?) to reset. Well being root-only and having some sort of a helper app is already needed. (Though the helper might well be the admins text editor. As for brittleness, it shares the same thing with all other text files: they kind of have to be rewritten completely every time (can't just replace a single line). Unless you meant some other brittleness? Of course there's locking, per-user files would make that a bit simpler. This was the per-user shadow file thingy I was thinking of: http://www.openwall.com/tcb/ (see the slides) -- Ilkka Virta <itvi...@iki.fi>
Bug#807992: [OATH-Toolkit-help] Bug#807992: per user oath files
A problem with doing that, is that anything that runs with the user's permissions could trivially read the secret key from the user's home directory. With SSH keys it's not a problem, since they are _public_ keys. Plus, a user could do something stupid, like resetting the OTP counter on every login, so they wouldn't need to use a pesky changing password, but instead use the same one always... I think some unix-like systems have per-user password files under /etc, so that they don't need setuid-root helpers to access them, but there still is some program to sanity check the password the user tries to set. (a setgid helper plus some trickery with file and directory permissions.) Doing something like that would simplify the backend, but of course you'd still need a helper application to access the files. On 15.12. 7:23, Antoine Beaupré wrote: Package: libpam-oath Version: 2.4.1-1 Severity: wishlist i find it problematic that the management of the OATH secrets is all centralised in a single file. it seems to me it would be preferable to delegate this management to users, the same way we have `~/.ssh/authorized_keys`. i suggest checking into `~user/.oath` for a similar format (obviously ommitting the username, to avoid forging other people's credentials). could that be considered? -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-oath depends on: ii libc6 2.19-18+deb8u1 ii liboath02.4.1-1 ii libpam-runtime 1.1.8-3.1 ii libpam0g1.1.8-3.1 libpam-oath recommends no packages. libpam-oath suggests no packages. -- no debconf information -- Ilkka Virta <itvi...@iki.fi>
Bug#784658: libpam-ssh cannot authenticate user from Additional block in pam.d/common-auth
On 7.5. 17:45, Jerome BENOIT wrote: Installing pam_ssh manually in the primary block (as below), results in the behaviour I would have expected. What must I read by manually ? I mean I edited /etc/pam.d/common-auth with a text editor, instead of using pam-auth-update(8). I would suggest changing the config to put the module in the primary block, so that it can authenticate the user on its own. Or, if that is not wanted, to set 'try_first_pass' instead of 'use_first_pass' so the login password and key passphrase don't need to match. pam_ssh also never seems to ask for the passphrase, even if the password given earlier doesn't unlock the key. (regardless of whether use_first_pass, try_first_pass or neither is given) Mmh, I realized this is because ChallengeResponseAuthentication is disabled by default in sshd_config, and it's needed for the conversation with the PAM module to work. So I have to admit this was a user error, sorry. (Not that I think the documentation about ssh vs. pam is too clear in general, bleh.) Have you tried with the version in experimental ? I did, now (libpam-ssh 2.01+ds-2), but it acts the same, since the pam config is the same and that was the only remaining problem anyway. -- Ilkka Virta itvi...@iki.fi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784658: libpam-ssh cannot authenticate user from Additional block in pam.d/common-auth
Package: libpam-ssh Version: 2.01-2 Severity: important Description of libpam-ssh says: - during authentication, the user types a SSH passphrase and is authenticated if the passphrase successfully decrypts the user's SSH private keys; However, because of the way the module is installed in /etc/pam.d/common-auth, it cannot actually authenticate the user. With the generated configuration (below), if pam_unix (or all of the primary) authentication modules fail, the requisite pam_deny.so will trigger and stop the processing of modules. pam_ssh then never gets a chance to authenticate. Logging in with the correct pam_unix password runs pam_ssh, but if the passphrase for the key is different, the key is never unlocked. pam_ssh also never seems to ask for the passphrase, even if the password given earlier doesn't unlock the key. (regardless of whether use_first_pass, try_first_pass or neither is given) generated /etc/pam.d/common-auth: - # here are the per-package modules (the Primary block) auth[success=1 default=ignore] pam_unix.so nullok_secure # here's the fallback if no module succeeds authrequisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around authrequiredpam_permit.so # and here are more per-package modules (the Additional block) authoptionalpam_ssh.so use_first_pass # end of pam-auth-update config - Examples: User kenny has a key in ~kenny/.ssh/login-keys.d/id_rsa, passphrase is keysecret. The unix password is password. trying to login with the unix pw doesn't unlock the key: root@plink:~# ssh kenny@localhost 'ssh-add -l ' kenny@localhost's password: [password] The agent has no identities. trying to login with key passphrase doesn't work at all... root@plink:~# ssh kenny@localhost 'ssh-add -l ' kenny@localhost's password: [keysecret] Permission denied, please try again. however, if the password and key passphrase are the same, the login succeeds and the key is unlocked: root@plink:~# echo kenny:keysecret | chpasswd root@plink:~# ssh kenny@localhost 'ssh-add -l ' kenny@localhost's password: [keysecret] 2048 15:5b:72:4a:73:2b:c4:cf:d1:9d:4c:94:a2:d5:36:e6 /home/kenny/.ssh/login-keys.d/id_rsa (RSA) Installing pam_ssh manually in the primary block (as below), results in the behaviour I would have expected. # here are the per-package modules (the Primary block) auth[success=2 default=ignore] pam_unix.so nullok_secure auth[success=1 default=ignore] pam_ssh.so try_first_pass debug # here's the fallback if no module succeeds authrequisite pam_deny.so # ... -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-ssh depends on: ii libc6 2.19-18 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libssl1.0.01.0.1k-3 ii multiarch-support 2.19-18 Versions of packages libpam-ssh recommends: pn libpam-tmpdirnone ii openssh-client [ssh-client] 1:6.7p1-5 libpam-ssh suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588434: libpam-ldap: unable to change password in default configuration
After spending some hours trying to find the cause from my ldap configuration, I'm happy to tell you this problem still exists in Debian 7.8 with the default configuration (generated by pam-auth-update): /etc/pam.d/common-password: password[success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 password[success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass As mentioned earlier in this bug, installing libpam-cracklib removes the problem. So does removing use_authtok from the pam_ldap.so line in /etc/pam.d/common-password . I don't see either solution mentioned in the docs, and libpam-ldap doesn't seem depend on, recommend or suggest libpam-cracklib either. I quickly tested what happens if cracklib is installed, but use_authtok is removed anyway, and didn't see any new problems appear. But perhaps someone who knows PAM better might comment on why use_authtok is needed/useful. libldap-2.4-2:amd64 2.4.31-1+nmu2 libnss-ldap:amd64264-2.5 libpam-ldap:amd64184-8.6 libpam-cracklib:amd641.1.3-7.1 cheers, -- Ilkka Virta - itvirta at iki.fi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
