Tag Info

Hot answers tagged

50

This is a security thing, it's not actually taking long to realize it. 2 vulnerabilities this solves: this throttles login attempts, meaning someone can't pound the system as fast as it can go trying to crack it (1M attempts a sec? idk). If it did it as soon as it verified your credentials were incorrect, you could use the amount of time it took for it to ...


26

This is intentional, to try and limit brute forcing. You can usually modify it by looking for the FAIL_DELAY configuration entry in /etc/login.defs and changing its value (mine is 3 seconds by default), although the comment in that file makes it sound like PAM will enforce at least a 2 second delay no matter what


22

This is not a limitation on the part of your SSH server, this is a limitation on the part of your server's method to encrypt passwords. When encrypting passwords on Unix, the crypt() function is called. This may use one of many backends, a possibility is using DES, or another limiting algorithm (for this particular case, I will assume your server is using ...


21

If you go into the sshd config file (usually /etc/ssh/sshd_config) and change the LogLevel directive to VERBOSE: LogLevel VERBOSE ...you can see something like this in the logs: Jun 24 22:43:42 localhost sshd[29779]: Found matching RSA key: d8:d5:f3:5a:7e:27:42:91:e6:a5:e6:9e:f9:fd:d3:ce Jun 24 22:43:42 localhost sshd[29779]: Accepted publickey for ...


21

You can do any one of these four things: Log in as a user that is in the wheel group and fix it from there Log in as root from the console/ILO Boot off of a CD, mount /etc and fix /etc/group Restore /etc/passwd and /etc/shadow from the most recent backup


17

I suspect you're OS is using DES password encryption, which only supports a maximum of 8 characters. http://serverfault.com/questions/361591/ssh-accepts-only-the-half-password From man crypt(3) GNU EXTENSION The glibc2 version of this function has the following additional features. If salt is a character string starting with the ...


16

Use of passwd -d is plain wrong , at least on Fedora, on any linux distro based on shadow-utils. If you remove the password with passwd -d, it means anyone can login to that user (on console or graphical) providing no password. In order to block logins with password authentication, run passwd -l username, which locks the account making it available to the ...


11

I think I should add a bit of a narrative to the link in 9000's answer. First, check in home to see if you have a folder named .ssh with files inside. If .ssh doesn't exist, you don't have any key set up, so you have to generate a pair using ssh-keygen (it defaults to create the keys in ~/.ssh, you can give the keys a password or not). This will give you a ...


9

You can use the Match option in sshd_config Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.[1] So, at the end of that file you could specify: Match User ...


8

The whole point of the shadow password file is that getpwnam doesn't return passwords from it. You need to look at man 3 shadow and getspnam in particular.


8

Some scripts for proper installation There is a full useable method to track/log ssh connections by key with expention to username. Introduction In addition to @Caleb 's anwer, I would like to share some little tricks there: Nota: I'm working on Debian 6.0. Server installation SSHD Log level First ensuring that server config has sufficient logging ...


8

Authentications that can continue: publickey The first instance of the “Authentications that can continue” message only lists public keys. So the server is set up not to accept any other authentication method such as passwords. If the server accepted passwords as well, you'd instead see: Authentications that can continue: publickey,password ...


8

You can do this using the PermitRootLogin directive. From the sshd_config manpage: Specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “forced-commands-only”, or “no”. The default is “yes”. If this option is set to “without-password”, password authentication is disabled for root. The following ...


8

If you don't want to change groups or use sudo, use a pam module called pam_exec to execute external scripts in a pam stage. Add a line in your /etc/pam.d/su after the pam_rootok.so line: auth sufficient pam_exec.so quiet /path/to/script /path/to/script has the permissions 755 (rwxr-xr-x) and the following content: #!/bin/bash if [ "$PAM_TYPE" == ...


7

For a moment, I thought that this might be inherited from the GDM configuration (since the GDM login screen does the same thing), but apparently it's not. After checking a few other places without any luck, I decided to find out for myself and took a look at the source code(v2.30). The code responsible for the shaking only checks to make sure the dialog ...


