Tag Info

New answers tagged

9

Full disk encryption is usually done using the dm-crypt Device Mapper target, with a nested LVM (Logical Volume Manager) inside. So to reset your password you'll have to Unlock/open the crypto container; this is done using cryptsetup Activate the logical volumes; vgchange is used for this. Usually you won't need to care about this. Just let the initrd ...


1

For your information, I opened a bug report on the Fedora bugzilla. The solution is: boot with init=/bin/bash (editing the kernel line in grub) after booting: remount -o remount,rw / passwd root enter the new password twice touch /.autorelabel reboot The last line (creating the .autorelabel file at the root) force a selinux relabelling of the whole ...


1

Yes, there could be a vulnerability in the public-key authentication mechanism of SSH. But there could also be a vulnerability in the password or challenge-response authentication mechanism. So basically on that factor alone, both authentication methods are considered equal. Benefits of public-key authentication The private key is never sent over the wire. ...


6

I think what you're referring to is what's called the challenge-response model. With this approach the key pairs are never exposed in a manner that they could be sniffed off the wire, as is the case with sending a password over the line. And so it's deemed much safer because of this fact. One of the answers to this security SE Q&A titled: Is using a ...


2

Use a gpg-agent and provide your password as: __password=$(gpg --decrypt /path/to/password.gpg) in your script. Of course, you need to previously encrypt it: $ echo "correct_horse_battery_staple" > password $ gpg --encrypt password


5

Adding a little bit of historical perspective, the idea of sleeping after a bad password is not just found in PAM-based systems. It's very old. For eaxmple in the 4.4BSD login source you'll find this tasty fragment: /* we allow 10 tries, but after 3 we start backing off */ if (++cnt > 3) { if (cnt >= 10) { badlogin(username); ...


2

As others have answered, PAM is most likely the cause for this. The actual verification of the password only takes a very short time, the rest is a delay designed to prevent brute force attacks. On Debian, I have the following lines in /etc/pam.d/login: # Enforce a minimal delay in case of failure (in microseconds). # (Replaces the `FAIL_DELAY' setting from ...


2

See this answer on StackOverflow that quotes the The Linux-PAM Module Writers' Guide: As directed by this file, one of more of the modules may fail causing the pam_...() call to return an error. It is desirable for there to also be a pause before the application continues. The principal reason for such a delay is security: a delay acts to discourage brute ...


0

I don't use Archlinux myself, so I don't know exactly, but this sounds like a mechanism against brute-force password guessing.


1

You could use something like expect to provide the credentials each time you want to connect. It's not super secure but gives you what you want. #!/usr/local/bin/expect -- set timeout -1 spawn gvfs-mount {args} expect "User" send "joe\n" expect "Password:" send "xxxxx\n" expect eof Source: gvfs-mount specify username password


2

You can try the following settings, found here: http://fooninja.net/2010/10/07/get-rid-of-wrong-password-delay-in-linux/ Disable delay in Ubuntu and Debian: Edit /etc/pam.d/common-auth and add nodelay: e.g.: auth [success=2 default=ignore] pam_unix.so nullok_secure changed to auth [success=2 default=ignore] pam_unix.so nullok_secure ...



Top 50 recent answers are included