Change email password on Directadmin with CLI / command line

It can happen that you don’t have access to Direcadmin’s GUI, but you have root access. I had this situation with one installation with very old OS on which the license was unable to update. So because of invalid license, control panel was not accessible. You can change email password from command line like this.

  • Go to virtual directory where passwords are saved
    myDA:~# cd /etc/virtual/mydomain.com/
    myDA:/etc/virtual/mydomain.com# 
  • You can generate new crypted passowrd like bellow. “mynewpassword” is new password.
    [root@server ~]# openssl passwd -1 -salt saltsalt mynewpassword
    $1$saltsalt$XCrU04m/7D.n5Ami6FbHo/
  • Copy generated hash from previous step and change it inside  /etc/virtual/mydomain.com/passwd

That’s it. You should be able to log in into the email account with a new password.

Found this here. Thank you very much!

cPanel – change email password without cPanel access – edit shadow file

I had issue with cPanel on which license was expired. So web interface wasn’t accessible. One client had situation and need to change email password urgently. Because cpanel wasn’t accessible, he was unable to do so. There is a trick. You can change mail password without accessing cpanel directly. You can modify shadow file and paste new password hash. cPanel stores email passwords in shadow file. Here is how you can do it.

First, you need to generate new password hash in SHA512 format. You can do it with python:

[root@machine ~]# python3 -c 'import crypt; print(crypt.crypt("mynewpassword", crypt.mksalt(crypt.METHOD_SHA512)))'
$6$Xy/Xjk9kArTdnMeh$tZemrVaYPG8kqW0DFxpxGXzurUWYx/3qoYA5xw1KYokYaVS/34jMWrFbrjf95xjOlOrskVAZeXSnKLAPn56pi.

Then you need to locate shadow file for your user and edit it:

root@cpanel [~]# cd /home/test/etc/testdomain.com
root@cpanel [/home/test/etc/testdomain.com]#
root@cpanel [/home/test/etc/testdomain.com]# vi shadow

Here is original hash for our user. You should change it with hash generated in first step. Change part which is marked with bold:

test:$6$o/dl07XTG2tht5ir$GZQ8DCOQQ1FG9U/G87aq0kOiEru8ndwWK8RbrDy6vbl9DCKSDEsejjIxwfvO329a4dONuypsQx9HuUj6MVuqx.:18269::::::

so it looks like this:

test:$6$Xy/Xjk9kArTdnMeh$tZemrVaYPG8kqW0DFxpxGXzurUWYx/3qoYA5xw1KYokYaVS/34jMWrFbrjf95xjOlOrskVAZeXSnKLAPn56pi.:18269::::::

That’s it, you should be able to login in webmail with new password, generated with python – frist step.

Password protect Netdata with NGINX / Permission denied while connecting to upstream error

Netdata is great free tool for generating server statistics. By default it’s open for entire world on port 19999 – http://servername.com:19999. It is not a good idea to leave this open so everyone can your system statistics.

One way to limit access from where it is accessible is by editing netdata.conf and specify IPS in “allow connections from” variable.

[web]
allow connections from = ip's that are allowed to access>

There is no option to password protect it. This can be done with NGINX. You can create reverse proxy, so that nginx will serve content from netdata application. To make netdata accessible on subfolder of your hostname, eg. http://my.hostname.com/netdata, then create nginx configuration like bellow.

First generate password file for nginx:

htpasswd -c /etc/nginx/.htpasswd "username"

Then create or edit existing nginx configuration to something like this:

upstream netdata {
        server 127.0.0.1:19999;
        keepalive 64;
}

server {
     listen 443 ssl http2;
     server_name my.hostname.com;
     location = /netdata {
         return 301 /netdata/;
    }

    location ~ /netdata/(?.*) {

        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;

        proxy_redirect off;
        proxy_set_header Host $host;   

        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_pass_request_headers on;
        proxy_set_header Connection "keep-alive";
        proxy_store off;
        proxy_pass http://netdata/$ndpath$is_args$args;

        gzip on;
        gzip_proxied any;
        gzip_types *;
   }

    error_log /var/log/nginx/error.log;
    access_log off;
    ....

Also, don’t forget to edit netdata.conf and change some variables. Make netdata accessible only from localhost (nginx):

[web]
bind to = 127.0.0.1
allow connections from = localhost
allow dashboard from = localhost

You should also allow connection to port 19999 only to local traffic (localhost).

Restart nginx and netdata, then try to access like: http(s)://my.hostname.com/netdata.

If you’re getting error like bellow in your nginx error log, than chances are that SELinux is active. Disable selinux or execute this command “setsebool -P httpd_can_network_connect true”.

[crit] 8411#0: *1 connect() to 127.0.0.1:19999 failed (13: Permission denied) while connecting to upstream, client: 8.8.8.8, server: my.hostname.com, request: "GET /netdata/ HTTP/1.1", upstream: "http://127.0.0.1:19999/", host: "my.hostname.com"

 

 

 

Create and password protect/encrypt zip archive from command line / stored 0% message

When sending zip archives that contains risky/secure content, you should always encrypt and password protect them. Especially when sending them to clients via email, Dropbox or some other public sharing method. To do that on Linux is very simple. You can do it with commands bellow. When executed you’ll be prompted to enter password.

When adding file, just do this:

zip --encrypt myarchive.zip myfile.txt

But when adding directory with subdirectorys and files, than you should always include “-r” flag to tell zip to use recursion. Otherwise you’ll end up with empty directory and see message like this “adding: behaviour.exchange/ (stored 0%)”

To add directory recursively:

zip --encrypt -r myarchive.zip mydir/

 

SSH without your certificate / overridde ssh certificate

If you want to test if users can ssh to a server with their passwords but your attempt is overridden by your ssh certificate, this is how you can do it.

ssh user@my.hostname.com -o PreferredAuthentications=password

© 2024 geegkytuts.net
Hosted by SIEL


About author