similar to: HEADS UP: OpenSSH 3.7.1p2

Take the usual precautions when upgrading. Also note that I have changed some configuration defaults: the server no longer accepts protocol version 1 nor password authentication by default. If your ssh client does not support ssh protocol version 2 or keyboard-interactive authentication, the recommended measures are: 1) get a better client 2) get a better client (I mean it) 3) get a better

Nico Kadel-Garcia <nkadel at gmail.com> writes: > Dag-Erling Sm?rgrav <des at des.no> writes: > > Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have > > X11Forwarding enabled by default. > I'm not sure I see your point. With X11Forwarding off by default, one would assume that it is only enabled on a case-by-case basis for users or groups who

Nico Kadel-Garcia <nkadel at gmail.com> writes: > Dag-Erling Sm?rgrav <des at des.no> writes: > > It is relatively trivial to write a PAM module to do that. > Which will have the relevant configuration overwritten and disabled > the next time you run "authconfig" on Red Hat based sysems. I'm not > sure if this occurs with other systems, but tuning PAM is

Lesley Kimmel <lesley.j.kimmel at gmail.com> writes: > So I probably shouldn't have said "arbitrary" script. What I really > want to do is to present a terms of service notice (/etc/issue). But I > also want to get the user to actually confirm (by typing 'y') that > they accept. If they try to exit or type anything other than 'y' they > will be

Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html This Mrdkaaa character claims to have exploited this, but does not say how. The issue is that if do_pam_account() fails, do_authloop() will call packet_disconnect() with loginmsg as the format string (classic printf(foo) instead of printf("%s", foo) bug). The stuff that do_authloop() appends to loginmsg is harmless (the user

Nico Kadel-Garcia <nkadel at gmail.com> writes: > I'm just trying to figure out under what normal circumstances a > connection with X11 forwarding enabled wouldn't be owned by a user who > already has normal system privileges for ssh, sftp, and scp access. Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have X11Forwarding enabled by default. DES --

FreeBSD's <sys/capability.h> was renamed to <sys/capsicum.h> a few years ago to avoid future conflicts with POSIX capabilities. There is still a stub for compatibility, but it would be better not to rely on it. DES -- Dag-Erling Sm?rgrav - des at des.no -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-capsicum_h.diff Type: text/x-patch

Slawa Olhovchenkov <slw at zxy.spb.ru> writes: > IMHO, ntp.conf need to include some numeric IP of public ntp servers. https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse https://en.wikipedia.org/wiki/Poul-Henning_Kamp#Dispute_with_D-Link DES -- Dag-Erling Sm?rgrav - des at des.no

Slawa Olhovchenkov <slw at zxy.spb.ru> writes: > IMHO, ntp.conf need to include some numeric IP of public ntp servers. https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse https://en.wikipedia.org/wiki/Poul-Henning_Kamp#Dispute_with_D-Link DES -- Dag-Erling Sm?rgrav - des at des.no

I want to ssh from a client to a machine on a closed network via a jumphost; let's call them {client,internal,jumphost}.example.com. I have authpf set up on the jumphost so that when logged in, I am allowed to open TCP connections from the jumphost to port 22 on internal nodes. This works well with port forwarding: des at client ~% ssh -L2222:internal.example.com:22 jumphost.example.com

We still have MD5 as our default password hash, even though known-hash attacks against MD5 are relatively easy these days. We've supported SHA256 and SHA512 for many years now, so how about making SHA512 the default instead of MD5, like on most Linux distributions? Index: etc/login.conf =================================================================== --- etc/login.conf (revision

If an ssh1 client initiates challenge-response authentication but does not submit a response to the challenge, and instead switches to some other authentication method, verify_response() will never run, and the kbdint device context will never be freed. In some cases (such as when the FreeBSD PAM authentication code is being used) this may cause a resource leak leading to a denial of service.

Contrast http://cvsweb.mindrot.org/index.cgi/openssh/monitor_fdpass.c?r1=1.23;r2=1.24 with http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/monitor_fdpass.c.diff?r1=1.14&r2=1.15 The original replaces cmsgbuf.tmp with cmsgbuf.buf, while the -portable version *adds* cmsgbuf.buf but retains cmsgbuf.tmp. I assume this was an oversight, and cmsgbuf.tmp should be removed? DES -- Dag-Erling

defines.h defines a bunch of IPTOS constants if they're not already available: #ifndef IPTOS_LOWDELAY # define IPTOS_LOWDELAY 0x10 # define IPTOS_THROUGHPUT 0x08 # define IPTOS_RELIABILITY 0x04 # define IPTOS_LOWCOST 0x02 # define IPTOS_MINCOST IPTOS_LOWCOST #endif /* IPTOS_LOWDELAY */ A few lines further down, it includes <netinet/ip.h>, which

I was scanning through my config.h and noticed something that startled me a bit. The configure script actually checks what sizeof(char) is, and defines.h relies on this information. This is completely unnecessary. By definition, sizeof(char) is always 1. This is not a matter of opinion; the C standard explicitly states, in ?6.5.3.4 alinea 3, When applied to an operand that has type char,

Normally, in the !UseLogin case on a system with login classes, the umask is set implicitly by the first setusercontext() call in do_setusercontext() in session.c. However, FreeBSD treats the umask differently from other login settings: unless running with the target user's UID, it will only apply the value from /etc/login.conf, not that from the user's ~/.login.conf. The patch below

With an OpenSSH 6.2p1 client with stock ssh_config and one of the following cases: - I don't have any client keys - I have one or more client keys, but not one of each type - I don't have an authorized_keys on the server - I have an authorized_keys on the server, but it does not list any of the keys I have - One of my client keys is listed, but I don't have an agent and

6.2p2 prints the same version string in the debugging output as it does when invoked with -V: % ssh -V OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 % ssh -v nonesuch |& head -1 OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 6.3p1 and newer don't - I don't have anything at hand that runs 6.3p1, but here are 6.[456]p1: % ssh -V OpenSSH_6.4p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 % ssh -v

Currently, sshd requires the chroot directory to be owned by root. This makes it impossible to chroot users into their own home directory, which would be convenient for sftp-only users. Is there a particular reason why, in safely_chroot() in session.c, if (st.st_uid != 0 || (st.st_mode & 022) != 0) fatal("bad ownership or modes for chroot "

#include <errno.h> was removed from includes.h in July: ---------------------------- revision 1.113 date: 2006/07/12 12:22:46; author: dtucker; state: Exp; lines: +1 -2 - stevesk at cvs.openbsd.org 2006/07/11 20:07:25 [scp.c auth.c monitor.c serverloop.c sftp-server.c sshpty.c readpass.c sshd.c monitor_wrap.c monitor_fdpass.c ssh-agent.c ttymodes.c atomicio.c includes.h