I've a fingerprint reader on my laptop and I installed fprintd to connect using it.
That works very well but there is this problem : When I remote connect to my laptop then I do a su/sudo command, I'm asking to swipe my finger. It works if I'm near the computer... but I'd prefer to disable it for cases I'm distant. Is there a way to do that ?
There is a bug filed for that in ubuntu which does not seem to have been resolved yet. That suggest there is no native way in fprint to do that. The workaround suggested by one user in there is to wait for the timeout.
From what I see pam can be configured in a certain way to fall back to password in case no print can be read by fprint. Archwiki says
auth sufficient pam_fprintd.so
auth include system-login
in /etc/pam.d/system-local-login not sure if that applies for your system too (for good measure here is someone configuring it in gentoo).So you should be able to allow pam to fall back on password with the right configuration.
I want to reiterate my comment for users that still don't know: Fingerprints (or biometrics in general) are not secure means of authentication (as the simpelest of the many flaws: you leave them all over your computer when you touch it).
There is a workaround:
Start two remote sessions.
On the first one, perform a sudo pwd. This will fire the fingerprint.
On the second, perform your desired command: sudo apt-get upgrade(or whatever). Since the fingerprint is blocked by the first session, it will skip directly to password authentication. No timeout.
Related
linux security and root access question....
I'm setting up a server that has a validator node running on it for a substrate-based blockchain. I was trying to harden the security of my server. I set up ufw for all ports but those necessary for the node to operate. I set up 2FA, SSH with ed25519, and then I was spending time trying to figure out, if for some crazy reason someone got in... how could I stop someone from using systemctl or poweroff with sudo privilages. The goal is maximize uptime and remain in sync with the other nodes at all times.
Anyways, I started blocking bash commands for the user account that allows SSH and blocked SSH to root. Then I blocked a few more commands and thought, what if someone could find their way around this? So, I just started blocking too many things lol. Even though I disabled sudo for the user and blocked a number of commands the user could still use systemctl and stop the service for the node. Eventually I found this guide on how to only allow a few commands for a user.
Update: I didn't properly remove the user from the sudo group. Afterwards they could still use systemctl but the system then allowed systemctl to pop up with an input for the root user password for authentication. Anyways, I just wanted something simple yet secure sooo....
I ended up removing all of the commands from the user and symlinked the su command and renamed it to a random command that only I know. All of the other commands done by the user respond with
-rbash: /usr/lib/command-not-found: restricted: cannot specify /' in command names
I took away bash history and bash autocomplete/tab completion. Now the only thing you can do is guess commands that will get you to the point where you still have to get past my root password. Is there a way for hackers to scan for available commands when there is only one available that is masked in this way?
Anyways, I'm saying all of this because I have always heard best security practices involve "disabling root". Sometimes I see it as just disable root SSH, which i already have done, but sometimes i read it like disable the root account. Some say disable the password and try to divvy it up with sudo privileges so it's more traceable to individual users.
In my case I need to preserve root access in some way but I basically hid everything within the root user. So, if anyone gets access to root it's over. But, it's behind 2FA, SSH, and an unknown command that just gets to where you can try a password to access root.
Am I thinking about this "disable root for security" all wrong and I should disable it completely or does it make sense what I've done so far?
You can also create a SSH key and use this to login to a Linux server, instead of using a password, and do not share your private key.
The following link is a tutorial on how to create a SSH key one, https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/
You could also add user filtering with AllowUsers option in sshd_config file:
AllowUsers admin1#192.168.1.* admin2#192.168.1.* otherid1 otherid2
This allows admin1 and admin2 only from 192.168.1.* addresses and otherid1, otherid2 from anywhere.
I have been using gpg for encryption for a while. Someone suggested that I should use gpg2 instead. When I went to use gpg2, I could do almost nothing; it would complain that access to private keys was required, but I could not seem to get it to use the private keys without gpg-agent running.
It turns out that I intentionally disabled gpg-agent (by using chmod -x /usr/bin/gpg-agent); this caused gpg2 to have very limited functionality and complain to stderr.
The reasons I disabled gpg-agent was following a chain of events.
First, I would SSH into a remote machine and "an agent" would open a popup asking for me to unlock my SSH keys. I did not like this because:
A pop-up on my screen interrupts my workflow
A pop-up on my screen is unlikely to be noticed, so it would appear instead that the connection is stalling instead of querying to unlock an encryption key
The agent appeared to cache my password when I absolutely do not want my password cached (much like sudo's annoying use of password caching, I can disable that in its config); I will always want to enter the passphrase for my encryption keys every time they are used for whatever program is using them.
The pop-up appeared to be owned by a separate process, while I want the specific process using the key to query for the passphrase (even if it's a library that does the actual querying); since I spend most of my activities using command-line tools, that means a GUI application isn't ideal because not everything I do will have access to X11
Automatically starting a separate process in the background removes the concept of "one command, one process", especially if that backgrounded process then lingers after the original command has exited
It turned out to be GNOME's key agent and that I could not uninstall the agent without uninstalling GNOME. So I simply disabled it by chmod -x /usr/bin/gnome-keyring*. I then found that SSH would fall back to another agent so I disabled that too using the same method chmod -x /usr/bin/ssh-agent*
When I started using gpg, I found it had a similar agent, the same one I am asking about. I disabled it immediately for the same reasons; I want software to always ask me for passphrases in order to use a private key. I do not want the passphrase to be cached for any reason whatsoever.
So with gpg2 appearing to require gpg-agent, I would like to ask:
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
Is there a way to use gpg2 without gpg-agent ever running?
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Your concerns are certainly valid IMO. The good news is that there are ways to customize gpg-agent behaviour to suit your needs. For example, use a terminal-based passphrase prompt (PIN entry) instead of a GUI prompt and do not cache passphrases.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
A quick solution, likely not a best practice, is to customize your ~/.gnupg/gpg-agent.conf with the following options:
# Expire cached PINs (passphrases) after zero seconds
default-cache-ttl 0
max-cache-ttl 0
# If you use your GPG keys for SSH auth...
default-cache-ttl-ssh 0
max-cache-ttl-ssh 0
enable-ssh-support
# Use TTY-based PIN entry program (I see pinentry,
# pinentry-curses, pinentry-gnome3, pinentry-tty and
# pinentry-x11 on my system)
pinentry-program /usr/bin/pinentry-tty
I found the following guides on GPG key best practices (more of a general guide around key management, not exactly what you're asking) fairly informative and easy to follow:
https://alexcabal.com/creating-the-perfect-gpg-keypair/
https://riseup.net/en/security/message-security/openpgp/best-practices (somewhat dated, some sections don't work out of the box with latest gpg 2.x versions)
Is there a way to use gpg2 without gpg-agent ever running?
Not with gpg 2.x as far as I am aware of. The man page states the following:
--use-agent
--no-use-agent
This is dummy option. gpg always requires the agent.
I have gpg 2.1.15.
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Good question... By default, gpg-agent uses a socket, so technically any process running as your user could in theory hijack your keys. Don't quote me on this, though. Here's an overview of how the gpg-agent works that will hopefully get you started on finding out the real answer:
https://unix.stackexchange.com/questions/188668/how-does-gpg-agent-work
According to https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase in order to provide password directly to gpg - without gpg-agent running - you need to run with following options:
gpg --passphrase-fd 0 --pinentry-mode loopback ...
You need to provide password in console right after running this command. No password prompt will be visible during typing, but you will see typed password.
To hide password while typing you can wrap command in stty:
stty -echo ; gpg ... ; stty echo
I tested this with GnuPG v. 2.2.4: killed gpg-agent, shredded /usr/bin/gpg-agent, then run as described above. Worked well.
Every time I commit a file in svn I get the following message:
ATTENTION! Your password for authentication realm:
http://domainname.com:80 “domainname.com”
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'.
Store password unencrypted (yes/no)? no
I don't want this authentication; how can I get rid of this warning?
You are not storing the password in Subversion because you answered no to the question whether or not you want to store this password.
I take it you want to eliminate this error warning message entirely. There are two ways to handle that:
The easy, but hard way: You can specify svn --no-auth-cache each and every time you a Subversion command. It's easy to do since it requires no real action on your part. It's hard because you have to do this almost every time you use a Subversion command (especially one that touches the repository like checkout and commit).
The hard, but easy way: You can modify your user's Subversion configuration not to ask if you want to store this information. (BTW, why are you running as root? You like living life on the edge? Better off running as a user and configure sudo to allow you to do the root stuff you need. That way, you can track who's doing what, and you don't do something that could accidentally bring the server down. In fact, many Unix/Linux systems by default no longer allow a user to sign in as root. You have to do sudo). This is hard because you have to do something, but easy because once you do it, you don't have to do anything again.
You have the name of the file that you need to edit (/root/.subversion/servers). Look for the [global] section and look for the line # store-passwords = no and remove the # from the beginning of the line. You can also do the same for the # store-plaintext-passwords = no line and the # store-auth-cred = no line. While, you're at it, you can also delete the files under the auth directory which is where Subversion stores its credentials. This will completely eliminate already stored passwords. More information can be found in the on line Red Bean Subversion manual.
Now, when you do a Subversion command that touches the repository, it'll ask you for a user name and password and won't ask if you want to store them.
You copied the full warning message here. Reading it instead of just copy/pasting it would answer your question:
you can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/root/.subversion/servers'.
The subversion client is only asking for authentication because the server requires it. To get rid of the authentication requirement, you'll have to change the server's configuration (e.g., in Apache, get rid of AuthType, AuthName, and AuthUserFile). You can use other authentication methods which do not require passwords (for example, client certificates).
If you just want to get rid of the save password unencrypted prompt, you can set store-plaintext-passwords=off (by editing ~/.subversion/config) or you can make encrypted passwords work by getting (on Unices) the GNOME keyring or KDE wallet running. On Windows, SVN should automatically use built-in NTFS encryption; on Mac OS X, the Keyring. See the Client Credentials section of the SVN Manual for further details.
You could also encrypt your home directory on Unix. Then the credentials would be encrypted as well (but of course available to any program running as you or root while you're logged in, similar to the NTFS encryption).
If you don't want SVN to store passwords at all, encrypted or not, set store-passwords=no in the SVN config file.
How come I always get
"GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)"
when I start 'gedit' from a shell from my superuser account?
I've been using GUI apps as a logged-in user and as a secondary user for 15+ years on various UNIX machines. There's plenty of good reasons to do so (remote shell, testing of configuration files, running multiple sessions of programs that only allow one instance per user, etc).
There's a bug at launchpad that explains how to eliminate this message by setting the following environment variable.
export DBUS_SESSION_BUS_ADDRESS=""
The technical answer is that gedit is a Gtk+/Gnome program, and expects to find a current gconf session for its configuration. But running it as a separate user who isn't logged in on the desktop, you don't find it. So it spits out a warning, telling you. The failure should be benign though, and the editor will still run.
The real answer is: don't do that. You don't want to be running GUI apps as anything but the logged-in user, in general. And you never want to be running any GUI app as root, ever.
For some (RHEL, CentOS) you may need to install the dbus-x11 package ...
sudo yum install dbus-x11
Additional details here.
Setting and exporting DBUS_SESSION_BUS_ADDRESS to "" fixed the problem for me. I only had to do this once and the problem was permanently solved. However, if you have a problem with your umask setting, as I did, then the GUI applications you are trying to run may not be able to properly create the directories and files they need to function correctly.
I suggest creating (or, have created) a new user account solely for test purposes. Then you can see if you still have the problem when logged in to the new user account.
I ran into this issue myself on several different servers. It I tried all of the suggestions listed here: made sure ~/.dbus had proper ownership, service messagbus restart, etc.
I turns out that my ~/.dbus was mode 755 and the problem went away when I changed the mode to 700. I found this when comparing known working servers with servers showing this error.
I understand there are several different answers to this problem, as I have been trying to solve this for 3 days.
The one that worked for me was to
rm -r .gconf
rm -r .gconfd
in my home directory. Hope this helps somebody.
In our administration team everyone has root passwords for all client servers.
But what should we do if one of the team members is not longer working with us?
He still has our passwords and we have to change them all, every time someone leave us.
Now we are using ssh keys instead of passwords, but this is not helpful if we have to use something other than ssh.
The systems I run have a sudo-only policy. i.e., the root password is * (disabled), and people have to use sudo to get root access. You can then edit your sudoers file to grant/revoke people's access. It's very granular, and has lots of configurability---but has sensible defaults, so it won't take you long to set up.
I would normally suggest the following:
Use a blank root password.
Disable telnet
Set ssh for no-root-login (or root login by public key only)
Disable su to root by adding this to the top of /etc/suauth: 'root:ALL:DENY'
Enable secure tty for root login on console only (tty1-tty8)
Use sudo for normal root access
Now then, with this setting, all users must use sudo for remote admin,
but when the system is seriously messed up, there is no hunting for
the root password to unlock the console.
EDIT: other system administration tools that provide their own logins will also need adjusting.
While it is a good idea to use a sudo only policy like Chris suggested depending on the the size of your system an ldap approach may also be helpful. We complement that by a file that contains all the root passwords but the root passwords are really long and unmemorable. While that may be considered a security flaw it allows us to still log in if the ldap server is down.
Aside from the sudo policy, which is probably better, there is no reason why each admin couldn't have their own account with UID 0, but named differently, with a different password and even different home directory. Just remove their account when they're gone.
We just made it really easy to change the root passwords on every machine we admininster so when people left we just ran the script. I know not very savvy but it worked. Before my time, everyone in the company had access to root on all server. luckily we moved away from that.
Generally speaking, if someone leaves our team, we don't bother changing root passwords. Either they left the company (and have no way to access the machines anymore as their VPN has been revoked, as has their badge access to the building, and their wireless access to the network), or they're in another department inside the company and have the professionalism to not screw with our environment.
Is it a security hole? Maybe. But, really, if they wanted to screw with our environment, they would have done so prior to moving on.
So far, anyone leaving the team who wants to gain access to our machines again has always asked permission, even though they could get on without the permission. I don't see any reason to impede our ability to get work done, i.e., no reason to believe anyone else moving onwards and upwards would do differently.
Reasonably strong root password. Different on each box. No remote root logins, and no passwords for logins, only keys.
If you have ssh access via your certificates, can't you log in via ssh and change the root password via passwd or sudo passwd when you need to do something else that requires the password?
We use the sudo only policy where I work, but root passwords are still kept. The root passwords are only available to a select few employees. We have a program called Password Manager Pro that stores all of our passwords, and can provide password audits as well. This allows us to go back and see what passwords have been accessed by which users. Thus, we're able to only change the passwords that actually need to be changed.
SSH keys have no real alternative.
For management of many authorized_keys files on many servers you have to implement your own solution, if you do not want the same file on every server. Either via an own tool, or with some configuration management solution like puppet, ansible or something like that.
Else a for loop in bash or some clush action will suffice.
Anything besides SSH logins:
For services you run that are login-based, use some sort of authentication with a central backend. Keep in mind that noone will do any work if this backend is unavailable!
Run the service clustered.
Don't do hacks with a super-duper-service backdoor account, to always have access in case something breaks (like admin access is broken due to a misconfiguration). No matter how much you monitor access or configuration changes affecting this account, this is 'just bad'(TM).
Instead of getting this backdoor right, you might as well just cluster the application, or at the very least have a spare system periodically mirroring the setup at hand if the main box dies, which then can be activated easily through routing changes in the network. If this sounds too complicated, your business is either too small and you can live with half a day to two days downtime. Or you really hate clusters due to lacking knowledge and are just saving on the wrong things.
In general: If you do use software unusable with some sort of Active Directory or LDAP integration you have to jump the shark and change passwords for these manually.
Also a dedicated password management database that can only be accessed by a very selected few directly, and is read-only to all the others, is very nice. Don't bother with excel files, these lack proper rights management. Working with version control on .csv files doesn't really cut it either after a certain treshold.