similar to: Proposal: always handle keys in separate process

How about using the existing OpenSSH client's PKCS#11 support to isolate keying material in a dedicated process? A similar approach, "Practical key privilege separation using Caml Crush", was discussed at FOSDEM'15 with a focus on Heatbleed [1][2] but the ideas and principles are the same. Now this is easily done using the following available components: - SoftHSM to store

Hello, at my universities CS computer pools we're trying to migrate our samba3 based NT domain to AD with samba4-rc1. In the past we had a little script which our users could run on their own from their linux account which created a samba user with their own uid/gid and set their password (via smbpasswd). We're trying to recreate this behaviour with "samba-tool user create"

On 2018-08-21T06:21, Stef Bon <stefbon at gmail.com> wrote: > Op di 21 aug. 2018 om 06:04 schreef Stef Bon <stefbon at gmail.com>: > > > > Hi, > > > > I'm looking for a procedure (on paper first) to provide users on hosts > > session keys to login to servers providing services like file, print > > or even access to internet or a sql db. >

Hello, When trying out (g)pxelinux using TFTP URLs and the '<host>::<path>' syntax, pxelinux seemed to "hang". Some printf debugging and tcpdump revealed that it looped in the timeout after sending the TFTP RRQ. Further investigation revealed, that if a plain IP address (e.g. "tftp://12.34.56.78/something") is used, the byte order is not converted from host

As far as I can tell when the ssh command uses an agent to authenticate to a server and then forwards an agent to that server, it will always use the same agent for both purposes. Has there been any attempt to make it possible for the ssh command to use two different agents, such that I can use one agent to authenticate and then forward a different agent to the server? -- Kasper Dupont --

Hi, Someone told me that DSA keys were being deprecated with OpenSSH 7.0. The only reference I could find about this topic on openSSH site is on the legacy page: ?OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.? There is no explanation about the weakness. But more than that, I could not find any mention

On Sat, Nov 26, 2016 at 1:16 AM, Alexander Wuerstlein <arw at cs.fau.de> wrote: [...] > Afaik its because DSA key size has (for very weird reasons admittedly: > FIPS 186-4) been limited to 1024 bits which is considered weak nowadays. Use of DSA within the SSH protocol requires the use of SHA1, which is 160 bits (80 bits against a birthday attack) and is reaching its use-by date. This

Hello, I'd like to announce "nutdown", a nut client written using perl UPS::Nut. It's purpose is to enable shutdowns in stages, e.g. "less important servers shut down at 80% charge, the important ones at 10% and the nut server at 5%". To that end, nutdown supports "events" like power_fail, the charge falling below configurable percentages (i.e. every

Alon, On 12/18/2018 06:52 PM, Alon Bar-Lev wrote: > OK... So you have an issue... > > First, you need to delegate your smartcard to remote machine, probably > using unix socket redirection managed by openssh. This can be done in > many levels... > 1. Delegate USB device, this will enable only exclusive usage of the > smartcard by remote machine. > 2. Delegate PC/SC, this

Hi Alexander Wuerstlein Thank for the information. Now I agree that it's better to save the socket in /tmp/ I checked the source code and found that it is hard-coded. /* Allocate a buffer for the socket name, and format the name. */ auth_sock_dir = xstrdup("/tmp/ssh-XXXXXXXXXX"); It would be nice if openssh provides an option to overwrite this default. Regards Tran

The idea behind this change is to add support for different "ssh-agents" being able to run at the same time. It does not change the current behaviour of the ssh-agent (which will set SSH_AUTH_SOCK just for itself). Neither does it change the behaviour of SSH_AGENT_PID (which still supports only one pid). The new implementation will go through the list of sockets (which are separated by a

Hi Team, We are having compile/linking time warning due unsatisfied system calls and macros. We have checked and confirm that these are not supported by hp-ux kernel and enabling them will require changes in VFS layer and physical filesystem. Unsatisfied system calls * renameat * symlinkat * linkat * unlinkat * readlinkat * mkdirat Undefined

This patchset allow syscalls (flock, ipc, getuid, geteuid and ioctl), so openssl engines, e.g. OpenSSL-ibmca and OpenSSL-ibmpkcs11, can work and communicate with the crypto cards during ssh login. 1. The flock and ipc are allowed only for s390 architecture. They are needed for openCryptoki project (PKCS#11 implementation), as the ibmpkcs11 engine makes use of openCryptoki. For more information,

I've committed this diff. Please test and confirm that it works ok. (If not, then I've botched the macro fixes in the previous commit) Thanks, Damien Miller On Tue, 14 Mar 2017, Damien Miller wrote: > ok, with the fixes for the seccomp-bpf sandbox that I just committed > the diff reduces to. > > IMO this is scoped narrowly enough to go in. > > -d > > diff

This patch enables specific ioctl calls for ICA crypto card on s390 platform. Without this patch, users using the IBMCA engine are not able to perform ssh login as the filter blocks the communication with the crypto card. Signed-off-by: Harald Freudenberger <freude at linux.vnet.ibm.com> Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com> --- sandbox-seccomp-filter.c |

On 03-03-2017 09:54, Petr Cerny wrote: > Damien Miller wrote: >> On Tue, 28 Feb 2017, Eduardo Barretto wrote: >> >>> On 13-02-2017 13:23, Eduardo Barretto wrote: >>> > This patch enables specific ioctl calls for ICA crypto card on s390 >>> > platform. Without this patch, users using the IBMCA engine are not >>> able >>> > to

On Tue, 28 Feb 2017, Eduardo Barretto wrote: > On 13-02-2017 13:23, Eduardo Barretto wrote: > > This patch enables specific ioctl calls for ICA crypto card on s390 > > platform. Without this patch, users using the IBMCA engine are not able > > to perform ssh login as the filter blocks the communication with the > > crypto card. > > > > Signed-off-by: Harald

https://bugzilla.mindrot.org/show_bug.cgi?id=3430 Bug ID: 3430 Summary: 64 bit time and seccomp conflict Product: Portable OpenSSH Version: 8.9p1 Hardware: ARM OS: Linux Status: NEW Severity: major Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2069 Bug ID: 2069 Summary: arm support for sandbox_seccomp_filter Classification: Unclassified Product: Portable OpenSSH Version: 6.1p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd

https://bugzilla.mindrot.org/show_bug.cgi?id=3085 Bug ID: 3085 Summary: seccomp issue after upgrading openssl Product: Portable OpenSSH Version: 8.1p1 Hardware: Other OS: Linux Status: NEW Severity: critical Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org