7

Turn to key-based authentication.


7

You're right: /etc/passwd and /etc/shadow are consulted by pam_unix.so, which are part of PAM. At least on modern Linuxes. You could change this by patching pam_unix.so. If the manpage is to be believed, you can't change the location of the system databases. And you really don't want to. /etc/passwd isn't just used for authentication, it's also used for ...


7

What you are trying to do is insecture in itself and really shouldn't be done. In that light, maybe you want to rethink your requirements on "secure". Why on earth bother with sudo? You can set up a (second) SSH server which accepts login as root user, but with public key authentication only. That way you don't need to transmit passwords at all and just log ...


6

I was experimenting with the RSA SecurID modules in my PAM configuration a while back, and successfully created exactly this behavior for myself, so I know one way to replicate what you're seeing. If you have a pam module that fails (returns PAM_AUTH_ERR) as either the only configured required module or as requisite before anything else (or in a number of ...


6

You can make ssh connections within a cron session. What you need is to setup a public key authentication to have passwordless access. For this to work, you need to have PubkeyAuthentication yes in each remote server's sshd_config. You can create a private/public key pair with or without a passphrase. If you use a passphrase (recommented) you need to also ...


6

There are several parts to what login programs do. Login programs differ in how they interact with the user who's trying to log in. Here are a few examples: login: reads input on a text terminal su: invoked by an already logged-in users, gets most of the data from its command-line arguments, plus authentication data (password) from a terminal gksu: similar ...


6

Whew. I solved the problem. It amounts to a config but within /etc/pam.d/vsftpd Because ssh sessions succeeded while ftp sessions failed, I went to /etc/pam.d/vsftpd, removed everything that was there and instead placed the contents of ./sshd to match the rules precisely. All worked! By method of elimination, I found that the offending line was: ...


6

Go with what's already setup, if ssh on the work box is already an open/monitored/supported/audited service then try to do the rsync via that. Not opening up new ports/services is generally safest. Not opening up insecure protocols to the internet is even better =) You can get ssh access to the ReadyNas (if you don't mind some hassle from Netgear in the ...


6

su requires the password of the account whose privileges you are trying to assume (apparently root in this case). sudo requires the password of the current user - that is, the password for user kshitiz. By running sudo su, you are effectively becoming root, then running su to get a root shell - that is, your privileges are already elevated to root before ...


6

If I'm not wrong, there are some slight differences between su and sudo: su only allows changing the user id (to become superuser for example). su allows any user that knows the password of another user to become that user, and there is no way to control this. sudo allows running a command as another user (including root). sudo is controlled by the ...


6

Yes, it's normal. The root user can do anything (including, say, changing a user's password, logging in as them, and changing it back), so they aren't restricted by su (or sudo). That includes password prompts and any other restrictions. The PAM configuration can be set up to have su present certain prompts to the root user still, for example encryption ...


5

I suspect that your sshd is configured to allow access via public key authentication and to disallow access via password. There are a couple of thiongs that you can do. The better option is to generate a key-pair for the new account and to copy the public key to your remote host ~/.ssh/authorized_keys file. You can use ssh-keygen or puttygen etc to generate ...


5

When you call into Linux-PAM for some authentication procedure, there is always one and only one stack that is run. The stack definition is looked up in these places; the first successful attempt determines which file is read: the file in /etc/pam.d named after the application "service name" (e.g., sshd or gdm), or the file /etc/pam.d/other if no ...


5

Look at the logs generated when you try to log in (they're in /var/log, I think /var/log/auth.log but the name might be different on CentOS). Do you keep /etc under version control? If you do, check what's changed. If you don't, consider doing it in the future. I recommend etckeeper. Since this is a virtual machine, try mounting its filesystem on the host ...


5

An easy way to find encrypted empty or weak passwords is to use a password cracker like John the Ripper. If you are using NIS or LDAP you need first to extract the password hashes from the database - one way is via getent, see the answer from maxschlepzig



Only top voted, non community-wiki answers of a minimum length are eligible