similar to: [Bug 442] sshd allows login via public-key when account locked

http://bugzilla.mindrot.org/show_bug.cgi?id=442 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-23 22:53 -------

http://bugzilla.mindrot.org/show_bug.cgi?id=442 Summary: sshd allows login via public-key when account locked Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=442 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 12:19

http://bugzilla.mindrot.org/show_bug.cgi?id=442 ------- Additional Comments From dtucker at zip.com.au 2002-11-24 14:25 ------- Created an attachment (id=181) --> (http://bugzilla.mindrot.org/attachment.cgi?id=181&action=view) Test for locked account in allowed_user() Tested on Redhat 8 and Solaris 8. ------- You are receiving this mail because: ------- You are the assignee for

Hi! I'm using Openssh v3.5p1 with Solaris 8 compiled with pam support enabled. It seems that if I use public key authentication I can log in to an account that is locked (/etc/shadow has *LK* as password). Login is also allowed even if the user does not have a valid shell. Is this a bug or am I missing something? -- Osmo Paananen

Hi Damien, I noticed you merged a couple of ifdefs in the fix for bug #442. The cvs comment says "Fix Bug #442 for PAM case". The code is now roughly: #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) spw = getspnam(pw->pw_name); passwd = spw->sp_pwdp; #else passwd =

http://bugzilla.mindrot.org/show_bug.cgi?id=278 Darren.Moffat at Sun.COM changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From Darren.Moffat at Sun.COM

I just ran into what I'd describe as an unexpected side-effect. I don't think it's necessarily a bug, and I don't need any assistance in working around it, but this information might be useful to others for troubleshooting. This was using OpenSSH built under Solaris 2.5.1, and running under 2.5.1 or 8. The symptom was that after upgrading from 3.7.1p1 to 3.7.1p2, some accounts

>Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the >'passwd -l ...' command to lock the users password. However, the user can >still access the system via ssh. Whilst I could do other things such as >moving their .ssh directory, removing their account home directory, etc, >etc, is there some 'nicer' way to inform ssh that the account is now

(I'm not subscribed to the list, please Cc me on replies). We have configured sshd to listen on port 80 for some of our users who are behind sufficiently paranoid firewalls. However, others are now confused since they're expecting a web server on port 80. So, I created a small patch (just as proof-of-concept so far), that determines the type of client connecting. A web client will start

Hi... Started playing with gluster. And the heal functions is my "target" for testing. Short description of my test ---------------------------- * 4 replicas on single machine * glusterfs mounted locally * Create file on glusterfs-mounted directory: date >data.txt * Append to file on one of the bricks: hostname >>data.txt * Trigger a self-heal with: stat data.txt =>

--- sshd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sshd.c b/sshd.c index dda8d9b77..cbdced5db 100644 --- a/sshd.c +++ b/sshd.c @@ -1533,6 +1533,8 @@ main(int ac, char **av) } else { do_log2(ll, "Unable to load host key: %s", options.host_key_files[i]); + sshkey_free(pubkey); + pubkey = NULL; sensitive_data.host_keys[i] = NULL;

Will copy these to http://wiki.centos.org/SpecialInterestGroup/Virtualization, after intial discussion or just point to the e-mail/email thread from the wiki. Feel free to correct as needed. Lars == Attendees == SIG Members: * LarsKurth (LK) * GeorgeDunlap (GD) * KaranbirSingh (KB) Travelling: * JohnnyHughes (JH) Guest * EuanHarris === Meeting time and cadence === Meetings will be

Hi all! I have setup a replicated/distributed gluster cluster 2 x (2 + 1). Centos 7 and gluster version 3.12.6 on server. All machines have two network interfaces and connected to two different networks, 10.10.0.0/16 (with hostnames in /etc/hosts, gluster version 3.12.6) 192.168.67.0/24 (with ldap, gluster version 3.13.1) Gluster cluster was created on the 10.10.0.0/16 net, gluster peer probe

How can I configure the dovecot for working with maildir's through NFS? If I add option "index_mmap_invalidate = yes" (as in doc/nfs.t) then in log I have this message: "Error: Error in configuration file /etc/dovecot.conf line 296: Unknown setting: index_mmap_invalidate" If I try to get the mail without option "index_mmap_invalidate" then I have in log this

Keep in mind a local disk is 3,6,12 Gbps but a network connection is typically 1Gbps. A local disk quad in raid 10 will outperform a 10G ethernet (especially using SAS drives). On December 5, 2017 6:11:38 AM EST, Riccardo Murri <riccardo.murri at uzh.ch> wrote: >Hello, > >I'm trying to set up a SAMBA server serving a GlusterFS volume. >Everything works fine if I locally

On Tue, 2017-12-05 at 11:11 +0000, Riccardo Murri wrote: > Hello, > > I'm trying to set up a SAMBA server serving a GlusterFS volume. > Everything works fine if I locally mount the GlusterFS volume (`mount > -t glusterfs ...`) and then serve the mounted FS through SAMBA, but > the performance is slower by a 2x/3x compared to a SAMBA server with a > local ext4 filesystem.

I have a situation where a number of potentially hostile clients ssh to a host I control, each ssh'ing in as the same user, and each forwarding a remote port back to them. So, the authorized_keys file looks like: no-agent-forwarding,command="/bin/true",no-pty,no-user-rc,no-X11-forwarding,permitopen="127.0.0.1:7" ssh-rsa AAAAB....vnRWxcgaK9xXoU= client1234 at example.com

Hi folks, Following an upgrade from Debian squeeze to wheezy, and Asterisk 1.6.2.9 to 1.8.13, my server is no longer able to register a connection to a SIP account at my ISP (XS4ALL in the Netherlands). At the same time, it is still able to register a different account with another SIP provider, so it must be that they no longer have the same basic requirements. The relevant part of my

[This is something like a bug report; maybe somewhat longish & technical ..] As an introduction, just try the following code (it should work both in R and S). I think it screws up the postscript() driver both for S and R, but this is not the issue here. is.R <- function() { ## returns 'TRUE' iff we are using 'R' exists("version") && !is.null(vl