New answers tagged authentication
I can recommend a solution by using Univention Corporate Server (UCS). It is a Debian-based Linux enterprise distribution that integrates an Actice Directory compatible domain using Samba 4. So this could become the centralized Active Directory you are speaking of. As to the LDAP issue, UCS also includes OpenLDAP. This means, you can integrate your existing ...
You could prefix the key with a forced command that tells the user what's going on. For example: command="/usr/bin/printf '*** Your key has been disabled ***\r\n'; sleep 1",no-pty,no-port-forwarding ssh-rsa AAAAB2...19Q== firstname.lastname@example.org Then they get: $ ssh servername PTY allocation request failed on channel 0 Your key has been disabled Connection to ...
Yes you can just put # (or any other character, as long as the initial entry e.g. ssh-rsa is no longer valid), before the relevant line. If you do that, and the system allows for plain text password logins as well, the user will be prompted for a password to login. So you might want to check that there is no (known) password associates with the account.
You fear of an update of shadow-utils is IMO unwarranted. The routines described in that HOWTO are available on my Ubuntu 12.04 and Mint 17 systems without installing anything special. The structure to read /etc/shadow information in a C program can be found in /usr/include/shadow.h and with man 5 shadow and the functions that you would need to find e.g. a ...
Never mind... ldap_default_authtok had an old password in it... (And, that bruise you see in the middle of my forehead is from me pounding my head on my desk...) Okay, now with more detail. I created my LDAP instance consistent with my notes on the subject. That included this bit of LDIF: dn: cn=config changetype: modify replace: ...
Iptables is not like a pam configuration file where the first rule satisfies a procedure. In iptables, ALL rules must be satisfied. This is completely wrong. The rules are traversed in order, and when a rule that matches jumps to one of the built-in targets (ACCEPT, DROP or QUEUE), the processing of the packet ends there: no more rules are traversed. ...
You can setup PAM to do that via PAM-PKCS11 (or alternatively using PAM-P11). Once PAM knows how to verify your credentials against your smartcard, you can use that to login.
LDAP is a directory service (a type of database) along with a protocol that describes what information is stored, how to search it, etc. All kinds of things can be stored there, but in this case it'd be Unix user and group info. Very loosely, an alternative to /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow. Or to NIS. NSS is glibc's name service ...
What you need to do is to regenerate the host keys in the remote server (the server to which you are trying to SSH to) so that its ssh_host_key.pub will change and will give you the Identification Has Changed error. This URL has steps to regenerate the host keys in debian server. Please translate to your version of Linux and it will work for you.
Swap/change host entries in ~/.ssh/known_hosts so that an incorrect IP address is listed for your host: From: 192.168.0.10 ecdsa-sha2-nistp256 AAAAE2...kFr3pqkY= 192.168.0.20 ecdsa-sha2-nistp256 AAAAE2...A82zdls0= To: 192.168.0.20 ecdsa-sha2-nistp256 AAAAE2...kFr3pqkY= 192.168.0.10 ecdsa-sha2-nistp256 AAAAE2...A82zdls0= (Note that the IP addresses has ...
What you can do is to regenerate the server keys (after backing up the previous ones if you need to revert back to them): ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key Edit: @jjlin answer is definitely less intrusive
Probably the easiest way is just to copy another host's key. For example, if you have a known_hosts file with something like 192.168.1.1 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCrkL8HEVk8VP3r... 192.168.1.2 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeL... and you want 192.168.1.2 to show an error, just copy 192.168.1.1's host key, so known_hosts ...
One way is to change the keys on the remote server so when they are verified against the entry in your known_hosts file it won't match and give you that message. Regenerate your host keys on the remote server with something like: ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa ssh-keygen -f ...
Have a look at libpam-script. It allows you to execute scripts during authorization, password changes and sessions. To meet your need, you can build a PAM configuration (in /etc/pam.d/<whatever>) that arranges for this module to execute right before pam_deny only if the normal sequence of modules denies the login.
Top 50 recent answers are included