Tag Info

New answers tagged

3

The problem is that curl expects some normal terminal settings and zle doesn't expect you change the terminal settings. So you can write it instead: _check-gmail() { zle -I ( s=$(stty -g) # safe zle's terminal setting stty sane # sane settings for curl curl -u username --silent "https://mail.google.com/mail/feed/atom" | tr -d '\n' ...


0

One approach would be to prompt the user prior to running your _check-gmail function so that your script has the password in hand, in a variable. Then you'd pass the password variable into your function so that the curl command can make use of it. For example: $ tst_fun () { echo "Parameter #1 is $1"; } $ tst_fun "my_pass" Parameter #1 is my_pass $ To ...


2

Are you okay with typing the password when you run it? You can read it in a bash script without making it visible in the terminal, saving to history, etc: #!/bin/bash if ! IFS= read -rs -p "Enter password: " password < /dev/tty 2> /dev/tty then echo "Password entry failed" exit 1 fi somecommand -user me -password $password Looking at the other ...


3

It will not only show up on your screen, but also in ps output, in your ~/.bash_history (though that one should only be readable to you and the admins) and possibly in some audit or performance logs. You should not pass passwords as arguments to commands. Arguments to commands should be considered public knowledge. For mysql, use ~/.my.cnf as Michael has ...


5

A better option than providing the password on the command line at all is to make a ~/.my.cnf file with the credentials in it: [client] password=something That way they are also protected against someone looking at the ps output, or your shell history. That said, you can turn off the watch title entirely with the -t or --no-title option, which will: ...


4

pass is a tool to store passwords in gpg-encrypted single files that can be grouped in folders. The code is written in shell code and follows the Unix philosophy. pass does not have an Android GUI interface but the password files themshelfs could be read using a GPG manager.


0

instead of here documents, try something like this: pw='Abcd$1234' exec 6>&1 ftp -nvi >&6 2>&6 |& print -p open Server print -p user User $pw "lines to ftp file" print -p bye


1

Here documents. cat <<EOF followed by several lines of text, followed by the literal string EOF on a new line, NOT indented. The portion between the EOFs is passed to the command as standard input. If 'EOF' is 'quoted', substitutions WON'T be done; otherwise they are. See <<- for the indented variety. So.. ftp -inv (IP) <<'EOF' ...


2

For Question 1: Just edit /etc/gdm/custom.conf with your favorite editor. Then, under the [daemon] section, add 2 lines so it looks like the code below (obviously change username to the username you want to use): [daemon] AutomaticLoginEnable=true AutomaticLogin=username


1

Technically the default is that sshd does not use PAM. From the sshd_config manpage: UsePAM Enables the Pluggable Authentication Module interface. [...] The default is ``no'' But this option is almost universally enabled by SSH installations by OS distributions and default config files and such. You can check if it's enabled in /etc/ssh/sshd_config if ...


2

Yes. You're correct. Each steps can be split in minor tasks as well, but you describe the overall algorithm.


1

The passwords are stored in the shadow file, not in /etc/passwd, so you need to delete the contents of the second column from /etc/shadow. An entry should look something like this: root::16229:0:99999:7:::


0

While this is possible, it is very rarely the right way to do something. I strongly suspect that you are at best making your life overly complicated and at worst doing something unsafe when you could do the safe thing at no extra cost. SSH lets clients authenticate with a key instead of a password. This is especially useful for automated use: create a key ...


2

Just backup the /etc/shadow file, and change the users passwords with passwd: Backup the shadow file: sudo cp /etc/shadow /etc/shadow.bak Change the password of the user you want to access (e.g. testuser): sudo passwd testuser When done, restore the /etc/shadow file from the backup: sudo mv /etc/shadow.bak /etc/shadow Note that all passwords should ...


2

If there is no /etc/passwd, then your embedded system is not running what is usually known as the Linux system, but rather a different operating system which is also based on the Linux kernel. A famous example of an operating system which uses on the Linux kernel but is not Linux is Android. Android doesn't have user accounts (at least not in its basic ...


2

The algorithm is the same. Modern shadow-suites use pluggable authentication modules (PAM), and PAM lets you configure one hashing algorithm. It's all about "salting", which means randomizing the password to give the very effect that you're asking about. Salting is a counter-measure to dictionary attacks, where an attacker with a dictionary of known ...


8

Separate users means a separate User ID, and therefore separate hashes will be involved with the algorithm. Even a user with the same name, same password, and created at the same time will (with almost certain probability) end up with a different hash. There are other factors that help create the encryption. If you want to look at a quick example here it ...



Top 50 recent answers are included