Re: ssh agent authentication for doas
2015-07-26 13:06 GMT+03:00 David Gwynne da...@gwynne.id.au: On 26 Jul 2015, at 7:41 pm, Vadim Zhukov persg...@gmail.com wrote: 2015-07-26 12:19 GMT+03:00 David Gwynne da...@gwynne.id.au: On 26 Jul 2015, at 7:07 pm, Nicholas Marriott nicholas.marri...@gmail.com wrote: Hi I can't say I know a lot about bsdauth so maybe this is a stupid question, but could this work as a login_* authentication method instead of doas doing it? i had a look at that. the biggest technical problem is that the bsd_auth framework filters all environment variables from the caller before calling the actual auth handler. if i wrote a login_sshagent thing for bsdauth, i cant get at the SSH_AUTH_SOCK env var to be able to talk to the agent. doas (and other programs) would have to be modified to explicitly pass the sockets location as an argument somehow. threading that needle doesnt look like much fun. it was pointed out to me that this isnt that useful anywhere except for doas and sudo, so generalising it has limited benefit. most bsd_auth uses are to authenticate remote users, you dont have a local agent socket to connect to in that situation. Probably a stupid question, but I see the auth_setoption() function that allows to pass parameters to the login script. Can't it be used? yes, that's what i alluded to above. doas would have to be modified to manage the bsd auth session itself rather than simply calling auth_userokay. it would have to check or specify the auth style and provide the extra information as you suggested. getting the list of authorized_keys would have to be rethought too. im still not sure what the general benefit is though. what else could sanely make use of an sshagent bsdauth backend apart from doas? the only thing i can think of is sudo, and it would need to be modified like i described above for doas too. without modification and code specific for this backend, bsd_auth users can't take advantage of it. Now I got it, thank you for explanation. I try to find a reliable and non-intrusive solution but can't, too. :( -- WBR, Vadim Zhukov
Re: ssh agent authentication for doas
Fair enough, thanks.
On Sun, Jul 26, 2015 at 07:19:06PM +1000, David Gwynne wrote:
On 26 Jul 2015, at 7:07 pm, Nicholas Marriott nicholas.marri...@gmail.com
wrote:
Hi
I can't say I know a lot about bsdauth so maybe this is a stupid
question, but could this work as a login_* authentication method instead
of doas doing it?
i had a look at that.
the biggest technical problem is that the bsd_auth framework filters all
environment variables from the caller before calling the actual auth handler.
if i wrote a login_sshagent thing for bsdauth, i cant get at the
SSH_AUTH_SOCK env var to be able to talk to the agent. doas (and other
programs) would have to be modified to explicitly pass the sockets location
as an argument somehow. threading that needle doesnt look like much fun.
it was pointed out to me that this isnt that useful anywhere except for doas
and sudo, so generalising it has limited benefit. most bsd_auth uses are to
authenticate remote users, you dont have a local agent socket to connect to
in that situation.
cheers,
dlg
On Sun, Jul 26, 2015 at 06:43:57PM +1000, David Gwynne wrote:
this is rough, but enough to start a discussion.
this lets doas authenticate a user by talking to their ssh agent
by specifying 'ssh-agent' on a permit line in the config. if agent
auth fails, doas falls back to bsd auth (ie, password auth).
to minimise the amount of code needed in doas, most of the heavy
lifting is handed off to two external programs.
the first is a program that fetches a users keys. it has to be
provided by the system administrator.
doas does not look at ~/.ssh/authorized_keys because that would
allow someone on an unattended shell to modify the current users
keys file to gain whatever privs theyve been granted by doas.
instead, it followes the semantics of sshds AuthorizedKeysCommand
handler.
at work i have an AuthorizedKeysCommand thing that fetches keys
from active directory (ie, an ldap) so users can do key based auth
on all our machines instead of just the ones we nfs export their
homedirs to. doas can use the same backend to fetch the set of keys
the system trusts to auth that user. alternatively, a machine could
have a set of trusted keys for its users that is read from /etc or
such.
the second program is /usr/libexec/doas.sshagent. my implementation
reuses a lot of ssh code and links to libssh.a, so ive currently
got it in src/usr.bin/ssh/doas.sshagent.
it basically reads authorized_keys from stdin and attempts to use
them against the users ssh agent.
if one of the provided keys works, it exits with code 0. if auth
fails, it exits with code 8. every other code is considered an
error.
the code in doas basically creates a pipe to join the stdout of the
authorized_keys command to the stdin of doas.sshagent, and then
waits for the latter to exit with a useful code.
this way avoids having to add a bunch of buffering, string parsing,
and crypto to doas itself. the doas.sshagent code contains that on
its behalf.
anyway, the code is rough, i only just got it all hanging together.
thoughts?
Index: doas/Makefile
===
RCS file: /cvs/src/usr.bin/doas/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- doas/Makefile 16 Jul 2015 20:44:21 - 1.1
+++ doas/Makefile 26 Jul 2015 04:39:17 -
@@ -8,7 +8,6 @@ MAN= doas.1 doas.conf.5
BINOWN= root
BINMODE=4555
-CFLAGS+= -I${.CURDIR}
COPTS+=-Wall
.include bsd.prog.mk
Index: doas/doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas/doas.c24 Jul 2015 06:36:42 - 1.21
+++ doas/doas.c26 Jul 2015 04:39:17 -
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
+#include sys/wait.h
#include limits.h
#include login_cap.h
@@ -26,6 +27,8 @@
#include stdlib.h
#include err.h
#include unistd.h
+#include fcntl.h
+#include signal.h
#include pwd.h
#include grp.h
#include syslog.h
@@ -33,6 +36,8 @@
#include doas.h
+static int ssh_agent(const char *, uid_t, gid_t);
+
static void __dead
usage(void)
{
@@ -291,7 +296,7 @@ main(int argc, char **argv, char **envp)
struct rule *rule;
uid_t uid;
uid_t target = 0;
- gid_t groups[NGROUPS_MAX + 1];
+ gid_t groups[NGROUPS_MAX + 1], gid;
int ngroups;
int i, ch;
int sflag = 0;
@@ -331,7 +336,7 @@ main(int argc, char **argv, char **envp)
ngroups = getgroups(NGROUPS_MAX, groups);
if (ngroups == -1)
err(1, can't get groups);
- groups[ngroups++] = getgid();
+ groups[ngroups++] = gid = getgid();
if (sflag) {
sh = getenv(SHELL);
@@ -360,13 +365,23 @@
ssh agent authentication for doas
this is rough, but enough to start a discussion.
this lets doas authenticate a user by talking to their ssh agent
by specifying 'ssh-agent' on a permit line in the config. if agent
auth fails, doas falls back to bsd auth (ie, password auth).
to minimise the amount of code needed in doas, most of the heavy
lifting is handed off to two external programs.
the first is a program that fetches a users keys. it has to be
provided by the system administrator.
doas does not look at ~/.ssh/authorized_keys because that would
allow someone on an unattended shell to modify the current users
keys file to gain whatever privs theyve been granted by doas.
instead, it followes the semantics of sshds AuthorizedKeysCommand
handler.
at work i have an AuthorizedKeysCommand thing that fetches keys
from active directory (ie, an ldap) so users can do key based auth
on all our machines instead of just the ones we nfs export their
homedirs to. doas can use the same backend to fetch the set of keys
the system trusts to auth that user. alternatively, a machine could
have a set of trusted keys for its users that is read from /etc or
such.
the second program is /usr/libexec/doas.sshagent. my implementation
reuses a lot of ssh code and links to libssh.a, so ive currently
got it in src/usr.bin/ssh/doas.sshagent.
it basically reads authorized_keys from stdin and attempts to use
them against the users ssh agent.
if one of the provided keys works, it exits with code 0. if auth
fails, it exits with code 8. every other code is considered an
error.
the code in doas basically creates a pipe to join the stdout of the
authorized_keys command to the stdin of doas.sshagent, and then
waits for the latter to exit with a useful code.
this way avoids having to add a bunch of buffering, string parsing,
and crypto to doas itself. the doas.sshagent code contains that on
its behalf.
anyway, the code is rough, i only just got it all hanging together.
thoughts?
Index: doas/Makefile
===
RCS file: /cvs/src/usr.bin/doas/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- doas/Makefile 16 Jul 2015 20:44:21 - 1.1
+++ doas/Makefile 26 Jul 2015 04:39:17 -
@@ -8,7 +8,6 @@ MAN=doas.1 doas.conf.5
BINOWN= root
BINMODE=4555
-CFLAGS+= -I${.CURDIR}
COPTS+=-Wall
.include bsd.prog.mk
Index: doas/doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas/doas.c 24 Jul 2015 06:36:42 - 1.21
+++ doas/doas.c 26 Jul 2015 04:39:17 -
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
+#include sys/wait.h
#include limits.h
#include login_cap.h
@@ -26,6 +27,8 @@
#include stdlib.h
#include err.h
#include unistd.h
+#include fcntl.h
+#include signal.h
#include pwd.h
#include grp.h
#include syslog.h
@@ -33,6 +36,8 @@
#include doas.h
+static int ssh_agent(const char *, uid_t, gid_t);
+
static void __dead
usage(void)
{
@@ -291,7 +296,7 @@ main(int argc, char **argv, char **envp)
struct rule *rule;
uid_t uid;
uid_t target = 0;
- gid_t groups[NGROUPS_MAX + 1];
+ gid_t groups[NGROUPS_MAX + 1], gid;
int ngroups;
int i, ch;
int sflag = 0;
@@ -331,7 +336,7 @@ main(int argc, char **argv, char **envp)
ngroups = getgroups(NGROUPS_MAX, groups);
if (ngroups == -1)
err(1, can't get groups);
- groups[ngroups++] = getgid();
+ groups[ngroups++] = gid = getgid();
if (sflag) {
sh = getenv(SHELL);
@@ -360,13 +365,23 @@ main(int argc, char **argv, char **envp)
fail();
}
- if (!(rule-options NOPASS)) {
+ switch (rule-options AUTHMASK) {
+ case NOPASS:
+ break;
+ case SSHAGENT:
+ if (ssh_agent(myname, uid, gid) == 0)
+ break;
+
+ /* FALLTHROUGH */
+ case PASSAUTH:
if (!auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
failed password for %s, myname);
fail();
}
+ break;
}
+
envp = copyenv((const char **)envp, rule);
pw = getpwuid(target);
@@ -385,4 +400,136 @@ main(int argc, char **argv, char **envp)
if (errno == ENOENT)
errx(1, %s: command not found, cmd);
err(1, %s, cmd);
+}
+
+char *keycmd = /etc/doas/sshkeys;
+char *keyuser = _doas;
+char *agentcmd = /usr/libexec/doas.sshagent;
+
+static int
+ssh_agent(const char *myname, uid_t uid, gid_t gid)
+{
+ extern char *__progname;
+ struct passwd *pw;
+ int p[2], devnull;
+ const char *sock;
+ pid_t keys, agent;
+ int status;
+ char *argv [] = { agentcmd, NULL };
+ char *envv[] =
Re: ssh agent authentication for doas
On 26 Jul 2015, at 7:07 pm, Nicholas Marriott nicholas.marri...@gmail.com
wrote:
Hi
I can't say I know a lot about bsdauth so maybe this is a stupid
question, but could this work as a login_* authentication method instead
of doas doing it?
i had a look at that.
the biggest technical problem is that the bsd_auth framework filters all
environment variables from the caller before calling the actual auth handler.
if i wrote a login_sshagent thing for bsdauth, i cant get at the SSH_AUTH_SOCK
env var to be able to talk to the agent. doas (and other programs) would have
to be modified to explicitly pass the sockets location as an argument somehow.
threading that needle doesnt look like much fun.
it was pointed out to me that this isnt that useful anywhere except for doas
and sudo, so generalising it has limited benefit. most bsd_auth uses are to
authenticate remote users, you dont have a local agent socket to connect to in
that situation.
cheers,
dlg
On Sun, Jul 26, 2015 at 06:43:57PM +1000, David Gwynne wrote:
this is rough, but enough to start a discussion.
this lets doas authenticate a user by talking to their ssh agent
by specifying 'ssh-agent' on a permit line in the config. if agent
auth fails, doas falls back to bsd auth (ie, password auth).
to minimise the amount of code needed in doas, most of the heavy
lifting is handed off to two external programs.
the first is a program that fetches a users keys. it has to be
provided by the system administrator.
doas does not look at ~/.ssh/authorized_keys because that would
allow someone on an unattended shell to modify the current users
keys file to gain whatever privs theyve been granted by doas.
instead, it followes the semantics of sshds AuthorizedKeysCommand
handler.
at work i have an AuthorizedKeysCommand thing that fetches keys
from active directory (ie, an ldap) so users can do key based auth
on all our machines instead of just the ones we nfs export their
homedirs to. doas can use the same backend to fetch the set of keys
the system trusts to auth that user. alternatively, a machine could
have a set of trusted keys for its users that is read from /etc or
such.
the second program is /usr/libexec/doas.sshagent. my implementation
reuses a lot of ssh code and links to libssh.a, so ive currently
got it in src/usr.bin/ssh/doas.sshagent.
it basically reads authorized_keys from stdin and attempts to use
them against the users ssh agent.
if one of the provided keys works, it exits with code 0. if auth
fails, it exits with code 8. every other code is considered an
error.
the code in doas basically creates a pipe to join the stdout of the
authorized_keys command to the stdin of doas.sshagent, and then
waits for the latter to exit with a useful code.
this way avoids having to add a bunch of buffering, string parsing,
and crypto to doas itself. the doas.sshagent code contains that on
its behalf.
anyway, the code is rough, i only just got it all hanging together.
thoughts?
Index: doas/Makefile
===
RCS file: /cvs/src/usr.bin/doas/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- doas/Makefile16 Jul 2015 20:44:21 - 1.1
+++ doas/Makefile26 Jul 2015 04:39:17 -
@@ -8,7 +8,6 @@ MAN= doas.1 doas.conf.5
BINOWN= root
BINMODE=4555
-CFLAGS+= -I${.CURDIR}
COPTS+= -Wall
.include bsd.prog.mk
Index: doas/doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas/doas.c 24 Jul 2015 06:36:42 - 1.21
+++ doas/doas.c 26 Jul 2015 04:39:17 -
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
+#include sys/wait.h
#include limits.h
#include login_cap.h
@@ -26,6 +27,8 @@
#include stdlib.h
#include err.h
#include unistd.h
+#include fcntl.h
+#include signal.h
#include pwd.h
#include grp.h
#include syslog.h
@@ -33,6 +36,8 @@
#include doas.h
+static int ssh_agent(const char *, uid_t, gid_t);
+
static void __dead
usage(void)
{
@@ -291,7 +296,7 @@ main(int argc, char **argv, char **envp)
struct rule *rule;
uid_t uid;
uid_t target = 0;
-gid_t groups[NGROUPS_MAX + 1];
+gid_t groups[NGROUPS_MAX + 1], gid;
int ngroups;
int i, ch;
int sflag = 0;
@@ -331,7 +336,7 @@ main(int argc, char **argv, char **envp)
ngroups = getgroups(NGROUPS_MAX, groups);
if (ngroups == -1)
err(1, can't get groups);
-groups[ngroups++] = getgid();
+groups[ngroups++] = gid = getgid();
if (sflag) {
sh = getenv(SHELL);
@@ -360,13 +365,23 @@ main(int argc, char **argv, char **envp)
fail();
}
-if (!(rule-options NOPASS)) {
+switch (rule-options AUTHMASK) {
+case NOPASS:
+break;
+case
Re: ssh agent authentication for doas
2015-07-26 12:19 GMT+03:00 David Gwynne da...@gwynne.id.au: On 26 Jul 2015, at 7:07 pm, Nicholas Marriott nicholas.marri...@gmail.com wrote: Hi I can't say I know a lot about bsdauth so maybe this is a stupid question, but could this work as a login_* authentication method instead of doas doing it? i had a look at that. the biggest technical problem is that the bsd_auth framework filters all environment variables from the caller before calling the actual auth handler. if i wrote a login_sshagent thing for bsdauth, i cant get at the SSH_AUTH_SOCK env var to be able to talk to the agent. doas (and other programs) would have to be modified to explicitly pass the sockets location as an argument somehow. threading that needle doesnt look like much fun. it was pointed out to me that this isnt that useful anywhere except for doas and sudo, so generalising it has limited benefit. most bsd_auth uses are to authenticate remote users, you dont have a local agent socket to connect to in that situation. Probably a stupid question, but I see the auth_setoption() function that allows to pass parameters to the login script. Can't it be used? -- WBR, Vadim Zhukov
doas -n
I don't think it falls on the side of bloat, and it's a pretty nifty option
to sudo...
Index: doas.1
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.10
diff -u -p -r1.10 doas.1
--- doas.1 21 Jul 2015 17:49:33 - 1.10
+++ doas.1 26 Jul 2015 11:13:52 -
@@ -21,7 +21,7 @@
.Nd execute commands as another user
.Sh SYNOPSIS
.Nm doas
-.Op Fl s
+.Op Fl ns
.Op Fl C Ar config
.Op Fl u Ar user
.Ar command
@@ -38,6 +38,10 @@ Parse and check the configuration file
.Ar config ,
then exit.
No command is executed.
+.It Fl n
+Non interactive mode, fail if
+.Nm
+would prompt for password.
.It Fl s
Execute the shell from
.Ev SHELL
Index: doas.c
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas.c 24 Jul 2015 06:36:42 - 1.21
+++ doas.c 26 Jul 2015 11:13:52 -
@@ -295,9 +295,10 @@ main(int argc, char **argv, char **envp)
int ngroups;
int i, ch;
int sflag = 0;
+ int nflag = 0;
uid = getuid();
- while ((ch = getopt(argc, argv, C:su:)) != -1) {
+ while ((ch = getopt(argc, argv, C:nsu:)) != -1) {
switch (ch) {
case 'C':
setresuid(uid, uid, uid);
@@ -307,6 +308,9 @@ main(int argc, char **argv, char **envp)
if (parseuid(optarg, target) != 0)
errx(1, unknown user);
break;
+ case 'n':
+ nflag = 1;
+ break;
case 's':
sflag = 1;
break;
@@ -361,7 +365,7 @@ main(int argc, char **argv, char **envp)
}
if (!(rule-options NOPASS)) {
- if (!auth_userokay(myname, NULL, NULL, NULL)) {
+ if (nflag || !auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
failed password for %s, myname);
fail();
Re: ssh agent authentication for doas
On 26 Jul 2015, at 7:41 pm, Vadim Zhukov persg...@gmail.com wrote: 2015-07-26 12:19 GMT+03:00 David Gwynne da...@gwynne.id.au: On 26 Jul 2015, at 7:07 pm, Nicholas Marriott nicholas.marri...@gmail.com wrote: Hi I can't say I know a lot about bsdauth so maybe this is a stupid question, but could this work as a login_* authentication method instead of doas doing it? i had a look at that. the biggest technical problem is that the bsd_auth framework filters all environment variables from the caller before calling the actual auth handler. if i wrote a login_sshagent thing for bsdauth, i cant get at the SSH_AUTH_SOCK env var to be able to talk to the agent. doas (and other programs) would have to be modified to explicitly pass the sockets location as an argument somehow. threading that needle doesnt look like much fun. it was pointed out to me that this isnt that useful anywhere except for doas and sudo, so generalising it has limited benefit. most bsd_auth uses are to authenticate remote users, you dont have a local agent socket to connect to in that situation. Probably a stupid question, but I see the auth_setoption() function that allows to pass parameters to the login script. Can't it be used? yes, that's what i alluded to above. doas would have to be modified to manage the bsd auth session itself rather than simply calling auth_userokay. it would have to check or specify the auth style and provide the extra information as you suggested. getting the list of authorized_keys would have to be rethought too. im still not sure what the general benefit is though. what else could sanely make use of an sshagent bsdauth backend apart from doas? the only thing i can think of is sudo, and it would need to be modified like i described above for doas too. without modification and code specific for this backend, bsd_auth users can't take advantage of it. dlg -- WBR, Vadim Zhukov
Re: doas -n
On Sun, Jul 26, 2015 at 02:27:55PM +0300, Vadim Zhukov wrote:
2015-07-26 14:15 GMT+03:00 Marc Espie es...@nerim.net:
I don't think it falls on the side of bloat, and it's a pretty nifty option
to sudo...
Index: doas.1
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.10
diff -u -p -r1.10 doas.1
--- doas.1 21 Jul 2015 17:49:33 - 1.10
+++ doas.1 26 Jul 2015 11:13:52 -
@@ -21,7 +21,7 @@
.Nd execute commands as another user
.Sh SYNOPSIS
.Nm doas
-.Op Fl s
+.Op Fl ns
.Op Fl C Ar config
.Op Fl u Ar user
.Ar command
@@ -38,6 +38,10 @@ Parse and check the configuration file
.Ar config ,
then exit.
No command is executed.
+.It Fl n
+Non interactive mode, fail if
+.Nm
+would prompt for password.
.It Fl s
Execute the shell from
.Ev SHELL
Index: doas.c
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas.c 24 Jul 2015 06:36:42 - 1.21
+++ doas.c 26 Jul 2015 11:13:52 -
@@ -295,9 +295,10 @@ main(int argc, char **argv, char **envp)
int ngroups;
int i, ch;
int sflag = 0;
+ int nflag = 0;
uid = getuid();
- while ((ch = getopt(argc, argv, C:su:)) != -1) {
+ while ((ch = getopt(argc, argv, C:nsu:)) != -1) {
switch (ch) {
case 'C':
setresuid(uid, uid, uid);
@@ -307,6 +308,9 @@ main(int argc, char **argv, char **envp)
if (parseuid(optarg, target) != 0)
errx(1, unknown user);
break;
+ case 'n':
+ nflag = 1;
+ break;
case 's':
sflag = 1;
break;
@@ -361,7 +365,7 @@ main(int argc, char **argv, char **envp)
}
if (!(rule-options NOPASS)) {
- if (!auth_userokay(myname, NULL, NULL, NULL)) {
+ if (nflag || !auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
failed password for %s, myname);
fail();
Can't this be achieved with doas -C /etc/doas.conf command ... and
checking if doas will print permit nopass, as it's done in Check if
command is permitted by doas thread on hackers@? I see you want to
fail later rather than sooner, though...
Possibly. What's the point ? that's one sudo option that takes about zero
code to emulate 100%. So why not ?
Update to /etc/services
Hello, Following is a patch to add BFD specific ports (RFC5881) and move RDP entry so the list is ordered. Denis Index: etc/services === RCS file: /cvs/src/etc/services,v retrieving revision 1.93 diff -u -p -r1.93 services --- etc/services31 Dec 2014 11:52:22 - 1.93 +++ etc/services26 Jul 2015 08:52:33 - @@ -228,12 +228,16 @@ eppc 3031/tcp# Remote AppleEvents/PP eppc 3031/udp# Remote AppleEvents/PPC Toolbox iscsi 3260/tcp# ISCSI mysql 3306/tcp# MySQL +rdp3389/tcp# Microsoft Remote Desktop Protocol iapp 3517/tcp802-11-iapp # IEEE 802.11f IAPP iapp 3517/udp802-11-iapp # IEEE 802.11f IAPP daap 3689/tcp# Digital Audio Access Protocol daap 3689/udp# Digital Audio Access Protocol svn3690/tcp# Subversion -rdp3389/tcp# Microsoft Remote Desktop Protocol +bfd-control 3784/tcp # BFD Control Protocol +bfd-control 3784/udp # BFD Control Protocol +bfd-echo3785/tcp # BFD Echo Protocol +bfd-echo3785/udp # BFD Echo Protocol sieve 4190/tcp# ManageSieve Protocol sieve 4190/udp# ManageSieve Protocol krb524 /tcp# Kerberos 5-4
Re: ssh agent authentication for doas
Hi
I can't say I know a lot about bsdauth so maybe this is a stupid
question, but could this work as a login_* authentication method instead
of doas doing it?
On Sun, Jul 26, 2015 at 06:43:57PM +1000, David Gwynne wrote:
this is rough, but enough to start a discussion.
this lets doas authenticate a user by talking to their ssh agent
by specifying 'ssh-agent' on a permit line in the config. if agent
auth fails, doas falls back to bsd auth (ie, password auth).
to minimise the amount of code needed in doas, most of the heavy
lifting is handed off to two external programs.
the first is a program that fetches a users keys. it has to be
provided by the system administrator.
doas does not look at ~/.ssh/authorized_keys because that would
allow someone on an unattended shell to modify the current users
keys file to gain whatever privs theyve been granted by doas.
instead, it followes the semantics of sshds AuthorizedKeysCommand
handler.
at work i have an AuthorizedKeysCommand thing that fetches keys
from active directory (ie, an ldap) so users can do key based auth
on all our machines instead of just the ones we nfs export their
homedirs to. doas can use the same backend to fetch the set of keys
the system trusts to auth that user. alternatively, a machine could
have a set of trusted keys for its users that is read from /etc or
such.
the second program is /usr/libexec/doas.sshagent. my implementation
reuses a lot of ssh code and links to libssh.a, so ive currently
got it in src/usr.bin/ssh/doas.sshagent.
it basically reads authorized_keys from stdin and attempts to use
them against the users ssh agent.
if one of the provided keys works, it exits with code 0. if auth
fails, it exits with code 8. every other code is considered an
error.
the code in doas basically creates a pipe to join the stdout of the
authorized_keys command to the stdin of doas.sshagent, and then
waits for the latter to exit with a useful code.
this way avoids having to add a bunch of buffering, string parsing,
and crypto to doas itself. the doas.sshagent code contains that on
its behalf.
anyway, the code is rough, i only just got it all hanging together.
thoughts?
Index: doas/Makefile
===
RCS file: /cvs/src/usr.bin/doas/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- doas/Makefile 16 Jul 2015 20:44:21 - 1.1
+++ doas/Makefile 26 Jul 2015 04:39:17 -
@@ -8,7 +8,6 @@ MAN= doas.1 doas.conf.5
BINOWN= root
BINMODE=4555
-CFLAGS+= -I${.CURDIR}
COPTS+= -Wall
.include bsd.prog.mk
Index: doas/doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas/doas.c 24 Jul 2015 06:36:42 - 1.21
+++ doas/doas.c 26 Jul 2015 04:39:17 -
@@ -17,6 +17,7 @@
#include sys/types.h
#include sys/stat.h
+#include sys/wait.h
#include limits.h
#include login_cap.h
@@ -26,6 +27,8 @@
#include stdlib.h
#include err.h
#include unistd.h
+#include fcntl.h
+#include signal.h
#include pwd.h
#include grp.h
#include syslog.h
@@ -33,6 +36,8 @@
#include doas.h
+static int ssh_agent(const char *, uid_t, gid_t);
+
static void __dead
usage(void)
{
@@ -291,7 +296,7 @@ main(int argc, char **argv, char **envp)
struct rule *rule;
uid_t uid;
uid_t target = 0;
- gid_t groups[NGROUPS_MAX + 1];
+ gid_t groups[NGROUPS_MAX + 1], gid;
int ngroups;
int i, ch;
int sflag = 0;
@@ -331,7 +336,7 @@ main(int argc, char **argv, char **envp)
ngroups = getgroups(NGROUPS_MAX, groups);
if (ngroups == -1)
err(1, can't get groups);
- groups[ngroups++] = getgid();
+ groups[ngroups++] = gid = getgid();
if (sflag) {
sh = getenv(SHELL);
@@ -360,13 +365,23 @@ main(int argc, char **argv, char **envp)
fail();
}
- if (!(rule-options NOPASS)) {
+ switch (rule-options AUTHMASK) {
+ case NOPASS:
+ break;
+ case SSHAGENT:
+ if (ssh_agent(myname, uid, gid) == 0)
+ break;
+
+ /* FALLTHROUGH */
+ case PASSAUTH:
if (!auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
failed password for %s, myname);
fail();
}
+ break;
}
+
envp = copyenv((const char **)envp, rule);
pw = getpwuid(target);
@@ -385,4 +400,136 @@ main(int argc, char **argv, char **envp)
if (errno == ENOENT)
errx(1, %s: command not found, cmd);
err(1, %s, cmd);
+}
+
+char *keycmd = /etc/doas/sshkeys;
+char *keyuser = _doas;
+char *agentcmd =
Re: Update to /etc/services
Are both TCP and UDP actually used for these? If not, please only list the protocols which are used (not just reserved). On 26 July 2015 09:53:52 BST, Denis Fondras open...@ledeuns.net wrote: Hello, Following is a patch to add BFD specific ports (RFC5881) and move RDP entry so the list is ordered. Denis Index: etc/services === RCS file: /cvs/src/etc/services,v retrieving revision 1.93 diff -u -p -r1.93 services --- etc/services 31 Dec 2014 11:52:22 - 1.93 +++ etc/services 26 Jul 2015 08:52:33 - @@ -228,12 +228,16 @@ eppc 3031/tcp# Remote AppleEvents/PP eppc 3031/udp# Remote AppleEvents/PPC Toolbox iscsi 3260/tcp# ISCSI mysql 3306/tcp# MySQL +rdp 3389/tcp# Microsoft Remote Desktop Protocol iapp 3517/tcp802-11-iapp # IEEE 802.11f IAPP iapp 3517/udp802-11-iapp # IEEE 802.11f IAPP daap 3689/tcp# Digital Audio Access Protocol daap 3689/udp# Digital Audio Access Protocol svn 3690/tcp# Subversion -rdp 3389/tcp# Microsoft Remote Desktop Protocol +bfd-control 3784/tcp # BFD Control Protocol +bfd-control 3784/udp # BFD Control Protocol +bfd-echo3785/tcp # BFD Echo Protocol +bfd-echo3785/udp # BFD Echo Protocol sieve 4190/tcp# ManageSieve Protocol sieve 4190/udp# ManageSieve Protocol krb524/tcp# Kerberos 5-4 -- Sent from a phone, please excuse the formatting.
Re: Update to /etc/services
Are both TCP and UDP actually used for these? If not, please only list the protocols which are used (not just reserved). Only UDP is used currently. Index: services === RCS file: /cvs/src/etc/services,v retrieving revision 1.93 diff -u -p -r1.93 services --- services31 Dec 2014 11:52:22 - 1.93 +++ services26 Jul 2015 19:02:41 - @@ -228,12 +228,14 @@ eppc 3031/tcp# Remote AppleEvents/PP eppc 3031/udp# Remote AppleEvents/PPC Toolbox iscsi 3260/tcp# ISCSI mysql 3306/tcp# MySQL +rdp3389/tcp# Microsoft Remote Desktop Protocol iapp 3517/tcp802-11-iapp # IEEE 802.11f IAPP iapp 3517/udp802-11-iapp # IEEE 802.11f IAPP daap 3689/tcp# Digital Audio Access Protocol daap 3689/udp# Digital Audio Access Protocol svn3690/tcp# Subversion -rdp3389/tcp# Microsoft Remote Desktop Protocol +bfd-control 3784/udp # BFD Control Protocol +bfd-echo3785/udp # BFD Echo Protocol sieve 4190/tcp# ManageSieve Protocol sieve 4190/udp# ManageSieve Protocol krb524 /tcp# Kerberos 5-4
Re: doas -n
26 июля 2015 г. 14:43 пользователь Marc Espie es...@nerim.net написал:
On Sun, Jul 26, 2015 at 02:27:55PM +0300, Vadim Zhukov wrote:
2015-07-26 14:15 GMT+03:00 Marc Espie es...@nerim.net:
I don't think it falls on the side of bloat, and it's a pretty nifty
option
to sudo...
Index: doas.1
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.10
diff -u -p -r1.10 doas.1
--- doas.1 21 Jul 2015 17:49:33 - 1.10
+++ doas.1 26 Jul 2015 11:13:52 -
@@ -21,7 +21,7 @@
.Nd execute commands as another user
.Sh SYNOPSIS
.Nm doas
-.Op Fl s
+.Op Fl ns
.Op Fl C Ar config
.Op Fl u Ar user
.Ar command
@@ -38,6 +38,10 @@ Parse and check the configuration file
.Ar config ,
then exit.
No command is executed.
+.It Fl n
+Non interactive mode, fail if
+.Nm
+would prompt for password.
.It Fl s
Execute the shell from
.Ev SHELL
Index: doas.c
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.21
diff -u -p -r1.21 doas.c
--- doas.c 24 Jul 2015 06:36:42 - 1.21
+++ doas.c 26 Jul 2015 11:13:52 -
@@ -295,9 +295,10 @@ main(int argc, char **argv, char **envp)
int ngroups;
int i, ch;
int sflag = 0;
+ int nflag = 0;
uid = getuid();
- while ((ch = getopt(argc, argv, C:su:)) != -1) {
+ while ((ch = getopt(argc, argv, C:nsu:)) != -1) {
switch (ch) {
case 'C':
setresuid(uid, uid, uid);
@@ -307,6 +308,9 @@ main(int argc, char **argv, char **envp)
if (parseuid(optarg, target) != 0)
errx(1, unknown user);
break;
+ case 'n':
+ nflag = 1;
+ break;
case 's':
sflag = 1;
break;
@@ -361,7 +365,7 @@ main(int argc, char **argv, char **envp)
}
if (!(rule-options NOPASS)) {
- if (!auth_userokay(myname, NULL, NULL, NULL)) {
+ if (nflag || !auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
failed password for %s, myname);
fail();
Can't this be achieved with doas -C /etc/doas.conf command ... and
checking if doas will print permit nopass, as it's done in Check if
command is permitted by doas thread on @? I see you want to
fail later rather than sooner, though...
Possibly. What's the point ? that's one sudo option that takes about zero
code to emulate 100%. So why not ?
Do we want one more ls-like synopsis? :)
More seriously, what's your use case? I see this option needed when
you misconfigure sudo/doas and have some event-driven script try to
read password from stdin. But doas:
1) don't use cookies, thus you can always may be sure that if it
didn't request password before, it won't do it later, too - unless you
change config, current user or his groups, of course.
2) can test if command will be run without password prompt. The latter
allows you checking not only manually, but also using
update-my-doas-conf wrappers. But you can redirect /dev/null for
tests, of course...
So what's your root problem you're solving with -n? Maybe there could
be constructed something better than -n flag? I'm not strongly
objecting the idea, just want to understand the whole picture first.
--
Vadim Zhukov
Re: doas -n
On Sun, Jul 26, 2015 at 03:07:06PM -0400, Ted Unangst wrote:
Marc Espie wrote:
I don't think it falls on the side of bloat, and it's a pretty nifty option
to sudo...
@@ -361,7 +365,7 @@ main(int argc, char **argv, char **envp)
}
if (!(rule-options NOPASS)) {
- if (!auth_userokay(myname, NULL, NULL, NULL)) {
+ if (nflag || !auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
failed password for %s, myname);
fail();
alright, so technical nit. i don't think we want it syslogging in this case. i
would add a separate block just above.
if (nflag)
fail();
or perhaps even better:
if (nflag)
errx(1, Authorization required);
yep, good for me.
Gonna commit this later.
Re: crypto softraid and keydisk on same harddrive
On Sat, Apr 25, 2015 at 10:54:22PM +1000, Joel Sing wrote: Apologies for not getting back to look at this - the above diff is in part a hack and it needs to be more cleanly implemented before it is committed. Additionally, it needs to be implemented and tested for all platforms that support softraid boot. I'll attempt to get this done over the next couple of weeks. Any progress on this? I would be happy to help you test diffs. -- Patrik Lundin
Re: doas -n
On Sun, Jul 26, 2015 at 12:07:44PM -0400, Ted Unangst wrote: Marc Espie wrote: I don't think it falls on the side of bloat, and it's a pretty nifty option to sudo... well, it's not just about code bloat. or even mostly about code bloat. every option added to the program is added to the man page, and then users learning how to use the program must read about each option and decide yes or no. the more options there are, the more people feel like they should study the man page even longer to find the best ones. like panning for gold. -s was added not just because it was small or nifty, but because developers said they relied on it due to muscle memory. its addition made doas better. at least tell me -n is an option you need and not just a nifty addition. I actually have code in make that tried to kill processes started thru sudo that no longer works. It won't go interactive...
Re: Update to /etc/services
Denis Fondras openbsd at ledeuns.net writes: krb524 /tcp# Kerberos 5-4 I would tweak krb524 comment to be # Kerberos 5 to 4 because this is how krb524 reads.
Re: [patch] Remove archaic manual sizing from dump(8)
On 2015-07-23, Michael McConville mmcco...@sccs.swarthmore.edu wrote: --- sbin/dump/main.c23 May 2015 05:17:20 - 1.56 +++ sbin/dump/main.c15 Jun 2015 23:16:10 - @@ -115,7 +115,7 @@ main(int argc, char *argv[]) usage(); obsolete(argc, argv); - while ((ch = getopt(argc, argv, 0123456789aB:b:cd:f:h:ns:ST:uWw)) != -1) + while ((ch = getopt(argc, argv, 0123456789AB:b:cd:f:h:ns:ST:uWw)) != -1) This will break lots of backup scripts. Should -a continue to be supported for some time? Definately. At minimum, as a no-op. Though if it previously acted as any sort of override over other selected options, that might be needed too.
Interactive F option in fsck man pages
It's documented in fsck(8), but not fsck_*(8). This can confuse people. I just copied its paragraph from fsck(8). Index: sbin/fsck_ext2fs/fsck_ext2fs.8 === RCS file: /cvs/src/sbin/fsck_ext2fs/fsck_ext2fs.8,v retrieving revision 1.16 diff -u -p -r1.16 fsck_ext2fs.8 --- sbin/fsck_ext2fs/fsck_ext2fs.8 10 Jan 2010 10:53:33 - 1.16 +++ sbin/fsck_ext2fs/fsck_ext2fs.8 26 Jul 2015 22:55:27 - @@ -166,6 +166,17 @@ this should be used with great caution a to continue after essentially unlimited trouble has been encountered. .El .Pp +If neither of the +.Fl y +or +.Fl n +options are specified, the user may force +.Nm +to assume an answer of +.Dq yes +to all the remaining questions by replying to a question with a value of +.Dq F . +.Pp Inconsistencies checked are as follows: .Pp .Bl -enum -compact Index: sbin/fsck_ffs/fsck_ffs.8 === RCS file: /cvs/src/sbin/fsck_ffs/fsck_ffs.8,v retrieving revision 1.23 diff -u -p -r1.23 fsck_ffs.8 --- sbin/fsck_ffs/fsck_ffs.811 Feb 2013 17:35:46 - 1.23 +++ sbin/fsck_ffs/fsck_ffs.826 Jul 2015 22:55:27 - @@ -216,6 +216,17 @@ this should be used with great caution a to continue after essentially unlimited trouble has been encountered. .El .Pp +If neither of the +.Fl y +or +.Fl n +options are specified, the user may force +.Nm +to assume an answer of +.Dq yes +to all the remaining questions by replying to a question with a value of +.Dq F . +.Pp In interactive mode, .Nm will list the conversion to be made Index: sbin/fsck_msdos/fsck_msdos.8 === RCS file: /cvs/src/sbin/fsck_msdos/fsck_msdos.8,v retrieving revision 1.14 diff -u -p -r1.14 fsck_msdos.8 --- sbin/fsck_msdos/fsck_msdos.816 Jun 2014 18:33:33 - 1.14 +++ sbin/fsck_msdos/fsck_msdos.826 Jul 2015 22:55:27 - @@ -93,6 +93,17 @@ to assume .Dq yes as the answer to all operator questions. .El +.Pp +If neither of the +.Fl y +or +.Fl n +options are specified, the user may force +.Nm +to assume an answer of +.Dq yes +to all the remaining questions by replying to a question with a value of +.Dq F . .Sh SEE ALSO .Xr fs 5 , .Xr fstab 5 ,
Re: ssh agent authentication for doas
David Gwynne wrote: this is rough, but enough to start a discussion. this lets doas authenticate a user by talking to their ssh agent by specifying 'ssh-agent' on a permit line in the config. if agent auth fails, doas falls back to bsd auth (ie, password auth). to minimise the amount of code needed in doas, most of the heavy lifting is handed off to two external programs. ehhh... woah, this is getting complicated fast. the first is a program that fetches a users keys. it has to be provided by the system administrator. at work i have an AuthorizedKeysCommand thing that fetches keys from active directory (ie, an ldap) so users can do key based auth and it sounds like you will be the only user... If we add this, we would need to document it. And worse, users would need to read it. And it would sound cool, but then they'd struggle to set it up and get frustrated. It is, in short, an attractive nuisance. If bsd auth does not suit your needs, then I think that should be the place to focus your efforts.
Re: doas -n
Marc Espie wrote: I don't think it falls on the side of bloat, and it's a pretty nifty option to sudo... well, it's not just about code bloat. or even mostly about code bloat. every option added to the program is added to the man page, and then users learning how to use the program must read about each option and decide yes or no. the more options there are, the more people feel like they should study the man page even longer to find the best ones. like panning for gold. -s was added not just because it was small or nifty, but because developers said they relied on it due to muscle memory. its addition made doas better. at least tell me -n is an option you need and not just a nifty addition.
