I'm trying to use dovecot IMAP server, and with the interface of squirrelmail.
Correct me if i'm wrong but I understood that the root login credentials for the
squirrelmail are the same as the root login credentials for the dovecot.
If so, how can i set/configure/find out my dovecot root password?
thanks.
Dovecot is used for mail delivery and should not be confused with the server root. You set up users with passwords usually in the /etc/passwd /etc/shadow directories.
For instance in the dovecot.conf file:
protocols = imap imaps
auth default {
mechanisms = plain login
passdb pam {
args = dovecot
}
userdb passwd {
}
socket listen {
client {
path = /var/spool/postfix/private/auth
user = postfix
group = postfix
mode = 0660
}
}
}
Dovecot will use PAM for password authentication and look in the /etc/passwd file for users and match them with password from either /etc/passwd or if not found there /etc/shadow
So whatever user/password combinations you create, those are the ones that can connect via IMAP from your squirrelmail interface
Related
I've managed to install influxdb2 and login to the web ui at localhost:8086 with the default username/pass admin/admin. But when I try to login now with the same credentials i get an error saying "Could not sign in" as shown here: Running systemctl status influxdb gives me this output: This persists after reboots and reinstalls of influxdb. Is there some way to hard reset the password or to disable the authentification?
You can reset your InfluxDB 2 administrator password by recovering a admin token if you have access to the installation filesystem.
Find influxd.bolt on the host or in the container: /var/lib/influxdb2/influxd.bolt
Search this mixed text and binary json file for strings like your known username or token.
cat /var/lib/influxdb2/influxd.bolt | strings | grep "admin's Token"
{"id":"1234567898000000",
"token":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==",
"status":"active",
"description":"admin's Token",
With an admin-privileged token, you can update the password with the Influx Command Line Interface (CLI) command influx user password. For example:
$ docker exec -it 85e4df16a429 influx user password -n admin -t xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
? Please type your new password *********************
? Please type your new password again *********************
Your password has been successfully updated.
$
It happened the same to me, I created a user and then I forgot the password.
For those who work in Windows, go to C:\Users\YourName and delete .influxdbv2.
I forgot i created a new user, organization and bucket when first running influxdb.
I've managed to solve it by purging all the influxdb files by running dpkg --purge influxdb2 and then reinstalling.
I am using HTTPie to make edgegrid authenticated calls to a set of REST APIs, but httpie always asks for password which hinders my ability to make calls in a shell script. The password is my localhost/system password, which after inputing, the command executes fine.
~/Desktop/DevOps/HTTPie/apiscripts-wip/tech_jam/casemanagement$ ./pull_cases.sh
http: password for techjam#localhost:
Question -> how do avoid this? Is there some issue with my environment set up?
--auth, -a
Pass a username:password pair as the argument. Or, if you only specify a username (-a username), you'll be prompted for the password before the request is sent.
https://httpie.org/doc#authentication
So you just need to update your script to include the password:
http -A edgegrid -a techjam:YOURPASSWORD --timeout=300 ':/case-management/v2/cases?duration=30&type=company-active'
(Btw, you don't need to—and probably don't even want to—change the default options in the config to include --auth-type, etc. The command above contains all those options so you can just rm ~/.httpie/config.json.)
I have a system where I'm trying to run the docker logincommand, it is a headless linux system, but unfortunately only the Docker Credentials Helper docker-credential-secretservice is installed.
This means that I get the following error:
Error saving credentials: error storing credentials - err: exit status 1, out: `Cannot autolaunch D-Bus without X11 $DISPLAY`
It makes sense that I get this as:
By default, Docker looks for the native binary on each of the
platforms, i.e. “osxkeychain” on macOS, “wincred” on windows, and
“pass” on Linux. A special case is that on Linux, Docker will fall
back to the “secretservice” binary if it cannot find the “pass”
binary. If none of these binaries are present, it stores the
credentials (i.e. password) in base64 encoding in the config files
described above.
And since secretservice helper uses a GUI credentials store it tries to open a window, which it can't on the headless system.
I've no control over the system, so I can't remove the /usr/bin/docker-credential-secretservice file to force docker login to fall back to the config file rather than using the secretservice helper.
What I can do is create and list files in my user's home folder. I've tried to run the command as such:
docker --config ./docker login -u <user-name> -p <password> <repository>
I was under the impression that the login command would then create a config.json in the ./docker (I've noticed docker login will create the folder if it doesn't exist). This works on a system that doesn't have any helpers installed, but not on the system in question.
I've also tried to create a ~/.docker/config.json with something like:
echo '{"credStore":""}' > ~/.docker/config.json
Hoping that docker login would get the hint not to use any helpers for the credential store.
Is there a way for a non-admin to force docker login to fall back to:
stores the credentials (i.e. password) in base64 encoding in the config files described above.
Without deleting the credentials helper?
(as a side note, I'll of course ask to have the /usr/bin/docker-credential-secretservice removed but, in case it's not possible or for future reference, are there any alternative solutions?)
Logging out the current user, before logging in with a different user name worked for me. Logging out removed the saved docker credentials.
docker logout <reponame>
docker login <reponame>
To avoid using a credsStore and to store a plaintext auth token in your docker config (e.g. ~/.docker/config.json), delete the "credsStore" key from your docker config file and rerun docker login.
When you run docker login, it will give a warning but will save the auth token into the file.
$ docker login
Username: someuser
Password:
WARNING! Your password will be stored unencrypted in ~/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
The resulting docker config file should look like this:
{
"auths": {
"your.docker.registry": {
"auth": "dXNlcm5hbWU6cGFzc3dvcmQK="
}
}
}
The auth token is simply a base64 encoded string of the form username:password.
This worked for Docker Engine versions 19 and 20.
Unfortunately, Docker (as of 18.06) first looks for the docker-credential-* binaries, and if it finds any of them, it will automatically overwrite the "credsStore" value in ~/.docker/config.json.
Your only workaround would be to install docker-credential-pass in your home directory so that Docker will use that instead of docker-credential-secretservice. docker-credential-pass does not require a GUI.
Steps to install docker-credential-pass:
docker login fails on a server with no X11 installed
You can just ignore all the output by sending everything to /dev/null like:
echo $TOKEN|docker login -u=user --password-stdin myregistry.com > /dev/null 2>&1
where $TOKEN will be your previously exported token or password.
This will be useful as well with CI's when using some automation
I've looked through the code and there appears to be no way to generally disable the use of credential helpers. But you can skip the code path on a per-registry basis.
https://github.com/docker/cli/blob/25eee83d6b8c475548254b2decc9c8e0490d229c/cli/config/configfile/file.go#L308 will look up the helper to use (just the suffix after docker-credential-) in credHelpers from the registry host name. If it is "" it will use the normal unencrypted file store. As far as I can tell, this is undocumented and likely unintended behavior.
With that, in order to bypass the credential helpers for a specific registry, do
mkdir ./docker
echo "{\"credHelpers\": {\"$REGISTRY_HOST\": \"\"}}" > ./docker/config.json
docker --config ./docker login -u $USERNAME -p $PASSWORD $REGISTRY_HOST
I believe the cause why {"credsStore":""} isn't working is the omitempty serialization tag on that field. Setting it to empty is the same as not setting it.
Not an answer to the question, but maybe to the problem:
We can launch dbus ourselves then unlock/lock/query the keyring from the cli.
These are the bash functions I use:
function unlock-keyring () {
export $(dbus-launch)
read -rsp "Password: " pass
export $(echo -n "$pass" | gnome-keyring-daemon --unlock)
unset pass
}
function lock-keyring () {
dbus-send --dest=org.gnome.keyring --print-reply /org/freedesktop/secrets org.freedesktop.Secret.Service.LockService
}
function query-keyring-locked () {
busctl --user get-property org.freedesktop.secrets /org/freedesktop/secrets/collection/login org.freedesktop.Secret.Collection Locked
}
https://unix.stackexchange.com/questions/473528/how-do-you-enable-the-secret-tool-command-backed-by-gnome-keyring-libsecret-an
https://superuser.com/questions/700826/how-to-lock-a-unlocked-gnome-keyring
https://superuser.com/questions/1618970/query-status-of-gnome-keyring
https://unix.stackexchange.com/questions/602313/unlock-gnome-keyring-daemon-from-command-line
Simply rename ~/.docker/config.json to something different, or remove it if you won't need it anymore.
mv ~/.docker/config.json ~/.docker/backup-config.json
I want to configure freeRADIUS server as a authentication server for enterprise WLAN testing. I'm new to freeRADIUS server configuration. please give me the step by step or any link for installation and configuration
Thanks,
Devaa
First we’ll need a place to work, so I created a directory:
mkdir /usr/src/freeradius && cd /usr/src/freeradius
Next we need to fetch our source and get any dependencies, so update your sources and enter the following commands:
apt-get update
apt-get build-dep freeradius
apt-get install libssl-dev fakeroot
apt-get source freeradius
This should have downloaded the FreeRADIUS source code for us, so now we’ll have to make a few changes to tell our compiler to build it with the EAP modules we’ll be using. First edit /usr/src/freeradius/freeradius-1.1.3/debian/control and remove libssl-dev from Build-Conflicts: and add it to the end of Build-Depends: line. Your file should look like this:
Build-Depends: debhelper (>= 5), libltdl3-dev, libpam0g-dev, libmysqlclient15-dev | libmysqlclient-dev, libgdbm-dev, libldap2-dev, libsasl2-dev, libiodbc2-dev, libkrb5-dev, snmp, autotools-dev, dpatch (>= 2), libperl-dev, libtool, dpkg-dev (>= 1.13.19), libssl-dev
Build-Conflicts:
Next you’ll need to add descriptions for your EAP modules, so enter the following at the end of the file:
Package: freeradius-eaptls
Architecture: any
Depends: freeradius (= ${binary:Version}), ${shlibs:Depends}
Description: eap-tls module for FreeRADIUS server
Debian will not provide a binary version of the rlm_eap_tls.so library. This
module is required if you want to use EAP/TLS authentication, commonly used
for WiFi access points.
Package: freeradius-eappeap
Architecture: any
Depends: freeradius (= ${binary:Version}), ${shlibs:Depends}
Description: eap-peap module for FreeRADIUS server
Debian will not provide a binary version of the rlm_eap_peap.so library. This
module is required if you want to use EAP/PEAP authentication, commonly used
for WiFi access points.
Save and exit this file.
Next we’ll edit /usr/src/freeradius/freeradius-1.1.3/debian/rules. Find and comment our the “buildssl=” and “moduleslist=-“ lines and add the following lines:
buildssl=–without-rlm_otp –without-rlm_sql_postgresql –without-snmp
modulelist=krb5 ldap sql_mysql sql_iodbc eap_peap eap_tls
Save and exit.
Now enter the following commands:
echo “usr/lib/freeradius/rlm_eap_tls*.so” >/usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eaptls.install
echo “usr/lib/freeradius/rlm_eap_peap*.so” > /usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eappeap.install
Next let’s create /usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eaptls.postinst and enter the following:
#! /bin/sh
set -e
case "$1" in
configure)
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d freeradius restart
else
/etc/init.d/freeradius restart
fi
;;
abort-upgrade)
;;
abort-remove)
;;
abort-deconfigure)
;;
esac
#DEBHELPER#
Now we’ll create /usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eappeap.postinst and add the following to it:
#! /bin/sh
set -e
case "$1" in
configure)
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d freeradius reload
else
/etc/init.d/freeradius reload
fi
;;
abort-upgrade)
;;
abort-remove)
;;
abort-deconfigure)
;;
esac
#DEBHELPER#
Now that the hard part is finished let’s compile our deb packages. Enter the following command:
cd /usr/src/freeradius/freeradius-1.1.3/
dpkg-buildpackage -rfakeroot -uc -us
If all went well you should now have several of .deb packages in /usr/src/freradius, so let’s install them by entering the following:
dpkg -i freeradius_1.1.3-3_i386.deb
dpkg -i freeradius-eaptls_1.1.3-3_i386.deb
dpkg -i freeradius-eappeap_1.1.3-3_i386.deb
Check to see if FreeRADIUS compiled and installed correctly by issues the following command:
ps aux | grep freeradius
And you should see something similar to this:
freerad 29998 0.0 0.8 44620 2224 ? Ssl 00:55 0:00 /usr/sbin/freeradius
If not start FreeRADIUS in debug mode as root and look for any clues to why things are not working properly:
freeradius –X
Also check /usr/lib/freeradius and ensure that the rlm_eap_peap-1.1.3.so and rlm_eap_tls-1.1.3.so modules exist.
Now to configure FreeRADIUS
First we’ll edit /etc/freeradius/radiusd.conf
NOTE: When editing the configuration files be sure that every open bracket ({) has a corresponding ending bracket (}) or you will break FreeRADIUS!
Find the mschap stanza under MODULES and configure it with the following parameters:
mschap {
authtype = MS-CHAP
use_mppe = yes
require_encryption = yes
require_strong = yes
}
Next verify the authorize stanza includes these parameters:
preprocess
mschap
suffix
eap
files
Now verify that the authenticate stanza is configured like this:
authenticate {
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
# Allow EAP authentication.
eap
}
Now we have to add a client to the clients.conf. By client we mean an authenticator such as an access point (AP) or a wireless controller. For this example we’ll use my Juniper SSG5’s address of 192.168.44.129. Add the following stanza to the clients.conf:
client 192.168.44.129 {
secret = test123
shortname = Juniper
}
Next we’ll configure our server to support PEAP by editing /etc/freeradius/eap.conf.
First change the default_eap_type in the eap stanza to look like this:
default_eap_type = peap
Because PEAP needs to support our example certificates uncomment the tls stanza as well as the following parameters.
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem
certificate_file = ${raddbdir}/certs/cert-srv.pem
CA_file = ${raddbdir}/certs/demoCA/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
}
Next find and uncomment the peap stanza and the following parameter:
default_eap_type = mschapv2
Now add a test user in the /etc/freeradius/users file so we can test the system. Add the following:
“tobias” User-Password == “password123”
Restart FreeRADIUS with the following command:
/etc/init.d/freeradius restart
Now if you’ve done everything correctly you should be able to authenticate with your test user with the following command:
radtest tobias password123 localhost 0 testing123
You should see:
ending Access-Request of id 170 to 127.0.0.1 port 1812
User-Name = "tobias"
User-Password = "password123"
NAS-IP-Address = 255.255.255.255
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=170, length=20
At this point everything should be working, although you would have to export your CA’s certificate to your PEAP clients so they would trust the server certificate being used by FreeRADIUS. The certificates we are currently using are there only to test with and should not be used for production. Next I’ll explain how to setup your own certificate authority (CA) and create your own certificates.
First we’ll need to install OpenSSL and since we’ll need to generate some complex passwords we’ll also install PWGen the password generator.
apt-get install openssl pwgen
OpenSSL uses a defaults file, /etc/ssl/openssl.cnf, that we’ll backup and edit to save us some time when we start generating our certs.
cp /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.bak
Now edit /etc/ssl/openssl.cnf and find this line:
dir =./demoCA
and change to:
dir =/etc/freeradius/eap/eapCA
This is the location were I’ll be creating the new CA. You might want to look through the rest of the file and edit the defaults to your environment. Here are some of the changes that I made to my openssl.cnf.
-countryName_default = AU
+countryName_default = US
-stateOrProvinceName_default = Some-State
+stateOrProvinceName_default = Oregon
+localityName_default = Portland
-0.organizationName_default = Widget ltd
+0.organizationName_default = Fat of the LAN
Now create and change to the directory that all of our certificates and CA will exist:
mkdir /etc/freeradius/eap && cd /etc/freeradius/eap
We will use one of OpenSSL’s included scripts to generate our CA, but you’ll want to customize it a bit before we use it so we’ll make a copy of it in our certificate directory.
cp /usr/lib/ssl/misc/CA.pl /etc/freeradius/eap
Next we have to edit CA.pl to tell it where to create our CA. Open it and change the following line:
CATOP=./demoCA
to:
CATOP=/etc/freeradius/eap/eapCA
Your CA is at the heart of your certificate infrastructure so it is important to protect it once you’ve generated it as well as use a strong password for it. I’ll generate a nice random 25 character password with pwgen. Be sure to record this password as you’ll need it each time you sign a certificate.
pwgen 25 1
aem5xahheethohP5Woh5Eb3ph
Now let’s run the script from within the /etc/freeradius/eap directory.
cd /etc/freeradius/eap
./CA.pl –newca
Answer all of the questions based on your environment and use the password you just created when prompted. When the script finishes you’ll have your own CA in /etc/freeradius/eap/eapCA. The next thing we need to do is create a server certificate for FreeRADIUS and sign it with our new CA.
./CA.pl –newreq-nodes
We should now have a new key pair as well as a signing request ready to send to our CA.
A quick note on compatibility. If you plan to use any of these certificates on Windows clients you’ll need to add XP extensions to the certificates you generate. The xpextensions file is included with Debian’s FreeRADIUS packages and I’ll include it in the appendix for our non-Debian readers. Just make a copy of it in our certificate directory.
cp /usr/share/doc/freeradius/examples/xpextensions /etc/freeradius/eap
Now let’s use our CA key to sign the FreeRADIUS’ certificate request, entering the CA’s password when prompted:
./CA.pl –sign (Optionally add -extensions xpserver_ext -extfile /etc/freeradius/eap/xpextensions)
Now that all of the certificates we need are generated, we need to create a couple of files needed for keying material and tell FreeRADIUS to use the new certs. To create the dh and random files, issue the following command:
openssl dhparam -check -text -5 512 -out dh
dd if=/dev/urandom of=random count=2
chmod 640 random newcert.pem newkey.pem newreq.pem dh
Now open your /etc/freeradius/eap.conf file, find the tls stanza, and change to reflect the new certificates we created.
private_key_file = /etc/freeradius/eap/newkey.pem
certificate_file = /etc/freeradius/eap/newcert.pem
CA_file = /etc/freeradius/eap/eapCA/cacert.pem
dh_file = /etc/freeradius/eap/dh
random_file = /etc/freeradius/eap/random
And while we’re at it, uncomment the following lines:
fragment_size = 1024
include_length = yes
Restart FreeRADIUS and copy your CA’s certificate (/etc/freeradius/eap/eapCA/cacert.pem) to your clients. Configure your clients’ supplicant for your new PEAP enabled SSID, configure your AP to use 802.1x and your new FreeRADIUS server and you’re good to go!
If you are looking for more information on RADIUS, check out this book. It’s been extremely helpful thus far.
This question is so broad. It really depends on what you want to do, where your authentication data (e.g. users/passwords) is stored, what type of EAP methods you are going to use, etc.
However, the default FreeRADIUS configuration will work pretty well for most testing with minimal changes.
Start by editing the raddb/users file and add a new user to the top. The form should be like
username Cleartext-Password := "password"
Then you can use radtest or eapol_test to check to see if this is working.
When that works, you can edit the clients.conf file to add your wireless AP or controller.
You should then be able to connect from the wireless network.
However, this can be quite complicated and there are lots of things to go wrong along the way, so don't be discouraged if it doesn't work first time.
Always run the server with debugging on (radiusd -X) when testing, and read all the output. It will show you where things are failing.
There is a lot of information on the FreeRADIUS wiki, for example start with the Basic configuration HOWTO. There is also lots of good tutorial advice on Alan Dekok's page. Note that for wireless you do need to configure EAP.
Here is a step by step link that I used for my freeradius installation.
Freeradius 3 Ubuntu tutorial
If you're still having issues, get a vps that comes with radius installed
I have forgotten my luci password, but can get in via ssh. How do I reset the luci password from the console? I see that in /etc/config/luci there is this:
config extern 'flash_keep'
...
option passwd '/etc/passwd'
...
So is it done with the regular passwd command?
You can change root password use passwd command via ssh. Normally,the root password is luci password.
\# passwd
Changing password for root
New password:
You actually have to issue mount_root before using passwd, then reboot. The method in this answer alone didn't work for me (18.06.1)
root#(none):~# mount_root
switching to jffs2 overlay
root#(none):/rom/root# passwd
Changing password for root
New password:
Retype password:
passwd: password for root changed by root
root#(none):/rom/root# reboot -f
via https://openwrt.org/docs/guide-user/troubleshooting/root_password_reset
If you'd like to use a non-root user for luci, I did this on a project a few months ago:
https://github.com/sudomesh/luci-app-peopleswifi/blob/master/luasrc/controller/peopleswifi/index.lua
where "admin" was another user in openwrt. It should be said that my understanding is that openwrt is specifically not secure in multi-user environments. While theoretically you can not give that "admin" user a login shell, I'm not sure that I would depend on this solution as a secure alternative to using luci authentication as root.