From weiler at soe.ucsc.edu Sat Jul 1 00:04:20 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Fri, 30 Jun 2006 07:04:20 -0700 Subject: OpenSSH public key problem with Solaris 10 Message-ID: <44A52F64.1080907@soe.ucsc.edu> Hi ya'll- I've got this odd openssh problem with Solaris 10 I was hoping someone could shed some light on. Not sure if it is a bug... Basically I'm trying to use pubkeys as an auth method, but am having issues. I can log in using passwords no problem, but as soon as it notices a matching public key it closes the connection. I ran the sshd server (on Solaris 10 box) in debug mode and got this output when I tried to log in: % sshd -d debug1: sshd version OpenSSH_4.3p2 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/local/openssh.10/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on ::. Server listening on :: port 22. debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: fd 6 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 11 debug1: inetd sockets after dupping: 4, 4 Connection from 128.114.48.86 port 49490 debug1: Client protocol version 2.0; client software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_4.3 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user weiler service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "weiler" debug1: PAM: setting PAM_RHOST to "banshee.cse.ucsc.edu" debug1: PAM: setting PAM_TTY to "ssh" Failed none for weiler from 128.114.48.86 port 49490 ssh2 Failed none for weiler from 128.114.48.86 port 49490 ssh2 debug1: userauth-request for user weiler service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 3495/100 (e=0/0) debug1: trying public key file /cse/tstaff/weiler/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 3495/100 (e=0/0) debug1: trying public key file /cse/tstaff/weiler/.ssh/authorized_keys2 debug1: matching key found: file /cse/tstaff/weiler/.ssh/authorized_keys2, line 2 Found matching RSA key: 4d:c0:33:3b:dd:75:89:bb:d1:36:e7:17:2b:85:34:9c debug1: restore_uid: 0/0 Postponed publickey for weiler from 128.114.48.86 port 49490 ssh2 debug1: userauth-request for user weiler service ssh-connection method publickey debug1: attempt 2 failures 1 debug1: temporarily_use_uid: 3495/100 (e=0/0) debug1: trying public key file /cse/tstaff/weiler/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 3495/100 (e=0/0) debug1: trying public key file /cse/tstaff/weiler/.ssh/authorized_keys2 debug1: matching key found: file /cse/tstaff/weiler/.ssh/authorized_keys2, line 2 Found matching RSA key: 4d:c0:33:3b:dd:75:89:bb:d1:36:e7:17:2b:85:34:9c debug1: restore_uid: 0/0 debug1: ssh_rsa_verify: signature correct debug1: do_pam_account: called Access denied for user weiler by PAM account configuration debug1: do_cleanup debug1: PAM: cleanup Failed publickey for weiler from 128.114.48.86 port 49490 ssh2 debug1: do_cleanup debug1: PAM: cleanup % Again, If I move my public key out of the way and try to log in with a password it works fine. Since it mentions my PAM configuration, here's my /etc/pam.conf file: login auth requisite pam_authtok_get.so.1 login auth required pam_unix_cred.so.1 login auth sufficient pam_unix_auth.so.1 login auth sufficient pam_krb5.so.1 login auth sufficient pam_ldap.so.1 # dtsession auth sufficient pam_unix_auth.so.1 dtsession auth sufficient pam_krb5.so.1 dtsession auth sufficient pam_ldap.so.1 # # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_cred.so.1 rlogin auth required pam_unix_auth.so.1 # # Kerberized rlogin service # krlogin auth required pam_unix_cred.so.1 krlogin auth binding pam_krb5.so.1 krlogin auth required pam_unix_auth.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_cred.so.1 # # Kerberized rsh service # krsh auth required pam_unix_cred.so.1 krsh auth binding pam_krb5.so.1 krsh auth required pam_unix_auth.so.1 # # Kerberized telnet service # ktelnet auth required pam_unix_cred.so.1 ktelnet auth binding pam_krb5.so.1 ktelnet auth required pam_unix_auth.so.1 # # PPP service (explicit because of pam_dial_auth) # ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_cred.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authentication # other auth requisite pam_authtok_get.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_unix_auth.so.1 other auth sufficient pam_krb5.so.1 other auth sufficient pam_ldap.so.1 # # passwd command (explicit because of a different authentication module) # passwd auth sufficient pam_passwd_auth.so.1 passwd auth sufficient pam_ldap.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # passwd account sufficient pam_unix_account.so.1 passwd account sufficient pam_ldap.so.1 # other account sufficient pam_unix_account.so.1 other account sufficient pam_ldap.so.1 other account sufficient pam_krb5.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session sufficient pam_unix_session.so.1 other session sufficient pam_ldap.so.1 other session sufficient pam_krb5.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 Would any of you guys happen to have a clue as to where I'm going wrong? Thanks a million in advance! ciao, erich From dtucker at zip.com.au Sat Jul 1 00:34:53 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 1 Jul 2006 00:34:53 +1000 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <44A52F64.1080907@soe.ucsc.edu> References: <44A52F64.1080907@soe.ucsc.edu> Message-ID: <20060630143453.GA18288@gate.dtucker.net> On Fri, Jun 30, 2006 at 07:04:20AM -0700, Erich Weiler wrote: > Hi ya'll- > > I've got this odd openssh problem with Solaris 10 I was hoping someone > could shed some light on. Not sure if it is a bug... Basically I'm > trying to use pubkeys as an auth method, but am having issues. I can > log in using passwords no problem, but as soon as it notices a matching > public key it closes the connection. I ran the sshd server (on Solaris > 10 box) in debug mode and got this output when I tried to log in: [...] > Found matching RSA key: 4d:c0:33:3b:dd:75:89:bb:d1:36:e7:17:2b:85:34:9c > debug1: restore_uid: 0/0 > debug1: ssh_rsa_verify: signature correct > debug1: do_pam_account: called > Access denied for user weiler by PAM account configuration [...] What's happening is that sshd is successfully authenticating via public-key. It then tries to check the account status via PAM which fails, because you have Kerberos modules in your PAM config but public-key authentication does not provide the Kerberos credentials required for the module to perform those checks, and thus it fails. If you don't use Kerberos then you can comment out the Kerberos account (and probably session) modules. (You might want to create a "sshd" service in the PAM config specifically for it.) If you do use Kerberos then I'm not sure what your options are. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From weiler at soe.ucsc.edu Sat Jul 1 01:20:43 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Fri, 30 Jun 2006 08:20:43 -0700 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <20060630143453.GA18288@gate.dtucker.net> References: <44A52F64.1080907@soe.ucsc.edu> <20060630143453.GA18288@gate.dtucker.net> Message-ID: <44A5414B.5060304@soe.ucsc.edu> Arrg. Yup, I need Kerberos to work in this case. Of course it works when a password is entered, but the public key thing would be very nice. Annoyingly enough this works under linux (redhat/fedora). I guess Sun's kerberos PAM module is somewhat lacking in functionality. How annoying of Sun! Thanks for the reply in any case. Darren Tucker wrote: > On Fri, Jun 30, 2006 at 07:04:20AM -0700, Erich Weiler wrote: >> Hi ya'll- >> >> I've got this odd openssh problem with Solaris 10 I was hoping someone >> could shed some light on. Not sure if it is a bug... Basically I'm >> trying to use pubkeys as an auth method, but am having issues. I can >> log in using passwords no problem, but as soon as it notices a matching >> public key it closes the connection. I ran the sshd server (on Solaris >> 10 box) in debug mode and got this output when I tried to log in: > [...] >> Found matching RSA key: 4d:c0:33:3b:dd:75:89:bb:d1:36:e7:17:2b:85:34:9c >> debug1: restore_uid: 0/0 >> debug1: ssh_rsa_verify: signature correct >> debug1: do_pam_account: called >> Access denied for user weiler by PAM account configuration > [...] > > What's happening is that sshd is successfully authenticating via > public-key. > > It then tries to check the account status via PAM which fails, because you > have Kerberos modules in your PAM config but public-key authentication > does not provide the Kerberos credentials required for the module to > perform those checks, and thus it fails. > > If you don't use Kerberos then you can comment out the Kerberos account > (and probably session) modules. (You might want to create a "sshd" > service in the PAM config specifically for it.) If you do use Kerberos > then I'm not sure what your options are. > -- =================================== Erich Weiler UNIX Systems Administrator School of Engineering University of California Santa Cruz weiler at soe.ucsc.edu =================================== From deengert at anl.gov Sat Jul 1 01:55:35 2006 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 30 Jun 2006 10:55:35 -0500 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <44A5414B.5060304@soe.ucsc.edu> References: <44A52F64.1080907@soe.ucsc.edu> <20060630143453.GA18288@gate.dtucker.net> <44A5414B.5060304@soe.ucsc.edu> Message-ID: <44A54977.6040501@anl.gov> Erich Weiler wrote: > Arrg. Yup, I need Kerberos to work in this case. Of course it works > when a password is entered, but the public key thing would be very nice. > Annoyingly enough this works under linux (redhat/fedora). I guess > Sun's kerberos PAM module is somewhat lacking in functionality. The Solaris 10 sshd has a nice PAM feature, in that it will use a different pam service name depending on the auth used. For example: sshd-password, sshd-kdbint, sshd-pubkey, sshd-gssapi ... The sshd_config can override these too. Thus you can skip the pam_krb5 for pubkey. OpenSSH might want to consider a similiar feature. > > How annoying of Sun! > > Thanks for the reply in any case. > > Darren Tucker wrote: > >>On Fri, Jun 30, 2006 at 07:04:20AM -0700, Erich Weiler wrote: >> >>>Hi ya'll- >>> >>>I've got this odd openssh problem with Solaris 10 I was hoping someone >>>could shed some light on. Not sure if it is a bug... Basically I'm >>>trying to use pubkeys as an auth method, but am having issues. I can >>>log in using passwords no problem, but as soon as it notices a matching >>>public key it closes the connection. I ran the sshd server (on Solaris >>>10 box) in debug mode and got this output when I tried to log in: >> >>[...] >> >>>Found matching RSA key: 4d:c0:33:3b:dd:75:89:bb:d1:36:e7:17:2b:85:34:9c >>>debug1: restore_uid: 0/0 >>>debug1: ssh_rsa_verify: signature correct >>>debug1: do_pam_account: called >>>Access denied for user weiler by PAM account configuration >> >>[...] >> >>What's happening is that sshd is successfully authenticating via >>public-key. >> >>It then tries to check the account status via PAM which fails, because you >>have Kerberos modules in your PAM config but public-key authentication >>does not provide the Kerberos credentials required for the module to >>perform those checks, and thus it fails. >> >>If you don't use Kerberos then you can comment out the Kerberos account >>(and probably session) modules. (You might want to create a "sshd" >>service in the PAM config specifically for it.) If you do use Kerberos >>then I'm not sure what your options are. >> > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From weiler at soe.ucsc.edu Sat Jul 1 02:15:40 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Fri, 30 Jun 2006 09:15:40 -0700 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <44A54977.6040501@anl.gov> References: <44A52F64.1080907@soe.ucsc.edu> <20060630143453.GA18288@gate.dtucker.net> <44A5414B.5060304@soe.ucsc.edu> <44A54977.6040501@anl.gov> Message-ID: <44A54E2C.2030006@soe.ucsc.edu> Upon further investigation I discovered that the root of my problem actually lies with the fact that Solaris's pam_ldap module does not allow account information to be read without valid credentials. It does not consider an ssh key auth to be a valid cred set, but it does consider a password to be (obviously). Linux pam_ldap (or PADL pam_ldap) works fine, which is why this setup is working on my linux boxes. This is apparently a documented issue and they are working on fixing it. I'm bugging the Sun engineers about it now. Turns out it has nothing to do with kerberos. Thanks a million for replying in any case! -erich Douglas E. Engert wrote: > Erich Weiler wrote: > >> Arrg. Yup, I need Kerberos to work in this case. Of course it works >> when a password is entered, but the public key thing would be very >> nice. Annoyingly enough this works under linux (redhat/fedora). I >> guess Sun's kerberos PAM module is somewhat lacking in functionality. > > The Solaris 10 sshd has a nice PAM feature, in that it > will use a different pam service name depending on the auth used. > For example: sshd-password, sshd-kdbint, sshd-pubkey, sshd-gssapi ... > The sshd_config can override these too. > > Thus you can skip the pam_krb5 for pubkey. > > OpenSSH might want to consider a similiar feature. > > >> >> How annoying of Sun! >> >> Thanks for the reply in any case. >> >> Darren Tucker wrote: >> >>> On Fri, Jun 30, 2006 at 07:04:20AM -0700, Erich Weiler wrote: >>> >>>> Hi ya'll- >>>> >>>> I've got this odd openssh problem with Solaris 10 I was hoping >>>> someone could shed some light on. Not sure if it is a bug... >>>> Basically I'm trying to use pubkeys as an auth method, but am having >>>> issues. I can log in using passwords no problem, but as soon as it >>>> notices a matching public key it closes the connection. I ran the >>>> sshd server (on Solaris 10 box) in debug mode and got this output >>>> when I tried to log in: >>> >>> [...] >>> >>>> Found matching RSA key: 4d:c0:33:3b:dd:75:89:bb:d1:36:e7:17:2b:85:34:9c >>>> debug1: restore_uid: 0/0 >>>> debug1: ssh_rsa_verify: signature correct >>>> debug1: do_pam_account: called >>>> Access denied for user weiler by PAM account configuration >>> >>> [...] >>> >>> What's happening is that sshd is successfully authenticating via >>> public-key. >>> >>> It then tries to check the account status via PAM which fails, >>> because you >>> have Kerberos modules in your PAM config but public-key authentication >>> does not provide the Kerberos credentials required for the module to >>> perform those checks, and thus it fails. >>> >>> If you don't use Kerberos then you can comment out the Kerberos account >>> (and probably session) modules. (You might want to create a "sshd" >>> service in the PAM config specifically for it.) If you do use Kerberos >>> then I'm not sure what your options are. >>> >> >> > -- =================================== Erich Weiler UNIX Systems Administrator School of Engineering University of California Santa Cruz weiler at soe.ucsc.edu =================================== From tim at multitalents.net Sat Jul 1 05:44:54 2006 From: tim at multitalents.net (Tim Rice) Date: Fri, 30 Jun 2006 12:44:54 -0700 (PDT) Subject: SunOS 4.1.4 "configure: WARNING" for sys/audit.h and sys/dir.h In-Reply-To: <20060630013314.GB18892@gate.dtucker.net> References: <200606291605.k5TG5C4b000851@mfg.private.sludge.net> <20060630013314.GB18892@gate.dtucker.net> Message-ID: On Fri, 30 Jun 2006, Darren Tucker wrote: > On Thu, Jun 29, 2006 at 09:05:12AM -0700, Russell Ruby wrote: > > 429 *-*-sunos4*) > > 430 CPPFLAGS="$CPPFLAGS -DSUNOS4" > > 431 AC_CHECK_FUNCS(getpwanam) > > 432 AC_DEFINE(PAM_SUN_CODEBASE) > > + add this + AC_DEFINE(HAVE_SYS_TYPES_H) > > That's odd, is one of the first tests autoconf does so it > should already be defined. Do you see "checking for sys/types.h..." near > the start of the configure output? Hmm, something strange going on with our configure .... tim at sun2 3% grep SYS_TYPE config.h /* #undef HAVE_SYS_TYPES_H */ tim at sun2 4% ls -l /usr/include/sys/types.h -rw-r--r-- 1 root bin 15840 Nov 19 2003 /usr/include/sys/types.h tim at sun2 5% uname -a SunOS sun2 5.8 Generic_117350-31 sun4u sparc SUNW,Ultra-2 tim at sun2 6% pwd /usr/local/src/networking/openssh .... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sat Jul 1 06:10:42 2006 From: tim at multitalents.net (Tim Rice) Date: Fri, 30 Jun 2006 13:10:42 -0700 (PDT) Subject: SunOS 4.1.4 "configure: WARNING" for sys/audit.h and sys/dir.h In-Reply-To: References: <200606291605.k5TG5C4b000851@mfg.private.sludge.net> <20060630013314.GB18892@gate.dtucker.net> Message-ID: On Fri, 30 Jun 2006, Tim Rice wrote: > On Fri, 30 Jun 2006, Darren Tucker wrote: > > > On Thu, Jun 29, 2006 at 09:05:12AM -0700, Russell Ruby wrote: > > > 429 *-*-sunos4*) > > > 430 CPPFLAGS="$CPPFLAGS -DSUNOS4" > > > 431 AC_CHECK_FUNCS(getpwanam) > > > 432 AC_DEFINE(PAM_SUN_CODEBASE) > > > + add this + AC_DEFINE(HAVE_SYS_TYPES_H) > > > > That's odd, is one of the first tests autoconf does so it > > should already be defined. Do you see "checking for sys/types.h..." near > > the start of the configure output? > > Hmm, something strange going on with our configure > .... > tim at sun2 3% grep SYS_TYPE config.h > /* #undef HAVE_SYS_TYPES_H */ > tim at sun2 4% ls -l /usr/include/sys/types.h > -rw-r--r-- 1 root bin 15840 Nov 19 2003 /usr/include/sys/types.h > tim at sun2 5% uname -a > SunOS sun2 5.8 Generic_117350-31 sun4u sparc SUNW,Ultra-2 > tim at sun2 6% pwd > /usr/local/src/networking/openssh > .... If I generate configure with autoconf 2.60 it seems define HAVE_SYS_TYPES_H as it should my Solaris & UnixWare boxes. Russell, Try http://www.multitalents.net/openssh/configure-1.343.gz and see if that helps on your Sun OS box. > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From neda_s at nifty.com Sat Jul 1 09:34:40 2006 From: neda_s at nifty.com (neda_s at nifty.com) Date: Sat, 01 Jul 2006 08:34:40 +0900 Subject: Problems with SFTP In-Reply-To: References: Message-ID: <200606302334.AA00053@0dhzej3d7hh91pv.nifty.com> Hi, Segfaults happens to access memory that was not allocated using xmalloc, to read/write from the file without the fileopen function, etc. I suggest you check what codes in openssh 4.3p2 happen Segfaults. Segfaults happens when SFTP works as a client. You embed the SNPRINTF statement in the openssh as a tracer. Could you modify the program and run it on your development environment? The program moves the control to the statement "case I_LS:" at the function "parse_dispatch_command" in the source file "sftp.c" when the user enters the command "ls". I suggest you embed the SNPRINTF statement here at the first. Regards, Tomo rogier at tw.reverze.net wrote: >Guys, > >Once again I need some help I hope you can give me. When I try to SFTP to >any of my PCs (also running openssh) from my Xscale (ARM, >big-endian) system sftp segfaults on me. Sftp to the xscale system works >without any problems. I'm using openssl-0.9.8b (with ocf support), >linux-2.6.16 and openssh 4.3p2 on the Xscale system. One of the systems I >try to sftp to runs Openssh 3.7.1p2, with openssl 0.9.7 and linux 2.4.27. >Below is an output of what ssh -v shows. ssh, scp, and sftp to this system >works fine, it's only sftp from this system. I've tried the SNPRINTF workaround, >which doesn't seem to help. Any ideas I can try? Note, the reason it can't >create files is because those files would be created on a rom filesystem. >Modifying the user directory so it creates them on a RAM filesystem >doesn't work either though. Hope you can help. > >Regards, > >Rogier > ------------------------------------------- ????(Satoshi Neda) neda_s at nifty.com From dtucker at zip.com.au Sat Jul 1 14:31:01 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 1 Jul 2006 14:31:01 +1000 Subject: SunOS 4.1.4 "configure: WARNING" for sys/audit.h and sys/dir.h In-Reply-To: References: <200606291605.k5TG5C4b000851@mfg.private.sludge.net> <20060630013314.GB18892@gate.dtucker.net> Message-ID: <20060701043101.GA30014@gate.dtucker.net> On Fri, Jun 30, 2006 at 01:10:42PM -0700, Tim Rice wrote: [...] > If I generate configure with autoconf 2.60 it seems define HAVE_SYS_TYPES_H > as it should my Solaris & UnixWare boxes. Seems to be because the first explicit AC_CHECK_HEADERS() is inside the case block (sounds familiar.) I suspect that autoconf 2.60 works because it handles this correctly. Putting AC_CHECK_HEADERS(sys/types.h) before the case block works (I suspect that checking for any header would make it work). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Jul 1 15:14:52 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 1 Jul 2006 15:14:52 +1000 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <44A54977.6040501@anl.gov> References: <44A52F64.1080907@soe.ucsc.edu> <20060630143453.GA18288@gate.dtucker.net> <44A5414B.5060304@soe.ucsc.edu> <44A54977.6040501@anl.gov> Message-ID: <20060701051452.GB30014@gate.dtucker.net> On Fri, Jun 30, 2006 at 10:55:35AM -0500, Douglas E. Engert wrote: > The Solaris 10 sshd has a nice PAM feature, in that it > will use a different pam service name depending on the auth used. > For example: sshd-password, sshd-kdbint, sshd-pubkey, sshd-gssapi ... > The sshd_config can override these too. > > Thus you can skip the pam_krb5 for pubkey. > > OpenSSH might want to consider a similiar feature. I've seen that mentioned earlier (here or elsewhere) and it's also been listed in OpenSSH's TODO file for a long time (originally from Solar Designer). It's not a bad idea, but the catch is that it would require either another compile or run time button and/or a migration hassle. This is because there's no (sane) way to tell which PAM services are available: pam_get_item(handle, PAM_SERVICE, [...]) will return the service name you asked for, not the service name that you actually got (which makes it kinda useless, since you already know what you asked for). Thus there is no way to, eg, try "sshd-kbdint" and fall back to "sshd" if it's not available (in the first instance you'll get the "other" service but have no way of knowing it). This is the case on at least Sun and LinuxPAM implementations. You can confirm this behaviour on other platforms with my PAM test tool: http://www.zip.com.au/~dtucker/patches/#pamtest $ sudo ./pam-test-harness -s some-random-service [...] pam_start(some-random-service, (NULL), &conv, &pamh) = 0 (Success) pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success) PAM_SERVICE = some-random-service (unchanged) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From senthilkumar_sen at hotpop.com Sat Jul 1 15:37:28 2006 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Sat, 1 Jul 2006 11:07:28 +0530 Subject: OpenSSH public key problem with Solaris 10 References: <44A52F64.1080907@soe.ucsc.edu><20060630143453.GA18288@gate.dtucker.net><44A5414B.5060304@soe.ucsc.edu> <44A54977.6040501@anl.gov> <20060701051452.GB30014@gate.dtucker.net> Message-ID: <047201c69cd0$81120410$220110ac@sekco> "Darren Tucker" wrote: > I've seen that mentioned earlier (here or elsewhere) and it's also > been listed in OpenSSH's TODO file for a long time (originally from > Solar Designer). It's not a bad idea, but the catch is that it would > require either another compile or run time button and/or a migration > hassle. Yes, its mentioned here and the previous discussion can be reached at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=110844606628771&w=2 I have an old patch, will update it and send it to the community if there are interest on it. Thanks, Senthil Kumar. From weiler at soe.ucsc.edu Sun Jul 2 13:41:38 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Sat, 01 Jul 2006 20:41:38 -0700 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <047201c69cd0$81120410$220110ac@sekco> References: <44A52F64.1080907@soe.ucsc.edu><20060630143453.GA18288@gate.dtucker.net><44A5414B.5060304@soe.ucsc.edu> <44A54977.6040501@anl.gov> <20060701051452.GB30014@gate.dtucker.net> <047201c69cd0$81120410$220110ac@sekco> Message-ID: <44A74072.3050400@soe.ucsc.edu> Hi Senthil, I'm using OpenSSH 4.3p2, if you have a patch that would work on that version to allow Solaris's pam_ldap to let someone in with public keys via SSH then I'm all over it. If you do post it, just let me know how to patch the code and I'll be eternally grateful. ciao, erich Senthil Kumar wrote: > "Darren Tucker" wrote: > >> I've seen that mentioned earlier (here or elsewhere) and it's also >> been listed in OpenSSH's TODO file for a long time (originally from >> Solar Designer). It's not a bad idea, but the catch is that it would >> require either another compile or run time button and/or a migration >> hassle. > > Yes, its mentioned here and the previous discussion can be reached at > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=110844606628771&w=2 > I have an old patch, will update it and send it to the community if > there are interest on it. > > Thanks, > Senthil Kumar. -- =================================== Erich Weiler UNIX Systems Administrator School of Engineering University of California Santa Cruz weiler at soe.ucsc.edu =================================== From deengert at anl.gov Tue Jul 4 01:43:14 2006 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 03 Jul 2006 10:43:14 -0500 Subject: OpenSSH public key problem with Solaris 10 In-Reply-To: <20060701051452.GB30014@gate.dtucker.net> References: <44A52F64.1080907@soe.ucsc.edu> <20060630143453.GA18288@gate.dtucker.net> <44A5414B.5060304@soe.ucsc.edu> <44A54977.6040501@anl.gov> <20060701051452.GB30014@gate.dtucker.net> Message-ID: <44A93B12.40607@anl.gov> Darren Tucker wrote: > On Fri, Jun 30, 2006 at 10:55:35AM -0500, Douglas E. Engert wrote: > >>The Solaris 10 sshd has a nice PAM feature, in that it >>will use a different pam service name depending on the auth used. >>For example: sshd-password, sshd-kdbint, sshd-pubkey, sshd-gssapi ... >>The sshd_config can override these too. >> >>Thus you can skip the pam_krb5 for pubkey. >> >>OpenSSH might want to consider a similiar feature. > > > I've seen that mentioned earlier (here or elsewhere) and it's also > been listed in OpenSSH's TODO file for a long time (originally from > Solar Designer). It's not a bad idea, but the catch is that it would > require either another compile or run time button and/or a migration > hassle. > > This is because there's no (sane) way to tell which PAM services are > available: pam_get_item(handle, PAM_SERVICE, [...]) will return the > service name you asked for, not the service name that you actually got > (which makes it kinda useless, since you already know what you asked > for). > > Thus there is no way to, eg, try "sshd-kbdint" and fall back to "sshd" > if it's not available (in the first instance you'll get the "other" > service but have no way of knowing it). Yes that's to bad and sounds like a bug. But even without this change how do you know now that "other" is not being used? i.e. the admin did not setup a "sshd" pam entry. Even Solaris 10 is misleading as the man page for sshd_config says you can change these from the default of sshd: PamSvcForNone PamSvcForPassword PamSvcForKbdInt PamSvcForOther But the man page for sshd says it uses sshd-none, sshd-password, sshd-kdbint, sshd-pubkey, sshd-hostbased, sshd-gssapi which it appears to do. (I have only tried the sshd-kbdint and sshd-gssapi.) > > This is the case on at least Sun and LinuxPAM implementations. You can > confirm this behaviour on other platforms with my PAM test tool: > http://www.zip.com.au/~dtucker/patches/#pamtest > > $ sudo ./pam-test-harness -s some-random-service > [...] > pam_start(some-random-service, (NULL), &conv, &pamh) = 0 (Success) > pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success) > PAM_SERVICE = some-random-service (unchanged) > So could OpenSSH have the sshd_config options set to sshd? This would then allow the admin the flexability and responsibility to update both sshd_config and pam.conf to match. If falling back to "other" is a problem, then maybe "other" should always fail or at least log that it is being used when not expected. Using the bug you discribe above, A pam_other_fail.so called only from "other" could use pam_get_item, and if did not return "other" it could fail. This would then force the admin to explicitly setup pam for each service. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From djm at mindrot.org Wed Jul 5 10:30:23 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Jul 2006 10:30:23 +1000 (EST) Subject: test, please ignore Message-ID: <20060705003035.C6B1D69A8F@natsu.mindrot.org> This is a test of the new mailing list server. Please don't reply. Thanks, Damien Miller From djm at mindrot.org Wed Jul 5 11:31:53 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Jul 2006 11:31:53 +1000 (EST) Subject: List server move Message-ID: Hi, The list server has now moved to a better home in a co-lo facility. The only visible change should be the URLs of the administration webpages that now live at http://lists.mindrot.org/ The old URLs for list administration have been configured to redirect to the new ones, so even this should be transparent. Please report any problems with the lists directly to me. Thanks, Damien Miller From abryson at bytefocus.com Wed Jul 5 14:31:39 2006 From: abryson at bytefocus.com (Alice Bryson) Date: Wed, 5 Jul 2006 12:31:39 +0800 Subject: test, please ignore In-Reply-To: <20060705003035.C6B1D69A8F@natsu.mindrot.org> References: <20060705003035.C6B1D69A8F@natsu.mindrot.org> Message-ID: <21ae1b060607042131g1584025brec93fb52537bdce2@mail.gmail.com> can i use this mailing list? 2006/7/5, Damien Miller : > This is a test of the new mailing list server. Please don't reply. > > Thanks, > Damien Miller > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Have a Good Day From damien-miller at hotmail.com Wed Jul 5 16:38:11 2006 From: damien-miller at hotmail.com (Damien Miller) Date: Wed, 05 Jul 2006 17:08:11 +1030 Subject: Testing again Message-ID: This is the last one, hopefully. _________________________________________________________________ Meet Sexy Singles today @ Lavalife - Click here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D22740&_t=751140432&_r=emailtagline_meetsexy_june&_m=EXT From djm at mindrot.org Wed Jul 5 16:43:57 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Jul 2006 16:43:57 +1000 (EST) Subject: test, please ignore In-Reply-To: <21ae1b060607042131g1584025brec93fb52537bdce2@mail.gmail.com> References: <20060705003035.C6B1D69A8F@natsu.mindrot.org> <21ae1b060607042131g1584025brec93fb52537bdce2@mail.gmail.com> Message-ID: On Wed, 5 Jul 2006, Alice Bryson wrote: > can i use this mailing list? You can use the mailing list if you want to discuss the development of portable OpenSSH :) To use it you can either subscribe to the list at: http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Or you can post as a non-subscriber. If you do not subscribe, then you will need to complete a one-time authentication challenge (this is done to weed out spam), and you won't see replies to your post unless the people who are replying explictly include your address. Cheers, Damien Miller From djm at mindrot.org Thu Jul 6 12:30:22 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 6 Jul 2006 12:30:22 +1000 (EST) Subject: rsync server has moved Message-ID: Hi, For anyone who is using it, the mindrot.org rsync server has changed home. It's canonical location is rsync.mindrot.org, so if you use that then you will be able to find it as long as it exists. -d From weiler at soe.ucsc.edu Fri Jul 7 07:33:14 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Thu, 06 Jul 2006 14:33:14 -0700 Subject: scp/sftp weirdness Message-ID: <44AD819A.2060708@soe.ucsc.edu> Hi ya'll- I'm having this weird problem with the new version of OpenSSH compiled on Solaris, version 4.3p2. SSH and SSHD work fine, all is well. But when I try to sftp or scp something I get this: % sftp bullitt Connecting to bullitt... command-line: line 0: Bad configuration option: PermitLocalCommand Connection closed % "PermitLocalCommand" doesn't appear in sshd_config or ssh_config, so I have no idea what's up... Has anyone seen this kind of thing before? Thanks for any insight, erich From djm at mindrot.org Fri Jul 7 09:55:00 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Jul 2006 09:55:00 +1000 (EST) Subject: scp/sftp weirdness In-Reply-To: <44AD819A.2060708@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> Message-ID: On Thu, 6 Jul 2006, Erich Weiler wrote: > Hi ya'll- > > I'm having this weird problem with the new version of OpenSSH compiled > on Solaris, version 4.3p2. SSH and SSHD work fine, all is well. But > when I try to sftp or scp something I get this: > > % sftp bullitt > Connecting to bullitt... > command-line: line 0: Bad configuration option: PermitLocalCommand > Connection closed It looks like you have your scp/sftp out of sync with your ssh binary. Perhaps OpenSSH scp/sftp are picking up Solaris' default ssh binary because it is first in your $PATH? -d From weiler at soe.ucsc.edu Fri Jul 7 12:27:33 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Thu, 06 Jul 2006 19:27:33 -0700 Subject: scp/sftp weirdness In-Reply-To: References: <44AD819A.2060708@soe.ucsc.edu> Message-ID: <44ADC695.10307@soe.ucsc.edu> As a matter of fact I do have 2 versions of OpenSSH lurking around (but no Sun SSH, I didn't install it). Maybe the new sftp is trying to reference the old ssh? I did a 'which ssh' and 'which sftp' and they are both in the right place... Does sftp reference anything else but ssh? sftp-server maybe? The reason I have 2 versions is that my older Solaris clients are using the old one and the newer Solaris 10 boxes are (trying to) using the new one. ciao, erich Damien Miller wrote: > On Thu, 6 Jul 2006, Erich Weiler wrote: > >> Hi ya'll- >> >> I'm having this weird problem with the new version of OpenSSH compiled >> on Solaris, version 4.3p2. SSH and SSHD work fine, all is well. But >> when I try to sftp or scp something I get this: >> >> % sftp bullitt >> Connecting to bullitt... >> command-line: line 0: Bad configuration option: PermitLocalCommand >> Connection closed > > It looks like you have your scp/sftp out of sync with your ssh binary. > Perhaps OpenSSH scp/sftp are picking up Solaris' default ssh binary > because it is first in your $PATH? > > -d From weiler at soe.ucsc.edu Fri Jul 7 12:55:26 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Thu, 06 Jul 2006 19:55:26 -0700 Subject: scp/sftp weirdness In-Reply-To: <44ADC695.10307@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> Message-ID: <44ADCD1E.7000200@soe.ucsc.edu> Also the "PermitLocalCommand" option doesn't appear anywhere in my ssh_config or sshd_config... What could be specifying that option I wonder? ciao, erich Erich Weiler wrote: > As a matter of fact I do have 2 versions of OpenSSH lurking around (but > no Sun SSH, I didn't install it). Maybe the new sftp is trying to > reference the old ssh? I did a 'which ssh' and 'which sftp' and they > are both in the right place... Does sftp reference anything else but > ssh? sftp-server maybe? > > The reason I have 2 versions is that my older Solaris clients are using > the old one and the newer Solaris 10 boxes are (trying to) using the new > one. > > ciao, erich > > Damien Miller wrote: >> On Thu, 6 Jul 2006, Erich Weiler wrote: >> >>> Hi ya'll- >>> >>> I'm having this weird problem with the new version of OpenSSH >>> compiled on Solaris, version 4.3p2. SSH and SSHD work fine, all is >>> well. But when I try to sftp or scp something I get this: >>> >>> % sftp bullitt >>> Connecting to bullitt... >>> command-line: line 0: Bad configuration option: PermitLocalCommand >>> Connection closed >> >> It looks like you have your scp/sftp out of sync with your ssh binary. >> Perhaps OpenSSH scp/sftp are picking up Solaris' default ssh binary >> because it is first in your $PATH? >> >> -d > -- =================================== Erich Weiler UNIX Systems Administrator School of Engineering University of California Santa Cruz weiler at soe.ucsc.edu =================================== From djm at mindrot.org Fri Jul 7 12:58:24 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Jul 2006 12:58:24 +1000 (EST) Subject: scp/sftp weirdness In-Reply-To: <44ADCD1E.7000200@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> Message-ID: I told you: your sftp and scp binaries are using the wrong ssh binary. sftp and ssh set a number of options when invoking ssh. PermitLocalCommand is one of them. On Thu, 6 Jul 2006, Erich Weiler wrote: > Also the "PermitLocalCommand" option doesn't appear anywhere in my ssh_config > or sshd_config... What could be specifying that option I wonder? > > ciao, erich > > Erich Weiler wrote: > > As a matter of fact I do have 2 versions of OpenSSH lurking around (but no > > Sun SSH, I didn't install it). Maybe the new sftp is trying to reference > > the old ssh? I did a 'which ssh' and 'which sftp' and they are both in the > > right place... Does sftp reference anything else but ssh? sftp-server > > maybe? > > > > The reason I have 2 versions is that my older Solaris clients are using the > > old one and the newer Solaris 10 boxes are (trying to) using the new one. > > > > ciao, erich > > > > Damien Miller wrote: > > > On Thu, 6 Jul 2006, Erich Weiler wrote: > > > > > > > Hi ya'll- > > > > > > > > I'm having this weird problem with the new version of OpenSSH compiled > > > > on Solaris, version 4.3p2. SSH and SSHD work fine, all is well. But > > > > when I try to sftp or scp something I get this: > > > > > > > > % sftp bullitt > > > > Connecting to bullitt... > > > > command-line: line 0: Bad configuration option: PermitLocalCommand > > > > Connection closed > > > > > > It looks like you have your scp/sftp out of sync with your ssh binary. > > > Perhaps OpenSSH scp/sftp are picking up Solaris' default ssh binary > > > because it is first in your $PATH? > > > > > > -d > > > > -- > =================================== > Erich Weiler > UNIX Systems Administrator > School of Engineering > University of California Santa Cruz > weiler at soe.ucsc.edu > =================================== > From dtucker at zip.com.au Fri Jul 7 13:02:02 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 07 Jul 2006 13:02:02 +1000 Subject: scp/sftp weirdness In-Reply-To: <44ADCD1E.7000200@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> Message-ID: <44ADCEAA.30209@zip.com.au> Erich Weiler wrote: > Also the "PermitLocalCommand" option doesn't appear anywhere in my > ssh_config or sshd_config... What could be specifying that option I wonder? scp and sftp add it to the command line they run, eg addargs(&args, "-oPermitLocalCommand no"); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From weiler at soe.ucsc.edu Fri Jul 7 13:11:32 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Thu, 06 Jul 2006 20:11:32 -0700 Subject: scp/sftp weirdness In-Reply-To: References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> Message-ID: <44ADD0E4.4010703@soe.ucsc.edu> Hi Damien, Respectfully, I understand what you are saying but I'm not seeing it in practice. I put the path to all the new SSH binaries in the very front of my PATH as such: setenv PATH /usr/local/openssh.new/bin:/rest/of/path % which ssh /usr/local/openssh.new/bin/ssh % which sftp /usr/local/openssh.new/bin/sftp and still I get the same error when I try to sftp anywhere... ciao, erich Damien Miller wrote: > I told you: your sftp and scp binaries are using the wrong ssh binary. > > sftp and ssh set a number of options when invoking ssh. PermitLocalCommand > is one of them. > > On Thu, 6 Jul 2006, Erich Weiler wrote: > >> Also the "PermitLocalCommand" option doesn't appear anywhere in my ssh_config >> or sshd_config... What could be specifying that option I wonder? >> >> ciao, erich >> From stuge-openssh-unix-dev at cdy.org Fri Jul 7 13:43:33 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 7 Jul 2006 05:43:33 +0200 Subject: scp/sftp weirdness In-Reply-To: <44ADD0E4.4010703@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> <44ADD0E4.4010703@soe.ucsc.edu> Message-ID: <20060707034333.12620.qmail@cdy.org> On Thu, Jul 06, 2006 at 08:11:32PM -0700, Erich Weiler wrote: > and still I get the same error when I try to sftp anywhere... Try running sftp under truss to see what is going on and perhaps get an idea on how to fix it. //Peter From imorgan at nas.nasa.gov Sat Jul 8 02:01:13 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 7 Jul 2006 09:01:13 -0700 (PDT) Subject: scp/sftp weirdness In-Reply-To: <20060707034333.12620.qmail@cdy.org> from Peter Stuge at "Jul 7, 2006 05:43:33 am" Message-ID: <200607071601.k67G1Do3005116@ganymede.nas.nasa.gov> Sometime ago, Peter Stuge wrote: > On Thu, Jul 06, 2006 at 08:11:32PM -0700, Erich Weiler wrote: > > and still I get the same error when I try to sftp anywhere... > > Try running sftp under truss to see what is going on and perhaps get > an idea on how to fix it. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Alternatively, simply doing an scp -v should show which ssh scp is actually using. -- Iain Morgan From rapier at psc.edu Sat Jul 8 03:16:12 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 07 Jul 2006 13:16:12 -0400 Subject: scp/sftp weirdness In-Reply-To: <44ADD0E4.4010703@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> <44ADD0E4.4010703@soe.ucsc.edu> Message-ID: <44AE96DC.5080505@psc.edu> Erich Weiler wrote: > Hi Damien, > > Respectfully, I understand what you are saying but I'm not seeing it in > practice. I put the path to all the new SSH binaries in the very front > of my PATH as such: Right, the paths might be setup however you like but if I remember correctly the binary has the preferred path to the binary built into it. If you do a 'strings scp | grep \/' you'll end up seeing the the default path to the binary. For example, mine reports cuckoo:~/ssh/hpn12/openssh-4.3p2 rapier$ strings scp | grep \/ /usr/local/bin/ssh %s/%s: name too long %s/%s /dev/null Couldn't open /dev/null: %s So by default its looking in /usr/local/bin/ssh and even if I have ./ in my path it doesn't matter because it will look in /usr/local/bin/ for the binary. What you can do to test things out is override the default using the '-S /explicit/path/to/ssh/binary' command. Good luck! From brandon.barker at gmail.com Sat Jul 8 01:26:41 2006 From: brandon.barker at gmail.com (Brandon Barker) Date: Fri, 7 Jul 2006 11:26:41 -0400 Subject: cygwin sshd Message-ID: <3e078a5e0607070826y4b34d604o67125d4d046f301d@mail.gmail.com> Hello, I've used cygwin and openssh's sshd many times successfuly on Windows systems previously, including windows server 2003 (thanks to the guide found at http://www.chinese-watercolor.com/LRP/printsrv/cygwin-sshd.html ). I recently installed active directory on a windows server 2003 system and promoted it to a domain controller. The problem is, only users in the Administrators group can log in using ssh; other users get the "Password denied, please try again." message. I've tried using mkpasswd and mkgroup with local users, domain users, and both local and domain users to no avail. I'll do my best to facilitate in helping solve this problem, any insights are vey much appreciated. Thanks, -- Brandon Barker Phone: (859) 948-5335 GPG Key: http://bigapple.uky.edu/~brandon/my_pgp_key.html From weiler at soe.ucsc.edu Sat Jul 8 03:29:36 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Fri, 07 Jul 2006 10:29:36 -0700 Subject: scp/sftp weirdness In-Reply-To: <44AE96DC.5080505@psc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> <44ADD0E4.4010703@soe.ucsc.edu> <44AE96DC.5080505@psc.edu> Message-ID: <44AE9A00.1080505@soe.ucsc.edu> Hi Chris, You are absolutely right, that fixes it. I was able to recompile and install in the right place and all is well. Thanks very much! ciao, erich Chris Rapier wrote: > > > Erich Weiler wrote: >> Hi Damien, >> >> Respectfully, I understand what you are saying but I'm not seeing it >> in practice. I put the path to all the new SSH binaries in the very >> front of my PATH as such: > > Right, the paths might be setup however you like but if I remember > correctly the binary has the preferred path to the binary built into it. > > If you do a 'strings scp | grep \/' you'll end up seeing the the default > path to the binary. > > For example, mine reports > cuckoo:~/ssh/hpn12/openssh-4.3p2 rapier$ strings scp | grep \/ > /usr/local/bin/ssh > %s/%s: name too long > %s/%s > /dev/null > Couldn't open /dev/null: %s > > So by default its looking in /usr/local/bin/ssh and even if I have ./ in > my path it doesn't matter because it will look in /usr/local/bin/ for > the binary. > > What you can do to test things out is override the default using the '-S > /explicit/path/to/ssh/binary' command. > > Good luck! -- =================================== Erich Weiler UNIX Systems Administrator School of Engineering University of California Santa Cruz weiler at soe.ucsc.edu =================================== From weiler at soe.ucsc.edu Sat Jul 8 04:44:08 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Fri, 07 Jul 2006 11:44:08 -0700 Subject: scp/sftp weirdness In-Reply-To: <44AE96DC.5080505@psc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> <44ADD0E4.4010703@soe.ucsc.edu> <44AE96DC.5080505@psc.edu> Message-ID: <44AEAB78.5030906@soe.ucsc.edu> > Right, the paths might be setup however you like but if I remember > correctly the binary has the preferred path to the binary built into it. > > If you do a 'strings scp | grep \/' you'll end up seeing the the default > path to the binary. Actually I have one more quick question. ;) While ssh now works with passwords, I have a problem with using public keys. When I try to log into another box using public keys I get this: ghost% ssh hammer could not open any host key ssh_msg_send: write ssh_keysign: couldn't send request ghost% If I set the setuid bit on the 'ssh' binary it works. But I don't want to set the setuid bit on the 'ssh' binary for security reasons as it is owned by root. This seemed to work fine with an older version of OpenSSH... Any idea as to what I may be doing wrong? ciao, erich From rapier at psc.edu Sat Jul 8 04:54:16 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 07 Jul 2006 14:54:16 -0400 Subject: scp/sftp weirdness In-Reply-To: <44AEAB78.5030906@soe.ucsc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> <44ADD0E4.4010703@soe.ucsc.edu> <44AE96DC.5080505@psc.edu> <44AEAB78.5030906@soe.ucsc.edu> Message-ID: <44AEADD8.8040101@psc.edu> I think you need to set the ssh-keysign binary to setuid root. Thats what I found with google anyway. http://itg.chem.indiana.edu/inc/wiki/software/openssh/189.html look under the debugging subheading. Oh, and obviously make sure the keys are in the right place. Good luck Erich Weiler wrote: >> Right, the paths might be setup however you like but if I remember >> correctly the binary has the preferred path to the binary built into it. >> >> If you do a 'strings scp | grep \/' you'll end up seeing the the default >> path to the binary. > > Actually I have one more quick question. ;) While ssh now works with > passwords, I have a problem with using public keys. When I try to log > into another box using public keys I get this: > > ghost% ssh hammer > could not open any host key > ssh_msg_send: write > ssh_keysign: couldn't send request > ghost% > > If I set the setuid bit on the 'ssh' binary it works. But I don't want > to set the setuid bit on the 'ssh' binary for security reasons as it is > owned by root. This seemed to work fine with an older version of > OpenSSH... Any idea as to what I may be doing wrong? > > ciao, erich > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From weiler at soe.ucsc.edu Sat Jul 8 05:01:40 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Fri, 07 Jul 2006 12:01:40 -0700 Subject: scp/sftp weirdness In-Reply-To: <44AEADD8.8040101@psc.edu> References: <44AD819A.2060708@soe.ucsc.edu> <44ADC695.10307@soe.ucsc.edu> <44ADCD1E.7000200@soe.ucsc.edu> <44ADD0E4.4010703@soe.ucsc.edu> <44AE96DC.5080505@psc.edu> <44AEAB78.5030906@soe.ucsc.edu> <44AEADD8.8040101@psc.edu> Message-ID: <44AEAF94.8090202@soe.ucsc.edu> Again you're fantastic. Not sure how I could have missed that on google :) Thanks again, erich Chris Rapier wrote: > I think you need to set the ssh-keysign binary to setuid root. Thats > what I found with google anyway. > http://itg.chem.indiana.edu/inc/wiki/software/openssh/189.html > look under the debugging subheading. > > Oh, and obviously make sure the keys are in the right place. > > Good luck > > > Erich Weiler wrote: >>> Right, the paths might be setup however you like but if I remember >>> correctly the binary has the preferred path to the binary built into it. >>> >>> If you do a 'strings scp | grep \/' you'll end up seeing the the >>> default path to the binary. >> >> Actually I have one more quick question. ;) While ssh now works with >> passwords, I have a problem with using public keys. When I try to log >> into another box using public keys I get this: >> >> ghost% ssh hammer >> could not open any host key >> ssh_msg_send: write >> ssh_keysign: couldn't send request >> ghost% >> >> If I set the setuid bit on the 'ssh' binary it works. But I don't >> want to set the setuid bit on the 'ssh' binary for security reasons as >> it is owned by root. This seemed to work fine with an older version >> of OpenSSH... Any idea as to what I may be doing wrong? >> >> ciao, erich >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- =================================== Erich Weiler UNIX Systems Administrator School of Engineering University of California Santa Cruz weiler at soe.ucsc.edu =================================== From email.ahmedkamal at googlemail.com Sat Jul 8 05:48:38 2006 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 7 Jul 2006 22:48:38 +0300 Subject: scp back to *me* (Wish report) Message-ID: <3da3b5b40607071248w32d13cafrcd661b846f7c33c3@mail.gmail.com> Hi, Thanks for the extra-ordinarily excellent package ssh. I love all the devs helping out with ssh. I am not subscribed to the list, so if anyone wants to reply, kindly CC me. Wish report: ========= When I ssh from 'laptop' to 'server', and I see a file I want to scp back to my laptop. The typical way for almost everyone (unless I am totally mistaken) is to: scp file user at laptop and enter his password for the laptop. This is per transferred file! Unfortunately, this is too cumbersome! I was thinking of a FTP like 'get' functionality, so basically on the server, if you scp a file and don't specify a destination, it is automatically copied back to *me* in the current folder. So, to copy a file over scp, I would scp file This is way easier/faster. Not sure if this can be implemented without breaking compatibility somehow. Anyway, that's just what I wanted to say. Thanks again, and best regards From william at 25thandClement.com Sat Jul 8 06:28:08 2006 From: william at 25thandClement.com (William Ahern) Date: Fri, 7 Jul 2006 13:28:08 -0700 Subject: scp back to *me* (Wish report) In-Reply-To: <3da3b5b40607071248w32d13cafrcd661b846f7c33c3@mail.gmail.com> References: <3da3b5b40607071248w32d13cafrcd661b846f7c33c3@mail.gmail.com> Message-ID: <20060707202808.GA32375@orville.25thandClement.com> On Fri, Jul 07, 2006 at 10:48:38PM +0300, Ahmed Kamal wrote: > Wish report: > ========= > When I ssh from 'laptop' to 'server', and I see a file I want to scp back to > my laptop. The typical way for almost everyone (unless I am totally > mistaken) is to: > scp file user at laptop > and enter his password for the laptop. This is per transferred file! > Unfortunately, this is too cumbersome! I was thinking of a FTP like 'get' > functionality, so basically on the server, if you scp a file and don't > specify a destination, it is automatically copied back to *me* in the > current folder. So, to copy a file over scp, I would > scp file You have two options. Most will point out sftp. But, if you're using a decent terminal emulator Google for zmodem. minicom is the only emulator I know of which would support this on the backend, but most Windows emulators do as well, I think. Using zmodem (or xmodem or ymodem or kermit, even) will allow you full shell access, and then allow you to send a file backward across the same connection. From william at 25thandClement.com Sat Jul 8 07:55:53 2006 From: william at 25thandClement.com (William Ahern) Date: Fri, 7 Jul 2006 14:55:53 -0700 Subject: scp back to *me* (Wish report) In-Reply-To: <3da3b5b40607071248w32d13cafrcd661b846f7c33c3@mail.gmail.com> References: <3da3b5b40607071248w32d13cafrcd661b846f7c33c3@mail.gmail.com> Message-ID: <20060707215553.GA1545@orville.25thandClement.com> On Fri, Jul 07, 2006 at 10:48:38PM +0300, Ahmed Kamal wrote: > Unfortunately, this is too cumbersome! I was thinking of a FTP like 'get' > functionality, so basically on the server, if you scp a file and don't > specify a destination, it is automatically copied back to *me* in the > current folder. So, to copy a file over scp, I would > scp file http://zssh.sourceforge.net/ From listuser at adnovum.ch Mon Jul 10 23:02:02 2006 From: listuser at adnovum.ch (Bernd Nies) Date: Mon, 10 Jul 2006 15:02:02 +0200 Subject: OpenSSH 4.3p2 on Solaris 10 and PAM Message-ID: <44B24FCA.2020702@adnovum.ch> Hi, We have a Solaris 10 system that authanticates users against an LDAP server with password management. On port 22 runs Sun SSH 1.1. On port 2222 runs OpenSSH 4.3p2. OpenSSH uses a configuration from a Linux system where login with password or public key works. Adittionally we have a customized PAM module that grants/revokes access based upon an attribute setting in LDAP. The PAM Configuration for Sun SSH 1.1 is: ==CUT== login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_dial_auth.so.1 login auth binding pam_unix_auth.so.1 server_policy login auth required pam_ldap.so.1 sshd-password account required pam_mymodule.so.1 sshd-none account required pam_mymodule.so.1 sshd-kbdint account required pam_mymodule.so.1 sshd-pubkey account required pam_mymodule.so.1 sshd-hostbased account required pam_mymodule.so.1 other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth binding pam_unix_auth.so.1 server_policy other auth required pam_ldap.so.1 passwd auth binding pam_passwd_auth.so.1 server_policy passwd auth required pam_ldap.so.1 cron account required pam_unix_account.so.1 other account requisite pam_roles.so.1 other account binding pam_unix_account.so.1 server_policy other account required pam_ldap.so.1 other session required pam_unix_session.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 server_policy ==CUT== This works fine with Sun SSH 1.1. Access is granted and revoked correctly, even if the user has placed his public key in .ssh/authorized keys. Using OpenSSH 4.3p2 with the above configuration this PAM module never gets executed. Login with password works but with public key authentication fails with "connection closed" and the debug messages in syslog: ==CUT== debug1: fd 6 clearing O_NONBLOCK debug1: rexec start in 6 out 6 newsock 6 pipe 8 sock 1 debug1: Forked child 1250. debug1: inetd sockets after dupping: 5, 5 Connection from 192.168.1.123 port 58541 debug1: Client protocol version 2.0; client software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: PAM: initializing for "user1" debug1: PAM: setting PAM_RHOST to "host1.domain.tld" debug1: PAM: setting PAM_TTY to "ssh" debug1: temporarily_use_uid: 1468/1000 (e=0/0) debug1: trying public key file /home/user1/.ssh/authorized_keys debug1: matching key found: file /home/user1/.ssh/authorized_keys, line 1 Found matching RSA key: 33:dd:ee:66:cc:33:11:33:44:dd:55:ee:00:33:00:ff debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1468/1000 (e=0/0) debug1: trying public key file /home/user1/.ssh/authorized_keys debug1: matching key found: file /home/user1/.ssh/authorized_keys, line 1 Found matching RSA key: 33:dd:ee:66:cc:33:11:33:44:dd:55:ee:00:33:00:ff debug1: restore_uid: 0/0 debug1: ssh_rsa_verify: signature correct debug1: do_pam_account: called Failed publickey for noglera from 192.168.1.123 port 58541 ssh2 debug1: do_cleanup debug1: PAM: cleanup ==CUT== How is the correct PAM configuration for Solaris 10 and OpenSSH 4.3p2 so that login with password or public key works? How has an additional PAM module to be inserted to work with OpenSSH? I found this PAM configuration: sshd auth requisite pam_authtok_get.so.1 sshd auth required pam_dhkeys.so.1 sshd auth sufficient pam_unix_auth.so.1 sshd auth required pam_ldap.so.1 try_first_pass sshd account required pam_unix_account.so.1 But with this config the password login of OpenSSH does not work. Only public key login does work. This is because the LDAP UserPassword is not readable. Authentication must be done with LDAP bind and not LDAP search/compare. Thanks in advance. Regards, Bernd From dtucker at zip.com.au Mon Jul 10 23:53:46 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 Jul 2006 23:53:46 +1000 Subject: OpenSSH 4.3p2 on Solaris 10 and PAM In-Reply-To: <44B24FCA.2020702@adnovum.ch> References: <44B24FCA.2020702@adnovum.ch> Message-ID: <44B25BEA.8020904@zip.com.au> Bernd Nies wrote: [lots of snippage] > How is the correct PAM configuration for Solaris 10 and OpenSSH 4.3p2 so > that login with password or public key works? > > How has an additional PAM module to be inserted to work with OpenSSH? SunSSH (or at least v1.1?) uses a different set of PAM services for each SSH authentication type, but OpenSSH doesn't, and by default uses the basename of the binary. It looks that if you configure the "sshd" service for the account stack to be the equivalent of what you have for SunSSH it would work: sshd account required pam_mymodule.so.1 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From alterdata at alterdata.com.br Tue Jul 11 23:03:24 2006 From: alterdata at alterdata.com.br (alterdata at alterdata.com.br) Date: Tue, 11 Jul 2006 10:03:24 -0300 Subject: Mail Delivery (failure alterdata@alterdata.com.br) Message-ID: Este endere?o de e-mail mudou. Por gentileza envie para faleconosco at alterdata.com.br From Andy.Hughes at HCAHealthcare.com Wed Jul 12 06:50:22 2006 From: Andy.Hughes at HCAHealthcare.com (Hughes Andy) Date: Tue, 11 Jul 2006 15:50:22 -0500 Subject: How to use SSH with Failed Login attempts and locking accounts Message-ID: <273CACD967F9BC47B023F758ACBC3A8C075855F4@NASEV06.hca.corpad.net> I have searched the FAQ's and have not seen an answer to this question. I have also read the manuals for the SSH and have not found an answer to this issue. My question is this: I am using openssh (OpenSSH_4.2p1, OpenSSL 0.9.8 05 Jul 2005) on MP-RAS Version 3.3.1.8 and 3.2 and I desire to allow a user to fail login for any reason only 3 (three) times and then lock the account. I can use the option of FAILLIMIT=3 in the /etc/default/login file for telnet sessions, and this will lock the account after three failed login attempts by the user. But this does not work for SSH. I have also placed the same option in the file of /etc/default/login.openssh with no such luck. I have researched, googled and ran other internet searches for this topic and have yet to find any answer. Could someone help me with this. It is an audit requirement here, to start locking an account when the user fails the login process, for any reason, after three attempts. Any help is appreciated. Thanks in advance for the help. Andy Hughes Systems Programmer Unix Systems HCA Information Technology & Services 2555 Park Plaza Bldg 4 - 2 East Nashville, Tn. 37203-1512 t: 615-344-6961 f: 615-344-8384 p: 615-733-7562 pager(interactive): andy.hughes at my2way.com e: andy.hughes at hcahealthcare.com w: www.hcahealthcare.com From srinath_balaraman at mentor.com Wed Jul 12 08:05:34 2006 From: srinath_balaraman at mentor.com (Balaraman, Srinath) Date: Tue, 11 Jul 2006 17:05:34 -0500 Subject: Problems with buffer usage in SSH1. Message-ID: Hello All, I am not sure if this has already been answered, but I couldn't find a solution to this in the archives so I am asking this. I am using OpenSSH 4.2p2. When using SSH1 protocol, the function "packet_read_poll1(void)" in file packet.c, waits till the entire packet of data has been read (line # 967). This may not pose problems with large buffer sizes (more than 30Kb, as it is by default), but when I try to reduce the buffer sizes to say 5Kb, my ssh client seems to be crashing for any incoming packet that's of size greater than 5Kb. In SSH2 this problem is overcome by constantly "consuming" the data in the buffer. I wanted to find out if somebody has already faced this problem and knows how to resolve it. I hope I have stated the problem precisely and correctly. Thanks, Srinath. From pedro at bezunartea.net Wed Jul 12 11:20:44 2006 From: pedro at bezunartea.net (Pedro Bezunartea Lopez) Date: Wed, 12 Jul 2006 03:20:44 +0200 (CEST) Subject: Stange sshd problem... bug? Message-ID: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> I haven't been able to find any information about this problem, I hope someone can help, anyway this is the setup: Server: - Linux Fedora Core 5 - kernel 2.6.17-1.2145_FC5smp - openssh-server-4.3p2-4 Client not working: - Linux Fedora Core 5 - kernel 2.6.17-1.2145_FC5smp - openssh-clients-4.3p2-4 Client working: - Same machine - Windows XP - putty 0.58 This is the log from the non working client: $ ssh -v elk1 OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to elk1 [**IP-removed**] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent And from the server: Jul 12 03:12:13 web1 sshd[3707]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 Jul 12 03:12:13 web1 sshd[1839]: debug1: Forked child 3707. Jul 12 03:12:13 web1 sshd[3707]: debug1: inetd sockets after dupping: 3, 3 Jul 12 03:12:13 web1 sshd[3707]: Connection from **IP-removed** port 47346 Jul 12 03:12:13 web1 sshd[3707]: debug1: Client protocol version 2.0; client software version OpenSSH_4.3 Jul 12 03:12:13 web1 sshd[3707]: debug1: match: OpenSSH_4.3 pat OpenSSH* Jul 12 03:12:13 web1 sshd[3707]: debug1: Enabling compatibility mode for protocol 2.0 Jul 12 03:12:13 web1 sshd[3707]: debug1: Local version string SSH-1.99-OpenSSH_4.3 Jul 12 03:12:13 web1 sshd[3708]: debug1: permanently_set_uid: 74/74 Jul 12 01:12:13 web1 sshd[3708]: debug1: list_hostkey_types: ssh-rsa,ssh-dss Jul 12 01:12:13 web1 sshd[3708]: debug1: SSH2_MSG_KEXINIT sent And it just freezes there. I've tried to set a smaller mtu, but the problem wasn't solved. When I connect to the same server using windows XP it works, so it has nothing to do with the hardware. I should also say that the server is behind a firewall and that it has been working fine with previous kernels. Any ideas? Anything else I can try? TIA, Pedro. From dtucker at zip.com.au Wed Jul 12 11:30:16 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Jul 2006 11:30:16 +1000 Subject: Stange sshd problem... bug? In-Reply-To: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> References: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> Message-ID: <44B450A8.6010808@zip.com.au> Pedro Bezunartea Lopez wrote: > I haven't been able to find any information about this problem, I hope > someone can help, anyway this is the setup: > > Server: > - Linux Fedora Core 5 > - kernel 2.6.17-1.2145_FC5smp > - openssh-server-4.3p2-4 > > Client not working: > - Linux Fedora Core 5 > - kernel 2.6.17-1.2145_FC5smp [...] > I should also say that the server is behind a firewall and that it has > been working fine with previous kernels. > > Any ideas? Anything else I can try? TIA, Try (as root): echo 0 >/proc/sys/net/ipv4/tcp_window_scaling and if that helps then read this for details: http://kerneltrap.org/node/6723 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rapier at psc.edu Wed Jul 12 12:51:29 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 11 Jul 2006 22:51:29 -0400 Subject: Stange sshd problem... bug? In-Reply-To: <44B450A8.6010808@zip.com.au> References: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> <44B450A8.6010808@zip.com.au> Message-ID: <44B463B1.6060006@psc.edu> As a note: if this does work then its important to realize that you haven't fixed the problem you have only identified what the problem is. This really only swaps one set of problems for a much larger set of problems (albeit one of performance rather than connection establishment). Its a neat problem though. Darren Tucker wrote: > Pedro Bezunartea Lopez wrote: >> I haven't been able to find any information about this problem, I hope >> someone can help, anyway this is the setup: >> >> Server: >> - Linux Fedora Core 5 >> - kernel 2.6.17-1.2145_FC5smp >> - openssh-server-4.3p2-4 >> >> Client not working: >> - Linux Fedora Core 5 >> - kernel 2.6.17-1.2145_FC5smp > [...] >> I should also say that the server is behind a firewall and that it has >> been working fine with previous kernels. >> >> Any ideas? Anything else I can try? TIA, > > Try (as root): > echo 0 >/proc/sys/net/ipv4/tcp_window_scaling > > and if that helps then read this for details: > http://kerneltrap.org/node/6723 > From dtucker at zip.com.au Wed Jul 12 13:53:51 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Jul 2006 13:53:51 +1000 Subject: Stange sshd problem... bug? In-Reply-To: <44B463B1.6060006@psc.edu> References: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> <44B450A8.6010808@zip.com.au> <44B463B1.6060006@psc.edu> Message-ID: <44B4724F.5020702@zip.com.au> Chris Rapier wrote: > Darren Tucker wrote: >> Try (as root): >> echo 0 >/proc/sys/net/ipv4/tcp_window_scaling >> >> and if that helps then read this for details: >> http://kerneltrap.org/node/6723 > As a note: if this does work then its important to realize that you > haven't fixed the problem you have only identified what the problem is. > This really only swaps one set of problems for a much larger set of > problems (albeit one of performance rather than connection establishment). That's true, and if this proves to be the reason then ideally the root cause (ie the network device that's not handling window scaling correctly) should be fixed. The catch is that this may be outside of the control of the folks affected by it. In that case you have a choice of "fast and flaky" or "slow and reliable", and which is preferable would depend on what you're trying to do with it :-) As another aside: the assertion in that kerneltrap article that there's a bug in OpenBSD's pf and it its handling of TCP window scaling appears to be incorrect (although it is possible to misconfigure pf to cause this problem, see http://www.benzedrine.cx/pf/msg05117.html). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From aphor at speakeasy.net Wed Jul 12 13:56:28 2006 From: aphor at speakeasy.net (Jeremy McMillan) Date: Tue, 11 Jul 2006 22:56:28 -0500 Subject: openssh-unix-dev Digest, Vol 39, Issue 6 In-Reply-To: References: Message-ID: <3C6FD014-EC4B-423E-BB01-35BBBA15EE11@speakeasy.net> On Jul 11, 2006, at 8:21 PM, openssh-unix-dev-request at mindrot.org wrote: > Date: Tue, 11 Jul 2006 15:50:22 -0500 > From: "Hughes Andy" > Subject: How to use SSH with Failed Login attempts and locking > accounts > To: > Message-ID: > <273CACD967F9BC47B023F758ACBC3A8C075855F4 at NASEV06.hca.corpad.net> > Content-Type: text/plain; charset="us-ascii" > > I have searched the FAQ's and have not seen an answer to this > question. > I have also read the manuals for the SSH and have not found an > answer to > this issue. I feel the rage of Theo stirring inside me... must ..... resist ...... the ...... impulse ..... aahh. Better now. http://groups.google.com/group/mailing.unix.openssh-dev/about > My question is this: > > I am using openssh (OpenSSH_4.2p1, OpenSSL 0.9.8 05 Jul 2005) on > MP-RAS MP-RAS? Y2K? Won't they support Solaris x86? I'll bet you can buffer overflow the crap out of MP-RAS! It makes me want to get back to work on my fuzzer! > Version 3.3.1.8 and 3.2 and I desire to allow a user to fail login for > any reason only 3 (three) times and then lock the account. I can use > the option of FAILLIMIT=3 in the /etc/default/login file for telnet > sessions, and this will lock the account after three failed login > attempts by the user. But this does not work for SSH. I have also > placed the same option in the file of /etc/default/login.openssh > with no > such luck. By default, ssh does not call login(3). Find that in the docs under UseLogin. Please Google that also. FYI: Automatic lockout allows anyone to lock out any account by guessing or knowing the name. This actually makes another easier way for malicious gremlins to abuse your systems. My favorite prank is to scratch out a fake warning to someone that they've been fired and then lock out their account... no, I would NEVER do that... > this. It is an audit requirement here, to start locking an account > when > the user fails the login process, for any reason, after three > attempts. I always thought an audit was a fact-finding pursuit. If I were you, I would pursue a CBA for automatic lockouts. If you don't really need them to conduct your business then you should keep all accounts locked and only enable them during controlled change windows. If you do really need these accounts to support your business, then your security policy should not lock your accounts. The programmers on this list are famously paranoid and prudent about security. You might ask yourself why this feature hasn't already been implemented and widely used if it were a good idea? > Any help is appreciated. Thanks in advance for the help. Also, you probably don't want to use login(3). I strongly encourage you to seek an implementation of pam_tally if I cannot discourage this automatic lockout craziness. From djm at mindrot.org Wed Jul 12 15:35:32 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 12 Jul 2006 15:35:32 +1000 (EST) Subject: How to use SSH with Failed Login attempts and locking accounts In-Reply-To: <273CACD967F9BC47B023F758ACBC3A8C075855F4@NASEV06.hca.corpad.net> References: <273CACD967F9BC47B023F758ACBC3A8C075855F4@NASEV06.hca.corpad.net> Message-ID: On Tue, 11 Jul 2006, Hughes Andy wrote: > I have searched the FAQ's and have not seen an answer to this question. > I have also read the manuals for the SSH and have not found an answer to > this issue. > > My question is this: > > I am using openssh (OpenSSH_4.2p1, OpenSSL 0.9.8 05 Jul 2005) on > MP-RAS Version 3.3.1.8 and 3.2 and I desire to allow a user to fail > login for any reason only 3 (three) times and then lock the account. I > can use the option of FAILLIMIT=3 in the /etc/default/login file for > telnet sessions, and this will lock the account after three failed > login attempts by the user. But this does not work for SSH. I have > also placed the same option in the file of /etc/default/login.openssh > with no such luck. I don't think any of the developers has access to MP-RAS, much less implemented OpenSSH support for account lockin on it. If you are interested in implementing better support for MP-RAS, then see if you can dig out some documentation of how the FAILLIMIT is implemented, and any system APIs for working with it. As a last resort you might be able to set UseLogin in sshd_config, which will cause sshd to call /usr/bin/login directly and will hopefully inherit whatever authorisation controls that it supports. -d From pedro at bezunartea.net Thu Jul 13 02:15:48 2006 From: pedro at bezunartea.net (Pedro Bezunartea Lopez) Date: Wed, 12 Jul 2006 18:15:48 +0200 (CEST) Subject: Stange sshd problem... bug? In-Reply-To: <44B4724F.5020702@zip.com.au> References: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> <44B450A8.6010808@zip.com.au> <44B463B1.6060006@psc.edu> <44B4724F.5020702@zip.com.au> Message-ID: <33648.192.168.0.5.1152720948.squirrel@www.bezunartea.net> That did it! Thanks a lot! The thing is that my linux client box won't be using window scaling, right? That will make certain connections, or should I say large information transfers slower? I can live with that for this machine. I should also say that this affects to all connections, not just ssh. Thanks again for your help! let's hope the kernel folks can fix this soon... Pedro. > Chris Rapier wrote: >> Darren Tucker wrote: >>> Try (as root): >>> echo 0 >/proc/sys/net/ipv4/tcp_window_scaling >>> >>> and if that helps then read this for details: >>> http://kerneltrap.org/node/6723 > >> As a note: if this does work then its important to realize that you >> haven't fixed the problem you have only identified what the problem is. >> This really only swaps one set of problems for a much larger set of >> problems (albeit one of performance rather than connection >> establishment). > > That's true, and if this proves to be the reason then ideally the root > cause (ie the network device that's not handling window scaling > correctly) should be fixed. > > The catch is that this may be outside of the control of the folks > affected by it. In that case you have a choice of "fast and flaky" or > "slow and reliable", and which is preferable would depend on what you're > trying to do with it :-) > > As another aside: the assertion in that kerneltrap article that there's > a bug in OpenBSD's pf and it its handling of TCP window scaling appears > to be incorrect (although it is possible to misconfigure pf to cause > this problem, see http://www.benzedrine.cx/pf/msg05117.html). > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From rapier at psc.edu Thu Jul 13 03:36:11 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 12 Jul 2006 13:36:11 -0400 Subject: Stange sshd problem... bug? In-Reply-To: <33648.192.168.0.5.1152720948.squirrel@www.bezunartea.net> References: <1372.192.168.0.5.1152667244.squirrel@www.bezunartea.net> <44B450A8.6010808@zip.com.au> <44B463B1.6060006@psc.edu> <44B4724F.5020702@zip.com.au> <33648.192.168.0.5.1152720948.squirrel@www.bezunartea.net> Message-ID: <44B5330B.8080501@psc.edu> Pedro Bezunartea Lopez wrote: > That did it! Thanks a lot! The thing is that my linux client box won't be > using window scaling, right? That will make certain connections, or should > I say large information transfers slower? I can live with that for this > machine. Yes, you'll effectively be limited to window scale of 0 which puts your maximum buffer at 64k. You won't see a problem unless your bandwidth delay product (BDP) exceeds that value. You can determine your BDP by multiplying the bandwidth by the round trip time. > I should also say that this affects to all connections, not just ssh. Yes. This will impact all of your connections. > Thanks again for your help! let's hope the kernel folks can fix this soon... Well, its not something that the linux kernel people need to fix. In fact, having this problem come up is probably a good thing as it will spur people to fix the problems in the intermediate boxes. From vinschen at redhat.com Sat Jul 15 00:05:40 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 14 Jul 2006 16:05:40 +0200 Subject: Problems accessing CVS repository Message-ID: <20060714140540.GA4110@calimero.vinschen.de> Hi, I have persistent problems to access the OpenSSH CVS repository as anonymous user, once it has been checked out: $ cvs -d anoncvs at anoncvs.mindrot.org:/cvs co openssh [...works fine...] $ cd openssh $ cvs up cannot create_adm_p /tmp/cvs-serv5471/contrib Permission denied The same happens when trying to use the second repository: $ cvs -d anoncvs at anoncvs2.at.openbsd.org:/openssh co openssh_cvs [...works fine...] $ cd openssh_cvs $ cvs up cannot create_adm_p /tmp/cvs-serv6828/contrib Permission denied This looks like a server problem. Or am I doing something wrong? I never had this problem with cvs before and I still haven't with other cvs servers. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Sat Jul 15 01:19:15 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 15 Jul 2006 01:19:15 +1000 Subject: Problems accessing CVS repository In-Reply-To: <20060714140540.GA4110@calimero.vinschen.de> References: <20060714140540.GA4110@calimero.vinschen.de> Message-ID: <44B7B5F3.6020804@zip.com.au> Corinna Vinschen wrote: > Hi, > > I have persistent problems to access the OpenSSH CVS repository as > anonymous user, once it has been checked out: > > $ cvs -d anoncvs at anoncvs.mindrot.org:/cvs co openssh > [...works fine...] > $ cd openssh > $ cvs up > cannot create_adm_p /tmp/cvs-serv5471/contrib > Permission denied [...] > This looks like a server problem. Or am I doing something wrong? > I never had this problem with cvs before and I still haven't with > other cvs servers. It appears to be a repository problem: cvs seems to need an "Emptydir" directory in CVSROOT, which is missing from the repository. I have created CVSROOT/Emptydir it on my copy (anoncvs.mindrot.org) and told the sync script to leave it alone, which seems to have at least worked around the problem for now... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Sat Jul 15 02:12:47 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 14 Jul 2006 18:12:47 +0200 Subject: Problems accessing CVS repository In-Reply-To: <44B7B5F3.6020804@zip.com.au> References: <20060714140540.GA4110@calimero.vinschen.de> <44B7B5F3.6020804@zip.com.au> Message-ID: <20060714161247.GN8759@calimero.vinschen.de> On Jul 15 01:19, Darren Tucker wrote: > Corinna Vinschen wrote: > > Hi, > > > > I have persistent problems to access the OpenSSH CVS repository as > > anonymous user, once it has been checked out: > > > > $ cvs -d anoncvs at anoncvs.mindrot.org:/cvs co openssh > > [...works fine...] > > $ cd openssh > > $ cvs up > > cannot create_adm_p /tmp/cvs-serv5471/contrib > > Permission denied > [...] > > This looks like a server problem. Or am I doing something wrong? > > I never had this problem with cvs before and I still haven't with > > other cvs servers. > > It appears to be a repository problem: cvs seems to need an "Emptydir" > directory in CVSROOT, which is missing from the repository. > > I have created CVSROOT/Emptydir it on my copy (anoncvs.mindrot.org) and > told the sync script to leave it alone, which seems to have at least > worked around the problem for now... That works for me, too. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Sat Jul 15 12:03:24 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Jul 2006 12:03:24 +1000 Subject: Problems accessing CVS repository In-Reply-To: <44B7B5F3.6020804@zip.com.au> References: <20060714140540.GA4110@calimero.vinschen.de> <44B7B5F3.6020804@zip.com.au> Message-ID: <44B84CEC.9020304@mindrot.org> Darren Tucker wrote: > It appears to be a repository problem: cvs seems to need an "Emptydir" > directory in CVSROOT, which is missing from the repository. should be fixed now From tryponraj at gmail.com Sat Jul 15 18:59:59 2006 From: tryponraj at gmail.com (ponraj) Date: Sat, 15 Jul 2006 14:29:59 +0530 Subject: ssh-keyscan exits in mid-way Message-ID: <007901c6a7ed$13185f90$180110ac@pomco> Hello All, Im using OpenSSH 4.3p2 and tyring to scan a list of 40 machines in my network with ssh-keyscan utility. I used the following command, ssh-keyscan -t rsa -f hosts.txt The man page says that this utility displays the host keys irrespective of ssh or host is up/down and its working great. But in case if the scan stops at 30th host due to some protocol problems, the utility exits and don't display the host keys for remaining machines. I think this is an expected behaviour, but it would be better to ignore that host continue till the end or atleast this can be documented specifically in the man page. Any comments? Thanks, Ponraj M From ryan at neomindstudio.com Sun Jul 16 01:00:02 2006 From: ryan at neomindstudio.com (Ryan Findley) Date: Sat, 15 Jul 2006 11:00:02 -0400 Subject: patch to add built-in support for port knocking Message-ID: All, A friend gave me access to an svn(+ssh) repository the other day, and told me that I needed to do some port knocking to open up ssh. It occurred to me that it would be extremely convenient if I could add a "knock" configuration option for the host to my ~/.ssh/config file and never think about this again (rather than creating a shell script to accomplish this behavior, and remembering to use it for remote access and svn activity). After some pretty small changes to ssh.c and readconf.c, my dream is now a reality. Might I be able to convince the good people of OpenSSH to consider adding my changes to CVS? If so, What do I have to do? Thanks for your time, -ryan findley From dtucker at zip.com.au Sun Jul 16 16:35:47 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 16 Jul 2006 16:35:47 +1000 Subject: patch to add built-in support for port knocking In-Reply-To: References: Message-ID: <20060716063547.GA23921@gate.dtucker.net> On Sat, Jul 15, 2006 at 11:00:02AM -0400, Ryan Findley wrote: > A friend gave me access to an svn(+ssh) repository the other day, and > told me that I needed to do some port knocking to open up ssh. It > occurred to me that it would be extremely convenient if I could add a > "knock" configuration option for the host to my ~/.ssh/config file > and never think about this again (rather than creating a shell script > to accomplish this behavior, and remembering to use it for remote > access and svn activity). You can do it from ~/.ssh/config already with a ProxyCommand. Make yourself a little shell script that does the portknocking then execs connect or netcat, like so: #!/bin/sh your_portknock_command $1 && exec /usr/bin/nc $1 $2 Then, add it to ~/.ssh/config: Host svnserver.example.com ProxyCommand /usr/local/bin/portknock_connect %h %p > After some pretty small changes to ssh.c and readconf.c, my dream is > now a reality. > Might I be able to convince the good people of OpenSSH to consider > adding my changes to CVS? It's unlikely. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From gopal.mahesh at wipro.com Mon Jul 17 14:45:14 2006 From: gopal.mahesh at wipro.com (gopal.mahesh at wipro.com) Date: Mon, 17 Jul 2006 10:15:14 +0530 Subject: I am getting the following error Message-ID: <34510F8FB9D8A34EA7F337CDE858FD220720FA@BLR-EC-MBX02.wipro.com> Hi I am getting the following error so please help me to slove the issue ./configure --prefix=/opt checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details Regards Mahesh.G Nortel SDE The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From cmynhier at gmail.com Mon Jul 17 23:36:28 2006 From: cmynhier at gmail.com (Chad Mynhier) Date: Mon, 17 Jul 2006 09:36:28 -0400 Subject: SMF/process contracts in Solaris 10 Message-ID: <3cf3989e0607170636l1ba420f0t7f317b454705baa@mail.gmail.com> I've searched the archive for this mailing list and the bug list for OpenSSH for this, and I'm finding nothing. I'd appreciate it if somoene could point me to an existing thread about this. (I know that other people are aware of the problem, though, so I'm a bit surprised to find nothing.) We're running OpenSSH under Solaris 10 using SMF instead of a legacy init script. SMF isn't doing the right thing WRT sshd. For example, SMF should be able to restart sshd if it's killed, but it's not currently doing so and reports the service as being online. I tracked down the problem to the fact that OpenSSH does not put child processes into separate process contracts. There are two side-effects to this omission. The first is the problem I describe above. Because sshd does not put child processes into searate process contracts, every process in the tree rooted at the parent sshd is in the same process contract (assuming no other process is creating new process contracts.) When the parent sshd process is killed, there are other live processes in that contract, thus SMF thinks the service is still online. There's a flipside to this problem, in that a 'svcadm disable' of OpenSSH will cause every process in that tree to be terminated. This would include daemons that have been started manually from someone's ssh session. I've fixed this problem locally by patching sshd.c with the contract-specific code from Sun's sshd.c. I would submit a patch based on that, but I'm not fully aware of the OpenSSH policy on Sun's ssh code. Chad Mynhier From kerwyn.marshall at gsa.gov Fri Jul 14 07:34:23 2006 From: kerwyn.marshall at gsa.gov (kerwyn.marshall at gsa.gov) Date: Thu, 13 Jul 2006 17:34:23 -0400 Subject: Need help with installing first time ? Message-ID: Need help with installing first time, how can I contact via phone ! From djm at mindrot.org Tue Jul 18 10:08:38 2006 From: djm at mindrot.org (Damien Miller) Date: Tue, 18 Jul 2006 10:08:38 +1000 (EST) Subject: SMF/process contracts in Solaris 10 In-Reply-To: <3cf3989e0607170636l1ba420f0t7f317b454705baa@mail.gmail.com> References: <3cf3989e0607170636l1ba420f0t7f317b454705baa@mail.gmail.com> Message-ID: On Mon, 17 Jul 2006, Chad Mynhier wrote: > I've fixed this problem locally by patching sshd.c with the > contract-specific code from Sun's sshd.c. I would submit a patch > based on that, but I'm not fully aware of the OpenSSH policy on Sun's > ssh code. We would be interested in a fix, but not if it is derived from Sun code. Their license is unacceptable. -d From tryponraj at gmail.com Wed Jul 19 14:34:57 2006 From: tryponraj at gmail.com (ponraj) Date: Wed, 19 Jul 2006 10:04:57 +0530 Subject: ssh-keyscan exits in mid-way Message-ID: <00ac01c6aaec$b467c0a0$180110ac@pomco> I digged up this problem further and find my results below. ssh-keyscan ignores the hosts if they are not up or sshd is not running when used with -f option. But when it encounters any error while retrieving the host key from the machine which is up and have sshd running, it simply exits. This may happen due to transport layer implementation in packet.c at packet_read_poll_seqnr() which results in exiting. My guess is that as packet.c is utilised by all OpenSSH utilities including ssh-keyscan, we can't make ssh-keyscan to continue with remaining hosts as specified in -f in case of an error. But I also vote for atleast documenting this one. regards, M.P ----- Original Message ----- From: "ponraj" To: Sent: Saturday, July 15, 2006 2:29 PM Subject: ssh-keyscan exits in mid-way > Hello All, > > Im using OpenSSH 4.3p2 and tyring to scan a list of 40 machines in my > network with ssh-keyscan utility. I used the following command, > > ssh-keyscan -t rsa -f hosts.txt > > The man page says that this utility displays the host keys irrespective of > ssh or host is up/down and its working great. But in case if the scan > stops at 30th host due to some protocol problems, the utility exits and > don't display the host keys for remaining machines. I think this is an > expected behaviour, but it would be better to ignore that host continue > till the end or atleast this can be documented specifically in the man > page. > > Any comments? > > Thanks, > Ponraj M From djm at mindrot.org Wed Jul 19 14:53:47 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 19 Jul 2006 14:53:47 +1000 (EST) Subject: ssh-keyscan exits in mid-way In-Reply-To: <00ac01c6aaec$b467c0a0$180110ac@pomco> References: <00ac01c6aaec$b467c0a0$180110ac@pomco> Message-ID: On Wed, 19 Jul 2006, ponraj wrote: > I digged up this problem further and find my results below. > > ssh-keyscan ignores the hosts if they are not up or sshd is not > running when used with -f option. But when it encounters any > error while retrieving the host key from the machine which is up and > have sshd running, it simply exits. This may happen due to transport > layer implementation in packet.c at packet_read_poll_seqnr() which > results in exiting. > > My guess is that as packet.c is utilised by all OpenSSH utilities > including ssh-keyscan, we can't make ssh-keyscan to continue with > remaining hosts as specified in -f in case of an error. But I > also vote for atleast documenting this one. ssh-keyscan could probably do with a cleanup_exit() implementation that looks at nonfatal_fatal, like its fatal() implmenetation does. This would obviously need to be done carefully. By the way, when you report problems please include debug traces. Saying that "ssh-keyscan exits in mid-way" doesn't give enough information for anyone to help you. Posting a debug trace from "ssh-keyscan -vvv" would. -d From tryponraj at gmail.com Wed Jul 19 19:07:27 2006 From: tryponraj at gmail.com (ponraj) Date: Wed, 19 Jul 2006 14:37:27 +0530 Subject: ssh-keyscan exits in mid-way References: <00ac01c6aaec$b467c0a0$180110ac@pomco> Message-ID: <012701c6ab12$c7e0fe50$180110ac@pomco> Hi all, Debug trace is given below. # ssh-keyscan -vvv host.server.com debug2: fd 3 setting O_NONBLOCK debug1: no match: mpSSH_0.1.0 debug1: host.server.com doesn't support ssh1 # ssh -vvv host.server.com OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005 HP-UX Secure Shell-A.04.30.005, HP-UX Secure Shell version debug1: Reading configuration data /opt/ssh/etc/ssh_config debug3: RNG is ready, skipping seeding debug2: ssh_connect: needpriv 0 debug1: Connecting to host.server.com [15.244.96.225] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/3 debug1: identity file /.ssh/identity type 0 debug3: Not a RSA1 key file /.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /.ssh/id_rsa type 1 debug3: Not a RSA1 key file /.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version mpSSH_0.1.0 debug1: no match: mpSSH_0.1.0 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3p2-hpn debug2: fd 4 setting O_NONBLOCK debug3: RNG is ready, skipping seeding debug1: SSH2_MSG_KEXINIT sent Received disconnect from 15.244.96.225: 11: SSH Disabled -- M.P ----- Original Message ----- From: "Damien Miller" To: "ponraj" Cc: Sent: Wednesday, July 19, 2006 10:23 AM Subject: Re: ssh-keyscan exits in mid-way > On Wed, 19 Jul 2006, ponraj wrote: > >> I digged up this problem further and find my results below. >> >> ssh-keyscan ignores the hosts if they are not up or sshd is not >> running when used with -f option. But when it encounters any >> error while retrieving the host key from the machine which is up and >> have sshd running, it simply exits. This may happen due to transport >> layer implementation in packet.c at packet_read_poll_seqnr() which >> results in exiting. >> >> My guess is that as packet.c is utilised by all OpenSSH utilities >> including ssh-keyscan, we can't make ssh-keyscan to continue with >> remaining hosts as specified in -f in case of an error. But I >> also vote for atleast documenting this one. > > ssh-keyscan could probably do with a cleanup_exit() implementation > that looks at nonfatal_fatal, like its fatal() implmenetation does. > This would obviously need to be done carefully. > > By the way, when you report problems please include debug traces. Saying > that "ssh-keyscan exits in mid-way" doesn't give enough information > for anyone to help you. Posting a debug trace from "ssh-keyscan -vvv" > would. > > -d > From tryponraj at gmail.com Wed Jul 19 19:44:42 2006 From: tryponraj at gmail.com (ponraj) Date: Wed, 19 Jul 2006 15:14:42 +0530 Subject: ssh-keyscan exits in mid-way References: <00ac01c6aaec$b467c0a0$180110ac@pomco> <012701c6ab12$c7e0fe50$180110ac@pomco> Message-ID: <013a01c6ab17$f9f4df10$180110ac@pomco> Hi all, Detailed debug traces of "ssh-keyscan" is given below. # ssh-keyscan -vvv -t rsa host.server.com debug2: fd 3 setting O_NONBLOCK debug1: no match: mpSSH_0.1.0 # host.server.com SSH-2.0-mpSSH_0.1.0 debug1: Enabling compatibility mode for protocol 2.0 debug3: RNG is ready, skipping seeding debug1: SSH2_MSG_KEXINIT sent Received disconnect from 15.244.96.225: 11: SSH Disabled -- M.P ----- Original Message ----- From: "ponraj" To: "Damien Miller" Cc: Sent: Wednesday, July 19, 2006 2:37 PM Subject: Re: ssh-keyscan exits in mid-way > Hi all, > > Debug trace is given below. > > # ssh-keyscan -vvv host.server.com > debug2: fd 3 setting O_NONBLOCK > debug1: no match: mpSSH_0.1.0 > debug1: host.server.com doesn't support ssh1 > > # ssh -vvv host.server.com > OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005 > HP-UX Secure Shell-A.04.30.005, HP-UX Secure Shell version > debug1: Reading configuration data /opt/ssh/etc/ssh_config > debug3: RNG is ready, skipping seeding > debug2: ssh_connect: needpriv 0 > debug1: Connecting to host.server.com [15.244.96.225] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/3 > debug1: identity file /.ssh/identity type 0 > debug3: Not a RSA1 key file /.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /.ssh/id_rsa type 1 > debug3: Not a RSA1 key file /.ssh/id_dsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /.ssh/id_dsa type 2 > debug1: Remote protocol version 2.0, remote software version mpSSH_0.1.0 > debug1: no match: mpSSH_0.1.0 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3p2-hpn > debug2: fd 4 setting O_NONBLOCK > debug3: RNG is ready, skipping seeding > debug1: SSH2_MSG_KEXINIT sent > Received disconnect from 15.244.96.225: 11: SSH Disabled > > > -- > M.P > > ----- Original Message ----- > From: "Damien Miller" > To: "ponraj" > Cc: > Sent: Wednesday, July 19, 2006 10:23 AM > Subject: Re: ssh-keyscan exits in mid-way > > >> On Wed, 19 Jul 2006, ponraj wrote: >> >>> I digged up this problem further and find my results below. >>> >>> ssh-keyscan ignores the hosts if they are not up or sshd is not >>> running when used with -f option. But when it encounters any >>> error while retrieving the host key from the machine which is up and >>> have sshd running, it simply exits. This may happen due to transport >>> layer implementation in packet.c at packet_read_poll_seqnr() which >>> results in exiting. >>> >>> My guess is that as packet.c is utilised by all OpenSSH utilities >>> including ssh-keyscan, we can't make ssh-keyscan to continue with >>> remaining hosts as specified in -f in case of an error. But I >>> also vote for atleast documenting this one. >> >> ssh-keyscan could probably do with a cleanup_exit() implementation >> that looks at nonfatal_fatal, like its fatal() implmenetation does. >> This would obviously need to be done carefully. >> >> By the way, when you report problems please include debug traces. Saying >> that "ssh-keyscan exits in mid-way" doesn't give enough information >> for anyone to help you. Posting a debug trace from "ssh-keyscan -vvv" >> would. >> >> -d >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From yusefram at yahoo.ie Wed Jul 19 16:55:14 2006 From: yusefram at yahoo.ie (yusef ramsey) Date: Wed, 19 Jul 2006 06:55:14 +0000 (GMT) Subject: maybe bug don't allow compile Message-ID: <20060719065514.5008.qmail@web27806.mail.ukl.yahoo.com> I'm using mandrake linux 10.0 I compile myself zlib 1.2.3 (sucess), openssl 0.9.8b (sucess), then openssh-4.3p2 (fail) with error like "undefined reference to 'dlerror'" make: *** [ssh] Error 1. I think problem for me was no libdl included in LIBS in top Makefile, so I manually add -ldl to LIBS variable and compile works. If this is bug in ./configure please fix, if I did something wrong in compile, please tell me. Cheers! Yusef From companycartuchos at dglnet.com.br Thu Jul 20 05:24:29 2006 From: companycartuchos at dglnet.com.br (Company Cartuchos) Date: Wed, 19 Jul 2006 16:24:29 -0300 Subject: =?iso-8859-1?Q?Promo=E7=E3o_Imperd=EDvel_HP?= Message-ID: <9ef293861ed04b21f7e271abe8b0e66e@www.companycartuchos.com.br> [1][cid:topo.gif] [img_01.jpg] [img_02.jpg] [img_03.jpg] [img_04.jpg] [img_05.jpg] [img_06.jpg] [img_07.jpg] [img_08.jpg] [img_09.jpg] [img_10.jpg] [img_11.jpg] [img_12.jpg] [img_13.jpg] [img_14.jpg] [img_15.jpg] [img_16.jpg] [img_17.jpg] [img_18.jpg] [img_19.jpg] [img_20.jpg] [img_21.jpg] [img_22.jpg] [2][USEMAP:img_23.jpg] [3][USEMAP:img_24.jpg] [4][USEMAP:img_25.jpg] [img_26.jpg] [img_27.jpg] [5][USEMAP:img_28.jpg] [6][USEMAP:img_29.jpg] [7][USEMAP:img_30.jpg] [img_31.jpg] [img_32.jpg] [img_33.jpg] [img_34.jpg] [img_35.jpg] [img_36.jpg] [img_37.jpg] [img_38.jpg] [img_39.jpg] [img_40.jpg] [8][cid:txt.gif] [9][cid:quit.gif] [10][thumb.php?id=m4&view=540282&key=cbc9fca708b9e401d2fe52b5649efaef& sview=1] References 1. http://www.companycartuchos.com.br/sistema/preview.php?key=cbc9fca708b9e401d2fe52b5649efaef&aid=52&uid=958533 2. LYNXIMGMAP:file://localhost/tmp/tmp4nk_07.html#FPMap2 3. LYNXIMGMAP:file://localhost/tmp/tmp4nk_07.html#FPMap0 4. LYNXIMGMAP:file://localhost/tmp/tmp4nk_07.html#FPMap1 5. LYNXIMGMAP:file://localhost/tmp/tmp4nk_07.html#FPMap3 6. LYNXIMGMAP:file://localhost/tmp/tmp4nk_07.html#FPMap4 7. LYNXIMGMAP:file://localhost/tmp/tmp4nk_07.html#FPMap5 8. mailto:info at m4all.com.br 9. http://www.companycartuchos.com.br/sistema/functions/unsubscribe.php?key=e57c6b956a6521b28495f2886ca0977a&id=958533&uid=1 10. http://www.m4all.com.br/ From dtucker at zip.com.au Thu Jul 20 08:07:24 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Jul 2006 08:07:24 +1000 Subject: maybe bug don't allow compile In-Reply-To: <20060719065514.5008.qmail@web27806.mail.ukl.yahoo.com> References: <20060719065514.5008.qmail@web27806.mail.ukl.yahoo.com> Message-ID: <44BEAD1C.7090705@zip.com.au> yusef ramsey wrote: > I'm using mandrake linux 10.0 I compile myself zlib 1.2.3 (sucess), > openssl 0.9.8b (sucess), then openssh-4.3p2 (fail) with error like > "undefined reference to 'dlerror'" make: *** [ssh] Error 1. > > I think problem for me was no libdl included in LIBS in top Makefile, > so I manually add -ldl to LIBS variable and compile works. It's a known problem with configure. OpenSSL 0.9.8x (or at least some configurations?) require libdl whereas previous versions (usually?) didn't. http://bugzilla.mindrot.org/show_bug.cgi?id=1181 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From richardm at br.ibm.com Thu Jul 20 06:14:41 2006 From: richardm at br.ibm.com (richardm at br.ibm.com) Date: Wed, 19 Jul 2006 17:14:41 -0300 Subject: ssh without encryption Message-ID: Greetings, I'm using the openssh server inside a simulator and it is very slow to login and use. I would like, then, to disable encryption between the machine that hosts the simulator and the simulator itself. Unfortunaly, I didn't found a way to do that. Could you, please, tell how can I do that? Or, if that's not possible, how can I reduce ssh encrypted connection overhead, so it actually becomes usable on the simulator? Thanks for your help! Richard Maciel Costa From rapier at psc.edu Fri Jul 21 00:42:58 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 20 Jul 2006 10:42:58 -0400 Subject: ssh without encryption In-Reply-To: References: Message-ID: <44BF9672.9000505@psc.edu> > Greetings, > > I'm using the openssh server inside a simulator and it is very slow to > login and use. I would like, then, to disable encryption between the > machine that hosts the simulator and the simulator itself. Unfortunaly, I > didn't found a way to do that. > Could you, please, tell how can I do that? Or, if that's not possible, how > can I reduce ssh encrypted connection overhead, so it actually becomes > usable on the simulator? > > Thanks for your help! Are you sure its an encryption issue? For the most part encryption, especially in interactive sessions, has minimal impact on the user experience. Do you think you could verify how much of an additional load this is placing on the CPU? Also, could you tell us if its an interactive or bulk data session? Now, if you want to just try *something* you should make sure you are using a lightweight cipher like RC4 by using -c arcfour in the command line. If you do see an improvement over the default 3DES (that is still the default isn't it? As an aside does this still make sense?) then it might be a CPU bounding issue. You say you are using a simulator - do you know what the simulated RTT is like? I'm thinking that could be a much more likely source of performance issues that the encryption. Chris From andreas at schigold.de Fri Jul 21 07:30:12 2006 From: andreas at schigold.de (Andreas Schigold) Date: Thu, 20 Jul 2006 23:30:12 +0200 Subject: new feature MaxIdleTime Message-ID: <44BFF5E4.6080904@schigold.de> Hello, in the company I work for we have an ISDN-router is dialing automatic to a special machine if a special IP-address is called by a client-PC inside the company. So we maintain the machines of our customers. But there is one problem: We cannot say to this router "hang up - I'm ready". So he has a configured idle timeout after this time he hang up by himself. So we need a short idle timeout to save money after closing of connection. But the service stuff maintains the machines is unhappy since the connection to many machines often goes to sleep and to the other machines the line breaks since there is a VPN or WAN connection on customers side. Okay, we can set one of the options TCPKeepAlive or ServerAliveInterval. But there is one problem: If a colleague forgets to close the ssh-session, it is living until the judgement day. So I searched for a solution supports 2 levels of idle timeout * a short timeout, if we want to close a session and * a long timeout, if a session is forgotten. After a long searching and thinking my only idea was to expand the ssh for our advantage. The result of my work you will find behind the link [1]http://schigold.de/openssh/index.html . I hope you will find it usefull and I'm close to the coding rules. If you want to put my result into one of the next versions, it would have two advantages to me. If my administrator upgrades the ssh, I don't need to reexpand the next version and if you accept my work he will accept this too. If you don't want to accept my patch, please tell me why and if I can do anything for your acceptence, please let me know. If you have questions, please ask me. If you accept it, please let me know the version you will put it in. Here I want to describe a use case: * we can set the idle timeout of the ISDN-router to - let's say - 10 Seconds * we can call our machines with "ssh -oServerAliveInterval=3 -oMaxIdleTime=180 user at machine-ip" * if the user closes the connection, ISDN-line hangs up 10 Seconds later * if the user interruptes his interaction for what ever (i.e. search something he needs to continue) he has a time window of 3 minutes * if the user forget to close the session, it closes by itself 3 minutes later, ISDN-line hangs up 3 minutes and 10 Seconds after last interaction During such a session a user may start different programms inside the login shell, i.e. midnight commander or our special service tools. If the service employee forgets to close all these programms then the shell environment variable TMOUT won't work for us. I discussed the topic in [2]tech at openbsd.org first and one poster ment, I should discuss it now here. Important: If the parameter is unused or set to 0 the behavior of "ssh" should be unchanged in compare with before. If it is used the behavior should be the same like a user closes the connection by itself after the configured idle-time (except this one printout that the idle-timeout happened) Also important: In my point of view the security and stability issues should be close untouched. But if you detect errors or problems I have to solve, please give me informations to my fault and give me the chance to make it better But very important: If I made errors (in programming or in the procedure) please help me since it is my first action in a free project. kind regards Andreas Schigold -- ############################# # Andreas Schigold # # mail: [3]andreas at schigold.de # ############################# References 1. http://schigold.de/openssh/index.html 2. mailto:tech at openbsd.org 3. mailto:andreas at schigold.de From weiler at soe.ucsc.edu Sun Jul 23 01:28:32 2006 From: weiler at soe.ucsc.edu (Erich Weiler) Date: Sat, 22 Jul 2006 08:28:32 -0700 Subject: OpenSSH and Solaris SEAM/Kerberos Message-ID: <44C24420.2040503@soe.ucsc.edu> Greetings all, I hope this is the right place to ask this question, if not please redirect me. I'm compiling OpenSSH 4.3p2 on Solaris 9, and want to compile with Kerberos5 support. However, since we are using Solaris SEAM for Kerberos, I can't seem to specify "--with-kerberos5=PATH" during configure because it doesn't look like SEAM's gssapi libraries are all in one place, and I'm betting they have different filenames than MIT's kerberos libs as well... And krb5.conf is in /etc/krb5/krb5.conf, not /etc/krb5.conf (although I'm sure I could make a link to fix that)... Has anybody compiled OpenSSH against Sun's SEAM successfully? Or know of a better place for me to ask such a thing? Thanks in advance, erich From martinson.jacob at gmail.com Sun Jul 23 03:15:07 2006 From: martinson.jacob at gmail.com (jacob martinson) Date: Sat, 22 Jul 2006 12:15:07 -0500 Subject: two factor authentication Message-ID: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> Are there any plans on the table to add native support for two-factor authentication, such as password *and* public key? Visa PCI standards require two-factor authentication for remote access and if password+key was available in openssh it would be much easier to maintain and support than a full-blown vpn with all the cross-platform compatibility issues that come with one. Thanks! Jacob From alon.barlev at gmail.com Sun Jul 23 04:13:39 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 22 Jul 2006 21:13:39 +0300 Subject: two factor authentication In-Reply-To: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> Message-ID: <44C26AD3.8020201@gmail.com> jacob martinson wrote: > Are there any plans on the table to add native support for two-factor > authentication, such as password *and* public key? > > Visa PCI standards require two-factor authentication for remote access > and if password+key was available in openssh it would be much easier > to maintain and support than a full-blown vpn with all the > cross-platform compatibility issues that come with one. Well... This depends on interpretation of what is two factor authentication... The regular interpretation is "something you have" and "something you know". "something you have" is usually smartcard device, although using files for poor people can also be accepted if high security is not needed. "something you know" is usually a password for a server (when you use one factor authentication), or password to access the private key on two factor authentication. Since private key is stronger than password, there is no real sense in not protecting the private key it-self using "something you know", and negotiate remote authentication by the stronger mechanism, which resides on "something you have". There is a limited smartcard support in openssh for opensc cards. There is more generic PKCS#11 support available at external patch at http://alon.barlev.googlepages.com/openssh-pkcs11 Best Regards, Alon Bar-Lev. From fcusack at fcusack.com Sun Jul 23 09:43:50 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Sat, 22 Jul 2006 16:43:50 -0700 Subject: two factor authentication In-Reply-To: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> Message-ID: On July 22, 2006 12:15:07 PM -0500 jacob martinson wrote: > Are there any plans on the table to add native support for two-factor > authentication, such as password *and* public key? You can already do that. Public key is itself already 2-factor -- something you know (the pin/passcode) and something you have (the device on which the public key resides). Password, via PAM or BSDAUTH, allows any two factor device the host (server) system supports. > Visa PCI standards require two-factor authentication for remote access > and if password+key was available in openssh it would be much easier > to maintain and support than a full-blown vpn with all the > cross-platform compatibility issues that come with one. Well, requiring 2 *types* of authentication may not fulfill a 2-factor authentication requirement, at least not the intent. You are clearly trying to do away with a hardware token requirement (otherwise the hardward token alone is enough for 2-factor), so having a software public key is likely to be either protected by the same password as used for the password part of the authentication, or not protected at all. So if I obtained the password, for sure I would need at least temporary access to the client system to obtain the public key, but once that was achieved, I have the public key and that's that. Note the difference between "real" 2-factor auth, where temporary access to the device only gives me temporary access to the server (assuming the passcode/pin is already known). If we don't include windows, then it's pretty easy to deploy a token- based 2-factor system; all modern unices and network devices will work with either pam/bsdauth or radius and give you pretty easy to deploy 2-factor auth. If your reason to require password + public key is to avoid some implementation cost while meeting Visa standards, I suggest you consider that an audit (say post-compromise) will reveal that your method is really only 2-factor in name (given typical user behavior). The cost of deploying a cross-platform token solution is pretty low. If you got down this far, check out www.tri-dsystems.com (full disclosure: they are my employer) for 2- and 3-factor solutions. -frank From dtucker at zip.com.au Sun Jul 23 10:16:12 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 23 Jul 2006 10:16:12 +1000 Subject: two factor authentication In-Reply-To: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> Message-ID: <44C2BFCC.5090904@zip.com.au> jacob martinson wrote: > Are there any plans on the table to add native support for two-factor > authentication, such as password *and* public key? Answering the second part first, yes, it's an open enhancement request (http://bugzilla.mindrot.org/show_bug.cgi?id=983). Going back to the first part: while requiring both password and public-key would probably improve security, personally I think the private key is another instance of "something you know" (although with the useful property of being able to prove you know it without disclosing it) since it can be copied, printed out, emailed... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From fcusack at fcusack.com Sun Jul 23 11:27:25 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Sat, 22 Jul 2006 18:27:25 -0700 Subject: two factor authentication In-Reply-To: <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> Message-ID: <5E8F428A0912845573CA331B@manatee.local> On July 22, 2006 7:08:59 PM -0500 jacob martinson wrote: > On 7/22/06, Frank Cusack wrote: >> On July 22, 2006 12:15:07 PM -0500 jacob martinson wrote: >> > Are there any plans on the table to add native support for two-factor >> > authentication, such as password *and* public key? >> >> You can already do that. Public key is itself already 2-factor -- >> something you know (the pin/passcode) and something you have (the >> device on which the public key resides). Password, via PAM or BSDAUTH, >> allows any two factor device the host (server) system supports. >> > > You can? How can you configure ssh to require both successful > password authentication (via the underlying OS password verification > mechanisms) and public key auth before the user is allowed onto the > system? Sorry, I meant you can already do native 2-factor auth via publickey or via password alone. > Public key is only single factor. All you need to know to > authenticate is the private key. There is no way to enforce > passphrase protection of the private from the server's perspective so > - unless I'm missing something - that isn't two-factor. You are correct, for files on disk. But publickey can also be used with smartcards and via control of authorized_keys or using X.509 (there's a patch for that) you can restrict to keys known to be protected by a pin/passphrase. Or if the environment is small enough and you can trust your users to have good passphrases you can probably claim 2-factor. The server doesn't enforce that but your policy can. (in limited cases) -frank From martinson.jacob at gmail.com Sun Jul 23 10:08:59 2006 From: martinson.jacob at gmail.com (jacob martinson) Date: Sat, 22 Jul 2006 19:08:59 -0500 Subject: two factor authentication In-Reply-To: References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> Message-ID: <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> On 7/22/06, Frank Cusack wrote: > On July 22, 2006 12:15:07 PM -0500 jacob martinson wrote: > > Are there any plans on the table to add native support for two-factor > > authentication, such as password *and* public key? > > You can already do that. Public key is itself already 2-factor -- > something you know (the pin/passcode) and something you have (the > device on which the public key resides). Password, via PAM or BSDAUTH, > allows any two factor device the host (server) system supports. > You can? How can you configure ssh to require both successful password authentication (via the underlying OS password verification mechanisms) and public key auth before the user is allowed onto the system? Public key is only single factor. All you need to know to authenticate is the private key. There is no way to enforce passphrase protection of the private from the server's perspective so - unless I'm missing something - that isn't two-factor. From william at 25thandClement.com Sun Jul 23 13:27:28 2006 From: william at 25thandClement.com (William Ahern) Date: Sat, 22 Jul 2006 20:27:28 -0700 Subject: two factor authentication In-Reply-To: <44C2BFCC.5090904@zip.com.au> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> Message-ID: <20060723032728.GA13075@orville.25thandClement.com> On Sun, Jul 23, 2006 at 10:16:12AM +1000, Darren Tucker wrote: > jacob martinson wrote: > > Are there any plans on the table to add native support for two-factor > > authentication, such as password *and* public key? > > Answering the second part first, yes, it's an open enhancement request > (http://bugzilla.mindrot.org/show_bug.cgi?id=983). > > Going back to the first part: while requiring both password and > public-key would probably improve security, personally I think the > private key is another instance of "something you know" (although with > the useful property of being able to prove you know it without > disclosing it) since it can be copied, printed out, emailed... > Excluding public keys exported from a smart card. For real smart cards (i.e. not USB memory sticks w/ a PKCS#11 library), the private key is not known even by the user holding the card (unless you work at IBM and own an electron scanning microscope). From dtucker at zip.com.au Sun Jul 23 13:32:46 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 23 Jul 2006 13:32:46 +1000 Subject: two factor authentication In-Reply-To: <20060723032728.GA13075@orville.25thandClement.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> Message-ID: <44C2EDDE.1080707@zip.com.au> William Ahern wrote: > On Sun, Jul 23, 2006 at 10:16:12AM +1000, Darren Tucker wrote: >> Going back to the first part: while requiring both password and >> public-key would probably improve security, personally I think the >> private key is another instance of "something you know" (although with >> the useful property of being able to prove you know it without >> disclosing it) since it can be copied, printed out, emailed... > > Excluding public keys exported from a smart card. For real smart cards (i.e. > not USB memory sticks w/ a PKCS#11 library), the private key is not known > even by the user holding the card (unless you work at IBM and own an > electron scanning microscope). That's true, and I should have mentioned it. My statement above applies only to the standard file-based public-key authentication (ie ~/.ssh/id_rsa and friends). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From william at 25thandClement.com Sun Jul 23 13:56:21 2006 From: william at 25thandClement.com (William Ahern) Date: Sat, 22 Jul 2006 20:56:21 -0700 Subject: two factor authentication In-Reply-To: <44C2EDDE.1080707@zip.com.au> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> <44C2EDDE.1080707@zip.com.au> Message-ID: <20060723035621.GA25710@orville.25thandClement.com> On Sun, Jul 23, 2006 at 01:32:46PM +1000, Darren Tucker wrote: > William Ahern wrote: > > On Sun, Jul 23, 2006 at 10:16:12AM +1000, Darren Tucker wrote: > >> Going back to the first part: while requiring both password and > >> public-key would probably improve security, personally I think the > >> private key is another instance of "something you know" (although with > >> the useful property of being able to prove you know it without > >> disclosing it) since it can be copied, printed out, emailed... > > > > Excluding public keys exported from a smart card. For real smart cards (i.e. > > not USB memory sticks w/ a PKCS#11 library), the private key is not known > > even by the user holding the card (unless you work at IBM and own an > > electron scanning microscope). > > That's true, and I should have mentioned it. My statement above applies > only to the standard file-based public-key authentication (ie > ~/.ssh/id_rsa and friends). > Personally, I don't like passwords, nor do I care much about "two-factor" authentication (PINs aren't a step forward, maybe a fingerprint scanner on the key fob itself...). What I do care about is removing passwords from the equation entirely. And it's a pain and a half to get OpenSSH working w/ OpenSC, and even more of a pain to actually get OpenSC to work! WRT to OpenSC, I've never seen so much code and so much labour amount to so little (that's not to slight OpenSC developers, but it does speak to the abysmal state of the smart card market; it's so close but so useless it's maddening). OpenSSH actually shipping w/ workable smart card configurations would, I think, have a similar effect on the state of computer security as when OpenSSH killed telnet. It would light a rocket under the whole software ecosystem. I can easily imagine Mozilla/Firefox following (yes, it has PKCS#11 support, but the middleware isn't there), and then the skies the limit. Everything else has already been SSL'ized, so the hard work is done for POP, IMAP, etc. Here at work I've been pushing to move toward smart cards (I have a pack of Schlumberger Cryptoflex's on my desk) for a long time, but I can't sell it to my bosses because the implementation path isn't clear enough (need Windows and Linux and OS X client software). We rely on SSH heavily (multiple implementations), so akward and proprietary RSA Security solutions are out of the question. From Jefferson.Ogata at noaa.gov Sun Jul 23 11:50:20 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 23 Jul 2006 01:50:20 +0000 Subject: two factor authentication In-Reply-To: <5E8F428A0912845573CA331B@manatee.local> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> Message-ID: <44C2D5DC.9050407@noaa.gov> On 2006-07-23 01:27, Frank Cusack wrote: > On July 22, 2006 7:08:59 PM -0500 jacob martinson wrote: >> On 7/22/06, Frank Cusack wrote: >>> On July 22, 2006 12:15:07 PM -0500 jacob martinson wrote: >>>> Are there any plans on the table to add native support for two-factor >>>> authentication, such as password *and* public key? >>> You can already do that. Public key is itself already 2-factor -- >>> something you know (the pin/passcode) and something you have (the >>> device on which the public key resides). Password, via PAM or BSDAUTH, >>> allows any two factor device the host (server) system supports. >>> >> You can? How can you configure ssh to require both successful >> password authentication (via the underlying OS password verification >> mechanisms) and public key auth before the user is allowed onto the >> system? > > Sorry, I meant you can already do native 2-factor auth via publickey > or via password alone. Calling public-key "2-factor" is just spin. 1. You can't force people to put a passphrase on their private key. 2. You can't keep people from storing the key in ssh-agent. 3. If the private key--the actual factor--is compromised, it doesn't matter if someone originally had a passphrase on it. The point of multiple factors is to have a backup in case one of the factors is compromised. Some time back I wrote a patch to allow sshd to require multiple authentication passes to succeed, so, e.g. public key could be combined with s/key to achieve something like two-factor without a smartcard; here the thing you have is the piece of paper with the one-time passwords written on it, and if it falls out of your pocket at the convenience store, it presents no threat by itself because there's a keypair somewhere that's also needed; conversely if your keypair is compromised that doesn't give the intruder access to your pocket. There are other patches out there that are better than my little hack. I would look into that. > You are correct, for files on disk. But publickey can also be used > with smartcards and via control of authorized_keys or using X.509 > (there's a patch for that) you can restrict to keys known to be > protected by a pin/passphrase. How? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From alon.barlev at gmail.com Sun Jul 23 14:56:06 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 23 Jul 2006 07:56:06 +0300 Subject: two factor authentication In-Reply-To: <20060723035621.GA25710@orville.25thandClement.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> <44C2EDDE.1080707@zip.com.au> <20060723035621.GA25710@orville.25thandClement.com> Message-ID: <44C30166.5000609@gmail.com> William Ahern wrote: > OpenSSH actually shipping w/ workable smart card configurations would, I > think, have a similar effect on the state of computer security as when > OpenSSH killed telnet. It would light a rocket under the whole software > ecosystem. I can easily imagine Mozilla/Firefox following (yes, it has > PKCS#11 support, but the middleware isn't there), and then the skies the > limit. Everything else has already been SSL'ized, so the hard work is done > for POP, IMAP, etc. > > Here at work I've been pushing to move toward smart cards (I have a pack of > Schlumberger Cryptoflex's on my desk) for a long time, but I can't sell it > to my bosses because the implementation path isn't clear enough (need > Windows and Linux and OS X client software). We rely on SSH heavily > (multiple implementations), so akward and proprietary RSA Security solutions > are out of the question. Hello, I do not understand the exact problem you have. Why won't you use smartcards? I've written a PKCS#11 patch for OpenSSH, it works for Unix AND Windows. So you can use almost any PKCS#11 complaint token. http://alon.barlev.googlepages.com/openssh-pkcs11 You can use OpenSC PKCS#11 provider, but you may choose other implementations as well, such as Athena, Aladdin, Siemens. What do you call akward proprietary RSA Security solution? I hope not for PKCS#11. Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Sun Jul 23 15:03:13 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 23 Jul 2006 08:03:13 +0300 Subject: two factor authentication In-Reply-To: <44C2D5DC.9050407@noaa.gov> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> Message-ID: <44C30311.3080606@gmail.com> Jefferson Ogata wrote: > Calling public-key "2-factor" is just spin. That's not true! Calling a password "security" is the same. > 1. You can't force people to put a passphrase on their private key. You cannot force users to not using scripts with hard coded password. > 2. You can't keep people from storing the key in ssh-agent. You cannot force user storing passwords in ssh-agent (Yes, ssh-agent, will be also patched to allow that, if your solution will be implemented). > 3. If the private key--the actual factor--is compromised, it doesn't > matter if someone originally had a passphrase on it. If someone bothers to get the private key AND password protects it, he will also bother to get the user password as well. > The point of multiple factors is to have a backup in case one of the > factors is compromised. No it doesn't. This is your interpretation. Two factors, when combined, giving you access to resources. If you want to have real security, use smartcards. If you don't use smartcards, then you don't have real security. Best Regards, Alon Bar-Lev. From Jefferson.Ogata at noaa.gov Sun Jul 23 16:50:35 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 23 Jul 2006 06:50:35 +0000 Subject: two factor authentication In-Reply-To: <44C30311.3080606@gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> <44C30311.3080606@gmail.com> Message-ID: <44C31C3B.5020803@noaa.gov> On 2006-07-23 05:03, Alon Bar-Lev wrote: > Jefferson Ogata wrote: >> Calling public-key "2-factor" is just spin. > > That's not true! > Calling a password "security" is the same. When did I call a password "security"? It's a factor. But the passwords I talked about in the part of my email that you elided are one-time passwords, not fixed reusable passwords. This provides a different kind of factor because it is not something the user knows; the user has to refer to a password list or token to find out what the password is. >> 1. You can't force people to put a passphrase on their private key. > > You cannot force users to not using scripts with hard coded > password. The motivations are opposite. Lazy users will generate private keys with no passphrase. Lazy users will not figure out how to write a script to pass the passphrase to ssh, and really, why would they, when they have ssh-agent available? >> 2. You can't keep people from storing the key in ssh-agent. > > You cannot force user storing passwords in ssh-agent (Yes, > ssh-agent, will be also patched to allow that, if your solution > will be implemented). Again with the passwords. ssh-agent has no capability for storing s/key-style one-time passwords, which are the only passwords I said anything about. And speaking more generally, ssh-agent cannot be patched to handle arbitrary one-time password schemes. And again, even with fixed passwords, your typical lazy user is not going to figure out how to patch ssh-agent, which--remember--is running on /his/ system, not yours. >> 3. If the private key--the actual factor--is compromised, it doesn't >> matter if someone originally had a passphrase on it. > > If someone bothers to get the private key AND password protects it, > he will also bother to get the user password as well. Not if it's a one-time password that the user doesn't even know until he reads it from a piece of paper in his wallet. Did you even read the email that you responded to? >> The point of multiple factors is to have a backup in case one of the >> factors is compromised. > > No it doesn't. This is your interpretation. > Two factors, when combined, giving you access to resources. Yes, and the point of that is to have a backup in case one of the factors is compromised. Or did you just think two factors is more fun for everyone? > If you want to have real security, use smartcards. > If you don't use smartcards, then you don't have real security. Actually, if you use smartcards, you have an unknown level of security, since you're at the mercy of the smartcard vendor. I have nothing against smartcards, but they're not free, and they don't necessarily provide the security they claim to. For all I know, any given smartcard has an RFID backdoor. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From fcusack at fcusack.com Sun Jul 23 17:27:46 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 23 Jul 2006 00:27:46 -0700 Subject: two factor authentication In-Reply-To: <20060723035621.GA25710@orville.25thandClement.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> <44C2EDDE.1080707@zip.com.au> <20060723035621.GA25710@orville.25thandClement.com> Message-ID: <20A6B8AB6ED8B09F3FC4F279@manatee.local> On July 22, 2006 8:56:21 PM -0700 William Ahern wrote: > Personally, I don't like passwords, nor do I care much about "two-factor" > authentication (PINs aren't a step forward, maybe a fingerprint scanner on > the key fob itself...). Sorry to be a bore, but www.tri-dsystems.com does exactly that. -frank From fcusack at fcusack.com Sun Jul 23 17:34:10 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 23 Jul 2006 00:34:10 -0700 Subject: two factor authentication In-Reply-To: <44C2D5DC.9050407@noaa.gov> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> Message-ID: <9BF2A6D8A971BC3BEA774DBA@manatee.local> On July 23, 2006 1:50:20 AM +0000 Jefferson Ogata wrote: > On 2006-07-23 01:27, Frank Cusack wrote: >> On July 22, 2006 7:08:59 PM -0500 jacob martinson wrote: >>> On 7/22/06, Frank Cusack wrote: >>>> On July 22, 2006 12:15:07 PM -0500 jacob martinson wrote: >>>>> Are there any plans on the table to add native support for two-factor >>>>> authentication, such as password *and* public key? >>>> You can already do that. Public key is itself already 2-factor -- >>>> something you know (the pin/passcode) and something you have (the >>>> device on which the public key resides). Password, via PAM or BSDAUTH, >>>> allows any two factor device the host (server) system supports. >>>> >>> You can? How can you configure ssh to require both successful >>> password authentication (via the underlying OS password verification >>> mechanisms) and public key auth before the user is allowed onto the >>> system? >> >> Sorry, I meant you can already do native 2-factor auth via publickey >> or via password alone. > > Calling public-key "2-factor" is just spin. Not at all. > 1. You can't force people to put a passphrase on their private key. > > 2. You can't keep people from storing the key in ssh-agent. > > 3. If the private key--the actual factor--is compromised, it doesn't > matter if someone originally had a passphrase on it. None of those are correct in the case of smartcards, and ssh publickey auth is agnostic as to whether the publickey auth came from a smartcard or an on-disk (essentially single-factor) key. > Some time back I wrote a patch to allow sshd to require multiple > authentication passes to succeed, so, e.g. public key could be combined > with s/key to achieve something like two-factor without a smartcard; > here the thing you have is the piece of paper with the one-time > passwords written on it, and if it falls out of your pocket at the > convenience store, it presents no threat by itself because there's a > keypair somewhere that's also needed; conversely if your keypair is > compromised that doesn't give the intruder access to your pocket. Unless you let the user generate the S/Key seed, in which case it will probably be weak. Even when it is strong, this is generally considered incovenient by users compared to a hardware token alone. >> You are correct, for files on disk. But publickey can also be used >> with smartcards and via control of authorized_keys or using X.509 >> (there's a patch for that) you can restrict to keys known to be >> protected by a pin/passphrase. > > How? With controlled authorized_keys (equivalently with X.509) you only allow keys that are on a smartcard. -frank From fcusack at fcusack.com Sun Jul 23 17:40:43 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 23 Jul 2006 00:40:43 -0700 Subject: two factor authentication In-Reply-To: <44C30311.3080606@gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> <44C30311.3080606@gmail.com> Message-ID: I won't respond to the bulk of this mostly knee-jerk response, but ... On July 23, 2006 8:03:13 AM +0300 Alon Bar-Lev wrote: > Jefferson Ogata wrote: >> The point of multiple factors is to have a backup in case one of the >> factors is compromised. > > No it doesn't. This is your interpretation. umm, no, that IS the point of multiple factors. > Two factors, when combined, giving you access to resources. > > If you want to have real security, use smartcards. > If you don't use smartcards, then you don't have real security. If you do use smartcards, you don't necessarily have real security. It depends on the environment. I talked to a high-security (NSA+) guy recently, smartcards weren't nearly secure enough for them. They are developing their own proprietary technology. In the right environment, publickey from a usb fob is "real" security. In the more general case, smartcards are probably secure. But smartcards could either be overkill or not enough. -frank From william at 25thandClement.com Sun Jul 23 17:43:45 2006 From: william at 25thandClement.com (William Ahern) Date: Sun, 23 Jul 2006 00:43:45 -0700 Subject: two factor authentication In-Reply-To: <44C30166.5000609@gmail.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> <44C2EDDE.1080707@zip.com.au> <20060723035621.GA25710@orville.25thandClement.com> <44C30166.5000609@gmail.com> Message-ID: <20060723074345.GA4814@orville.25thandClement.com> On Sun, Jul 23, 2006 at 07:56:06AM +0300, Alon Bar-Lev wrote: > Hello, > > I do not understand the exact problem you have. Well, the immediate problem is getting OpenSC to intialize the card. Actually, a peer and I have gotten that far, _but_ we could not assert that OpenSC was actually using the hardware for crypto operations, or simply using a generated private key stored in the cards shared memory. It actually appeared like the latter, but after several hours (well, days, really) spent we had to give it up. > Why won't you use smartcards? Because I can't tell whether things are working properly, and unfortuantely I don't have any more time at the moment. My point is that trying to use smart cards today is like trying to use SSH before OpenSSH, a PITA. > I've written a PKCS#11 patch for OpenSSH, it works for Unix AND Windows. > So you can use almost any PKCS#11 complaint token. > > http://alon.barlev.googlepages.com/openssh-pkcs11 > > You can use OpenSC PKCS#11 provider, but you may choose other implementations > as well, such as Athena, Aladdin, Siemens. For Windows, yes. But for Linux I'm stuck w/ OpenSC. > What do you call akward proprietary RSA Security solution? I hope not for PKCS#11. > A popular solution that RSA Security sells is a key fob w/ a clock and a pseudo-random stream generated from a shared key pair (unknown proprietary algorithm) called SecurID. To authenticate, your password is the most recent output from the psuedo-random stream, which churns at a specific rate. Of course, these require software support that is not available on free software. I didn't describe it very well. Here's the URL: http://www.rsasecurity.com/node.asp?id=1156 From fcusack at fcusack.com Sun Jul 23 17:45:20 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 23 Jul 2006 00:45:20 -0700 Subject: two factor authentication In-Reply-To: <44C31C3B.5020803@noaa.gov> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> <44C30311.3080606@gmail.com> <44C31C3B.5020803@noaa.gov> Message-ID: <91429BA62CE3A8CA198D1F8B@manatee.local> On July 23, 2006 6:50:35 AM +0000 Jefferson Ogata wrote: > Actually, if you use smartcards, you have an unknown level of security, > since you're at the mercy of the smartcard vendor. I have nothing > against smartcards, but they're not free, and they don't necessarily > provide the security they claim to. For all I know, any given smartcard > has an RFID backdoor. Well geez, in that case you can never be secure, ever. Your Lenovo laptop could have a backdoor. -frank From Jefferson.Ogata at noaa.gov Sun Jul 23 18:41:49 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 23 Jul 2006 08:41:49 +0000 Subject: two factor authentication In-Reply-To: <91429BA62CE3A8CA198D1F8B@manatee.local> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> <44C30311.3080606@gmail.com> <44C31C3B.5020803@noaa.gov> <91429BA62CE3A8CA198D1F8B@manatee.local> Message-ID: <44C3364D.8060301@noaa.gov> On 2006-07-23 07:45, Frank Cusack wrote: > On July 23, 2006 6:50:35 AM +0000 Jefferson Ogata wrote: >> Actually, if you use smartcards, you have an unknown level of security, >> since you're at the mercy of the smartcard vendor. I have nothing >> against smartcards, but they're not free, and they don't necessarily >> provide the security they claim to. For all I know, any given smartcard >> has an RFID backdoor. > > Well geez, in that case you can never be secure, ever. Your Lenovo > laptop could have a backdoor. Indeed it could. But there are many CPUs I might plug my smartcard into, but only one smartcard with my private key. What's more reliable: attacking the CPU or attacking the smartcard? No piece of hardware magically instills perfect security in everything it touches. The only security we can know about with any degree of confidence is that which comes from analyzing algorithms. Placing blind faith in smartcards as the be-all, end-all of authentication strategies is unwise, especially if you've convinced yourself that you don't need any other authentication factor except those nifty smartcards you just bought 10,000 of from a single vendor. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From Jefferson.Ogata at noaa.gov Sun Jul 23 18:57:21 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 23 Jul 2006 08:57:21 +0000 Subject: two factor authentication In-Reply-To: <9BF2A6D8A971BC3BEA774DBA@manatee.local> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <5b7479590607221708s477bc1d6p7357fbed43b8ec12@mail.gmail.com> <5E8F428A0912845573CA331B@manatee.local> <44C2D5DC.9050407@noaa.gov> <9BF2A6D8A971BC3BEA774DBA@manatee.local> Message-ID: <44C339F1.3090407@noaa.gov> On 2006-07-23 07:34, Frank Cusack wrote: > On July 23, 2006 1:50:20 AM +0000 Jefferson Ogata > wrote: >> On 2006-07-23 01:27, Frank Cusack wrote: >>> On July 22, 2006 7:08:59 PM -0500 jacob martinson >>> wrote: >>>> On 7/22/06, Frank Cusack wrote: >>>>> On July 22, 2006 12:15:07 PM -0500 jacob martinson >>>>> wrote: >>>>>> Are there any plans on the table to add native support for two-factor >>>>>> authentication, such as password *and* public key? >>>>> You can already do that. Public key is itself already 2-factor -- >>>>> something you know (the pin/passcode) and something you have (the >>>>> device on which the public key resides). Password, via PAM or >>>>> BSDAUTH, >>>>> allows any two factor device the host (server) system supports. >>>>> >>>> You can? How can you configure ssh to require both successful >>>> password authentication (via the underlying OS password verification >>>> mechanisms) and public key auth before the user is allowed onto the >>>> system? >>> >>> Sorry, I meant you can already do native 2-factor auth via publickey >>> or via password alone. >> >> Calling public-key "2-factor" is just spin. > > Not at all. > >> 1. You can't force people to put a passphrase on their private key. >> >> 2. You can't keep people from storing the key in ssh-agent. >> >> 3. If the private key--the actual factor--is compromised, it doesn't >> matter if someone originally had a passphrase on it. > > None of those are correct in the case of smartcards, and ssh publickey > auth is agnostic as to whether the publickey auth came from a smartcard > or an on-disk (essentially single-factor) key. Your original statement was that "public key is itself already 2-factor", which is generally untrue. The secret is the private key. Compromise of the factor is compromise of the private key, plain and simple. Public key using a smartcard with a passphrase, which is what you've changed the topic to, is a much more specific (and expensive) strategy, and I might grant that it technically involves two factors (though they really are entangled), since the private key resides, by nature, on separate media from the rest of the system, unlike public key auth in general. But you appear to be playing word games with respect to two-factor authentication. A management entity that says, "you must use two-factor auth" won't be charmed by your fancy footwork--if you convince them that public keys with smartcards is two-factor auth, they'll say, "fine, then you have to do three-factor auth". The real question that it would be nice to see answered is how to get sshd to do n-factor authentication, rather than quibbling over how many factors are involved in some particular authentication strategy. This would be addressing the spirit of the original question, not trying to use semantics to get out of solving the problem. >> Some time back I wrote a patch to allow sshd to require multiple >> authentication passes to succeed, so, e.g. public key could be combined >> with s/key to achieve something like two-factor without a smartcard; >> here the thing you have is the piece of paper with the one-time >> passwords written on it, and if it falls out of your pocket at the >> convenience store, it presents no threat by itself because there's a >> keypair somewhere that's also needed; conversely if your keypair is >> compromised that doesn't give the intruder access to your pocket. > > Unless you let the user generate the S/Key seed, in which case it will > probably be weak. It may--so what? The intruder doesn't automatically know what it is. S/key is simply a convenient example because it is free and openssh already supports it; someone is free to implement an OTP system that relies on a list of random, unrelated, single-use passwords. The specific implementation is irrelevant--the point is that OTP is a distinct factor from publickey, by nature. > Even when it is strong, this is generally considered incovenient by users compared to a hardware token alone. Yes, some people believe more security often means less convenience. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From alon.barlev at gmail.com Mon Jul 24 02:27:15 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 23 Jul 2006 19:27:15 +0300 Subject: two factor authentication In-Reply-To: <20060723074345.GA4814@orville.25thandClement.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> <44C2EDDE.1080707@zip.com.au> <20060723035621.GA25710@orville.25thandClement.com> <44C30166.5000609@gmail.com> <20060723074345.GA4814@orville.25thandClement.com> Message-ID: <44C3A363.9030408@gmail.com> William Ahern wrote: >> You can use OpenSC PKCS#11 provider, but you may choose other implementations >> as well, such as Athena, Aladdin, Siemens. > > For Windows, yes. But for Linux I'm stuck w/ OpenSC. > Not at all, I've just gave four examples for *WORKING* solutions: 1. OpenSC. 2. Athena. 3. Aladdin. 4. Siemens. You can choose the right one for you. Athena and Aladdin works well with the same media content in Windows *AND* Linux. >> What do you call akward proprietary RSA Security solution? I hope not for PKCS#11. >> > > A popular solution that RSA Security sells is a key fob w/ a clock and a > pseudo-random stream generated from a shared key pair (unknown proprietary > algorithm) called SecurID. To authenticate, your password is the most recent I hoped you referred this product... I don't like it. I don't find it usable and it way too expensive. Moreover it has no real advantage over regular smartcard. Best Regards, Alon Bar-Lev. From mh+openssh-unix-dev at zugschlus.de Mon Jul 24 19:52:58 2006 From: mh+openssh-unix-dev at zugschlus.de (Marc Haber) Date: Mon, 24 Jul 2006 11:52:58 +0200 Subject: [Feature Suggestion] ~/.ssh/config pre-connect hook Message-ID: <20060724095258.GD2686@torres.l21.ma.zugschlus.de> Hi, in port knocking setups, it would be great to have the possibility to execute a shell command before the ssh connection is actually initiated. That way, one could configure ssh like host foo hostname foo.bar.example user baz pre-connect knock foo.bar.example 1234 5678 and transparently initiate the connection by saying ssh foo. ssh would then first invoke the knock process and then initiate the actual ssh connection. This can currently be implemented by using something along the lines of proxycommand sh -c 'knock ; sleep 1; exec socket %h %p' but I find this ugly and unintuitive. Please consider implementing the more straight-forward direct approach. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 From deengert at anl.gov Tue Jul 25 00:04:33 2006 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 24 Jul 2006 09:04:33 -0500 Subject: two factor authentication In-Reply-To: <20060723074345.GA4814@orville.25thandClement.com> References: <5b7479590607221015g7d54a14q19c60ef19c3ec9b@mail.gmail.com> <44C2BFCC.5090904@zip.com.au> <20060723032728.GA13075@orville.25thandClement.com> <44C2EDDE.1080707@zip.com.au> <20060723035621.GA25710@orville.25thandClement.com> <44C30166.5000609@gmail.com> <20060723074345.GA4814@orville.25thandClement.com> Message-ID: <44C4D371.3090606@anl.gov> William Ahern wrote: > On Sun, Jul 23, 2006 at 07:56:06AM +0300, Alon Bar-Lev wrote: > >>Hello, >> >>I do not understand the exact problem you have. > > > Well, the immediate problem is getting OpenSC to intialize the card. > Actually, a peer and I have gotten that far, _but_ we could not assert that > OpenSC was actually using the hardware for crypto operations, or simply > using a generated private key stored in the cards shared memory. To verify if the crypto is being done on the card, if you are using the pcscd you could use its debug capabilities to watch the traffic between the OpenSC applicaiton and pcscd. You could also use a USB debugger to watch the traffic to the card reader. If the crypto is being done on the card, you should see the ADPUs with the crypto operations. You may want to post a question about your specific card on the OpenSC mail list too. Depeinding on the card, it may or may not have a random number generator, but should have at least RSA to use the private key on the card and the ability to keep the private key on the card. If it does not, time to get a different card. > It actually > appeared like the latter, but after several hours (well, days, really) spent > we had to give it up. > > >>Why won't you use smartcards? > > > Because I can't tell whether things are working properly, and unfortuantely > I don't have any more time at the moment. My point is that trying to use > smart cards today is like trying to use SSH before OpenSSH, a PITA. > Agree! > >>I've written a PKCS#11 patch for OpenSSH, it works for Unix AND Windows. >>So you can use almost any PKCS#11 complaint token. >> >>http://alon.barlev.googlepages.com/openssh-pkcs11 >> >>You can use OpenSC PKCS#11 provider, but you may choose other implementations >>as well, such as Athena, Aladdin, Siemens. > > > For Windows, yes. But for Linux I'm stuck w/ OpenSC. > > >>What do you call akward proprietary RSA Security solution? I hope not for PKCS#11. >> > > > A popular solution that RSA Security sells is a key fob w/ a clock and a > pseudo-random stream generated from a shared key pair (unknown proprietary > algorithm) called SecurID. To authenticate, your password is the most recent > output from the psuedo-random stream, which churns at a specific rate. Of > course, these require software support that is not available on free > software. I didn't describe it very well. Here's the URL: > > http://www.rsasecurity.com/node.asp?id=1156 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From fcusack at fcusack.com Tue Jul 25 06:38:02 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 24 Jul 2006 13:38:02 -0700 Subject: two factor authentication Message-ID: <450DD3FC22F51F95172A9AD0@manatee.local> On July 23, 2006 8:57:21 AM +0000 Jefferson Ogata wrote: > On 2006-07-23 07:34, Frank Cusack wrote: >> On July 23, 2006 1:50:20 AM +0000 Jefferson Ogata >> wrote: >>> On 2006-07-23 01:27, Frank Cusack wrote: >>>> On July 22, 2006 7:08:59 PM -0500 jacob martinson >>>> wrote: >>>>> On 7/22/06, Frank Cusack wrote: >>>>>> On July 22, 2006 12:15:07 PM -0500 jacob martinson >>>>>> wrote: >>>>>>> Are there any plans on the table to add native support for two-factor >>>>>>> authentication, such as password *and* public key? >>>>>> You can already do that. Public key is itself already 2-factor -- >>>>>> something you know (the pin/passcode) and something you have (the >>>>>> device on which the public key resides). Password, via PAM or >>>>>> BSDAUTH, >>>>>> allows any two factor device the host (server) system supports. >>>>>> >>>>> You can? How can you configure ssh to require both successful >>>>> password authentication (via the underlying OS password verification >>>>> mechanisms) and public key auth before the user is allowed onto the >>>>> system? >>>> >>>> Sorry, I meant you can already do native 2-factor auth via publickey >>>> or via password alone. >>> >>> Calling public-key "2-factor" is just spin. >> >> Not at all. >> >>> 1. You can't force people to put a passphrase on their private key. >>> >>> 2. You can't keep people from storing the key in ssh-agent. >>> >>> 3. If the private key--the actual factor--is compromised, it doesn't >>> matter if someone originally had a passphrase on it. >> >> None of those are correct in the case of smartcards, and ssh publickey >> auth is agnostic as to whether the publickey auth came from a smartcard >> or an on-disk (essentially single-factor) key. > > Your original statement was that "public key is itself already > 2-factor", which is generally untrue. The secret is the private key. > Compromise of the factor is compromise of the private key, plain and simple. True, my original statement was misleading/incorrect. > Public key using a smartcard with a passphrase, which is what you've > changed the topic to, is a much more specific (and expensive) strategy, > and I might grant that it technically involves two factors (though they > really are entangled), since the private key resides, by nature, on > separate media from the rest of the system, unlike public key auth in > general. > > But you appear to be playing word games with respect to two-factor > authentication. A management entity that says, "you must use two-factor > auth" won't be charmed by your fancy footwork--if you convince them that > public keys with smartcards is two-factor auth, they'll say, "fine, then > you have to do three-factor auth". Don't make me laugh. A "management entity" is likely only to be concerned about 2-factor auth because of input from internal IT (and then just as likely to be ignored as not) or from a 3rd-party audit, not because of experience with what 2-factor means and what it achieves. I do disagree with you on whether or not a smartcard is 2 factor ... ok techically yes, if you can get the key out of it, then the other factor is just shine, but at what cost? For the typical threat that has to be protected against, a smartcard is sufficiently 2-factor. > The real question that it would be nice to see answered is how to get > sshd to do n-factor authentication, rather than quibbling over how many > factors are involved in some particular authentication strategy. This > would be addressing the spirit of the original question, not trying to > use semantics to get out of solving the problem. I answered that twice: PAM/BSDAUTH with the correct backends, or publickey with smartcards. And to repeat myself, in the case where you can't change sshd (say sshd on a router) then as long as you can do RADIUS you can generally get multifactor auth via OTP tokens. I'm quite surprised that you would misread the smartcard part of my answer as trying to wrangle out of the question. It seems quite obvious how to have sshd do n-factor authentication in the way the OP suggested: modify the code to require this. I believe there are already patches out there to do just that. I suggested ways to do this without requiring changes to sshd. >>> Some time back I wrote a patch to allow sshd to require multiple >>> authentication passes to succeed, so, e.g. public key could be combined >>> with s/key to achieve something like two-factor without a smartcard; >>> here the thing you have is the piece of paper with the one-time >>> passwords written on it, and if it falls out of your pocket at the >>> convenience store, it presents no threat by itself because there's a >>> keypair somewhere that's also needed; conversely if your keypair is >>> compromised that doesn't give the intruder access to your pocket. >> >> Unless you let the user generate the S/Key seed, in which case it will >> probably be weak. > > It may--so what? The intruder doesn't automatically know what it is. The intruder can easily determine it from observation. > S/key is simply a convenient example because it is free and openssh > already supports it; someone is free to implement an OTP system that > relies on a list of random, unrelated, single-use passwords. The > specific implementation is irrelevant--the point is that OTP is a > distinct factor from publickey, by nature. > >> Even when it is strong, this is generally considered incovenient by users compared to a >> hardware token alone. > > Yes, some people believe more security often means less convenience. Well, it often does. -frank From Jefferson.Ogata at noaa.gov Tue Jul 25 06:57:32 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 24 Jul 2006 20:57:32 +0000 Subject: two factor authentication In-Reply-To: <450DD3FC22F51F95172A9AD0@manatee.local> References: <450DD3FC22F51F95172A9AD0@manatee.local> Message-ID: <44C5343C.5080607@noaa.gov> On 2006-07-24 20:38, Frank Cusack wrote: > On July 23, 2006 8:57:21 AM +0000 Jefferson Ogata wrote: >> But you appear to be playing word games with respect to two-factor >> authentication. A management entity that says, "you must use two-factor >> auth" won't be charmed by your fancy footwork--if you convince them that >> public keys with smartcards is two-factor auth, they'll say, "fine, then >> you have to do three-factor auth". > > Don't make me laugh. A "management entity" is likely only to be concerned > about 2-factor auth because of input from internal IT (and then just as > likely to be ignored as not) or from a 3rd-party audit, not because of > experience with what 2-factor means and what it achieves. Well, I'm guessing you haven't read this: http://www.whitehouse.gov/omb/memoranda/fy2006/m06-16.pdf "... recommending all departments and agencies take the following actions: ... Allow remote access only with two-factor authentication where one of the factors is provided by a device separate from the computer gaining access." For the US federal government in general, which has to implement these recommendations, this is clearly not the result of input from "internal IT". It's a decree from the White House--the supreme US government management entity--largely in reaction to the VA laptop debacle. > I do disagree with you on whether or not a smartcard is 2 factor ... ok > techically yes, if you can get the key out of it, then the other factor > is just shine, but at what cost? For the typical threat that has to be > protected against, a smartcard is sufficiently 2-factor. Well, I was actually provisionally agreeing with you that with a smartcard from which the key is not directly accessible, yes you may arguably have two factors. But I don't think the White House will consider it so. >> The real question that it would be nice to see answered is how to get >> sshd to do n-factor authentication, rather than quibbling over how many >> factors are involved in some particular authentication strategy. This >> would be addressing the spirit of the original question, not trying to >> use semantics to get out of solving the problem. > > I answered that twice: PAM/BSDAUTH with the correct backends, or publickey > with smartcards. And to repeat myself, in the case where you can't change > sshd (say sshd on a router) then as long as you can do RADIUS you can > generally get multifactor auth via OTP tokens. I'm quite surprised that > you would misread the smartcard part of my answer as trying to wrangle out > of the question. I read it that way because instead of saying, "no, there's nothing native in sshd but there are ways to force sshd to pass authentication to other modules which may do multiple factors," you asserted that pubkey was already 2-factor. > It seems quite obvious how to have sshd do n-factor authentication in the > way the OP suggested: modify the code to require this. I believe there > are already patches out there to do just that. I suggested ways to do > this without requiring changes to sshd. And the patches were what I was drawing attention to. But since sshd is largely about strong authentication, it would be nice to see it natively support per-user configuration of multiple required authentication methods. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dtucker at zip.com.au Tue Jul 25 08:35:58 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 Jul 2006 08:35:58 +1000 Subject: two factor authentication In-Reply-To: <44C5343C.5080607@noaa.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> Message-ID: <44C54B4E.2080206@zip.com.au> Jefferson Ogata wrote: > And the patches were what I was drawing attention to. But since sshd is > largely about strong authentication, it would be nice to see it natively > support per-user configuration of multiple required authentication methods. The "per-user" part has just been added to sshd and will be in the next major release: the "Match" keyword allows you conditionally override some settings on a per {user,host,network} basis. It doesn't allow control of authentication types (yet), though. eg: AllowTcpForwarding yes Match User anoncvs AllowTcpForwarding no -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From fcusack at fcusack.com Tue Jul 25 10:55:37 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 24 Jul 2006 17:55:37 -0700 Subject: two factor authentication In-Reply-To: <44C5343C.5080607@noaa.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> Message-ID: <2CFD0D79BA8C3249A440466D@manatee.local> On July 24, 2006 8:57:32 PM +0000 Jefferson Ogata wrote: > And the patches were what I was drawing attention to. But since sshd is > largely about strong authentication, it would be nice to see it natively > support per-user configuration of multiple required authentication methods. I definitely agree with that! From David.Leonard at quest.com Tue Jul 25 11:44:29 2006 From: David.Leonard at quest.com (David Leonard) Date: Tue, 25 Jul 2006 11:44:29 +1000 Subject: two factor authentication In-Reply-To: <2CFD0D79BA8C3249A440466D@manatee.local> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <2CFD0D79BA8C3249A440466D@manatee.local> Message-ID: <44C5777D.3080008@quest.com> Frank Cusack wrote: > On July 24, 2006 8:57:32 PM +0000 Jefferson Ogata wrote: > >> And the patches were what I was drawing attention to. But since sshd is >> largely about strong authentication, it would be nice to see it natively >> support per-user configuration of multiple required authentication methods. >> > > I definitely agree with that! > I'm all for multiple-auth in sshd, but the current impl appears to conflict with an obscure feature of RFC4462 that I have been trying to implement, namely where the username field can start off blank and the server deduces the username from the credentials. Has anyone else looked at this? sshd currently rejects connections when the username field changes between separate auth attempts. d From alon.barlev at gmail.com Tue Jul 25 15:17:06 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 25 Jul 2006 08:17:06 +0300 Subject: two factor authentication In-Reply-To: <44C5343C.5080607@noaa.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> Message-ID: <44C5A952.1040302@gmail.com> Jefferson Ogata wrote: > Well, I was actually provisionally agreeing with you that with a > smartcard from which the key is not directly accessible, yes you may > arguably have two factors. But I don't think the White House will > consider it so. Why do you guess? Ask them! Smartcard *IS* two factor, this is why they exist. There is no better security solution than smartcards. You can, how-ever, wish your users to enter the password for the smartcard and then enter the password for the server. But I really pity your users. If you don't trust your users you can provide them with a smartcard with a pre-defined complex-enough password, they cannot change. The result is smartcard being locked if someone try to guess that password. You can also consider biometric enabled smartcards, and have 3 factors. But biometric is the worse from user perspective. Best Regards, Alon Bar-Lev. From Jefferson.Ogata at noaa.gov Tue Jul 25 15:55:53 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 25 Jul 2006 05:55:53 +0000 Subject: two factor authentication In-Reply-To: <44C5A952.1040302@gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> Message-ID: <44C5B269.6010102@noaa.gov> On 2006-07-25 05:17, Alon Bar-Lev wrote: > Smartcard *IS* two factor, this is why they exist. There is no > better security solution than smartcards. It's just rude to keep touting the same nonsense without even bothering to read or understand what the other person has written. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From deengert at anl.gov Wed Jul 26 00:27:27 2006 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 25 Jul 2006 09:27:27 -0500 Subject: two factor authentication In-Reply-To: <44C5777D.3080008@quest.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <2CFD0D79BA8C3249A440466D@manatee.local> <44C5777D.3080008@quest.com> Message-ID: <44C62A4F.1030601@anl.gov> David Leonard wrote: > Frank Cusack wrote: > >>On July 24, 2006 8:57:32 PM +0000 Jefferson Ogata wrote: >> >> >>>And the patches were what I was drawing attention to. But since sshd is >>>largely about strong authentication, it would be nice to see it natively >>>support per-user configuration of multiple required authentication methods. >>> >> >>I definitely agree with that! >> > > > I'm all for multiple-auth in sshd, but the current impl appears to > conflict with an obscure feature of RFC4462 that I have been trying to > implement, namely where the username field can start off blank and the > server deduces the username from the credentials. I would not quite call it obscure, but an important feature that ssh needs to support. The user may have credentials, such as Kerbero tickets or Globus proxy certificates, both using GSSAPI, and wants to connect to some machine using these "network" credentials. The machine should be able to determine what local unix account to use in this case if no specific user name is provided. In some cases a different temporary unix account might be assigned for each session. ssh should not require the user to supply the local unix account to use in these situations when other credentials can be used to determine the local account. OpenSSH in the past has checked the pam_user to make sure it was not changed by the pam routines, rather the accepting that pam routines have decided to use a different user name then the one supplied by the user which goes against this concept of determining the user from the network credentials. > Has anyone else looked > at this? sshd currently rejects connections when the username field > changes between separate auth attempts. > > d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rapier at psc.edu Wed Jul 26 01:12:21 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 25 Jul 2006 11:12:21 -0400 Subject: two factor authentication In-Reply-To: <44C5A952.1040302@gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> Message-ID: <44C634D5.9000004@psc.edu> Alon Bar-Lev wrote: > Smartcard *IS* two factor, this is why they exist. There is no > better security solution than smartcards. Of course, smartcards can be easily defeated by a sufficiently scary person holding a pair of garden shears. ;) From sxw at inf.ed.ac.uk Wed Jul 26 01:34:01 2006 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Tue, 25 Jul 2006 16:34:01 +0100 Subject: two factor authentication In-Reply-To: <44C62A4F.1030601@anl.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <2CFD0D79BA8C3249A440466D@manatee.local> <44C5777D.3080008@quest.com> <44C62A4F.1030601@anl.gov> Message-ID: > > David Leonard wrote: >> I'm all for multiple-auth in sshd, but the current impl appears to >> conflict with an obscure feature of RFC4462 that I have been >> trying to >> implement, namely where the username field can start off blank and >> the >> server deduces the username from the credentials. > David, I've got a partial implementation of this for the GSSAPI patches, which originally came from the GSI-OpenSSH code. Let me know if you're interested, and I can dig it out ... Cheers, Simon. From David.Leonard at quest.com Wed Jul 26 01:16:48 2006 From: David.Leonard at quest.com (David Leonard) Date: Wed, 26 Jul 2006 01:16:48 +1000 Subject: RFC 4462 empty user name string In-Reply-To: <24614.1153838849@localhost> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <2CFD0D79BA8C3249A440466D@manatee.local> <44C5777D.3080008@quest.com> <24614.1153838849@localhost> Message-ID: <44C635E0.3030406@quest.com> Hi, Thanks for that. I looked at the patch in 958, and I guess I will have to stare at it some more (when I am more awake) to understand how it uses empty username strings. I'm mainly confused as to what the behaviour of the /client/ should be. You see I've also got patches against PuTTY, and the approach I made it try for gssapi-with-mic/gss-keyex was - try sending an empty username string first - if that fails, try sending the username provided in config - if that fails, try sending the non-realm elements of the upn :) My plan was that the client should try to discover a way to login to the server by trying older and older standards.. and guesswork. The problem though is that sshd rejects the connection because it sees the client is changing the username, and won't give the client a second chance. The only workaround I can see is that the client re-try the connection after it collapses (but that has its own hairy problems.) Bug 1100 is the one I entered on this topic. I have an implementation (patch), for openssh but it only works without privsep at the moment. Cheers d Jim Basney wrote: > Yes, we find the RFC 4462 empty user name string feature very useful for > the GSI GSSAPI mechanism to ease single sign-on across systems where > usernames differ. For interop, we have to be careful to only send an > empty username if we know the server will accept it. We maintain our > GSI patch for OpenSSH at . I submitted > a version of the patch at > which I'd be happy to > update if there's interest. > > Cheers, > Jim > > David Leonard wrote: > >> I'm all for multiple-auth in sshd, but the current impl appears to >> conflict with an obscure feature of RFC4462 that I have been trying to >> implement, namely where the username field can start off blank and the >> server deduces the username from the credentials. Has anyone else looked >> at this? sshd currently rejects connections when the username field >> changes between separate auth attempts. >> >> d >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > From alon.barlev at gmail.com Wed Jul 26 03:12:21 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 25 Jul 2006 20:12:21 +0300 Subject: two factor authentication In-Reply-To: <44C634D5.9000004@psc.edu> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> Message-ID: <44C650F5.9010100@gmail.com> Chris Rapier wrote: > > > Alon Bar-Lev wrote: > >> Smartcard *IS* two factor, this is why they exist. There is no >> better security solution than smartcards. > > Of course, smartcards can be easily defeated by a sufficiently scary > person holding a pair of garden shears. ;) > Well... I am not a native English speaker... What does it mean? Do you actually think there is a better security mechanism than smartcards? Do you actually think a private key file + password + server password is better than using smartcards? Adding a remote password to the smartcard strengthen the solution? Best Regards, Alon Bar-Lev. From jbasney at ncsa.uiuc.edu Wed Jul 26 00:47:29 2006 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Tue, 25 Jul 2006 09:47:29 -0500 Subject: RFC 4462 empty user name string In-Reply-To: <44C5777D.3080008@quest.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <2CFD0D79BA8C3249A440466D@manatee.local> <44C5777D.3080008@quest.com> Message-ID: <24614.1153838849@localhost> Yes, we find the RFC 4462 empty user name string feature very useful for the GSI GSSAPI mechanism to ease single sign-on across systems where usernames differ. For interop, we have to be careful to only send an empty username if we know the server will accept it. We maintain our GSI patch for OpenSSH at . I submitted a version of the patch at which I'd be happy to update if there's interest. Cheers, Jim David Leonard wrote: > I'm all for multiple-auth in sshd, but the current impl appears to > conflict with an obscure feature of RFC4462 that I have been trying to > implement, namely where the username field can start off blank and the > server deduces the username from the credentials. Has anyone else looked > at this? sshd currently rejects connections when the username field > changes between separate auth attempts. > > d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rapier at psc.edu Wed Jul 26 03:44:55 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 25 Jul 2006 13:44:55 -0400 Subject: two factor authentication In-Reply-To: <44C650F5.9010100@gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> Message-ID: <44C65897.5090800@psc.edu> Alon Bar-Lev wrote: > Chris Rapier wrote: >> >> >> Alon Bar-Lev wrote: >> >>> Smartcard *IS* two factor, this is why they exist. There is no >>> better security solution than smartcards. >> >> Of course, smartcards can be easily defeated by a sufficiently scary >> person holding a pair of garden shears. ;) >> > > Well... I am not a native English speaker... What does it mean? > > Do you actually think there is a better security mechanism than smartcards? The idea is that almost every security solution can be broken if the person trying to break it is sufficiently ruthless. Things like smart-cards, fobs, two factor authentication and so forth are really only effective at one class of security attacks where the technology is targeted. However, the weakest link in any security chain is always the human. If you *physically* attack the human then its very easy to gain access to most any system. The mental I was trying to convey above is someone who wants access to your systems and is willing to cut off your toes and fingers with a pair of garden shears to get in. While some might consider this to be extreme I'm personally surprised its not being doing with some frequency. Now is there a better solution than smartcards? Well, smart cards are a compromise between security and convenience. They provide reasonably good security but its not perfect. In fact, if you think about it ATM cards are two factor security - very much like smartcards - you need the card and the pin to access your money. However, a little ingenuity and you come up with http://www.snopes.com/crime/warnings/atmcamera.asp http://www.crimes-of-persuasion.com/Crimes/InPerson/atm_scams.htm and http://www.engadget.com/2005/03/29/beware-phony-atm-facades/ Anyway, this doesn't have much to do with OpenSSH. My point was really just that most any security protocol can be broken by someone who is determined enough to do it. From jbasney at ncsa.uiuc.edu Wed Jul 26 01:34:36 2006 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Tue, 25 Jul 2006 10:34:36 -0500 Subject: RFC 4462 empty user name string In-Reply-To: <44C635E0.3030406@quest.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <2CFD0D79BA8C3249A440466D@manatee.local> <44C5777D.3080008@quest.com> <24614.1153838849@localhost> <44C635E0.3030406@quest.com> Message-ID: <26635.1153841676@localhost> Sorry, I should have mentioned that the patch in Bug 958 doesn't have the empty user name string mods, as I think that's best addressed as a separate issue (and I'll follow your Bug 1100 with interest). Our empty user name modifications are only in the larger patch at , specifically . Our current approach is to only send an empty username if: - the user didn't specify a username at the client - the server supports the GSI OID for GSSAPI authentication (and thus has our server-side mods) David Leonard wrote: > Hi, > > Thanks for that. I looked at the patch in 958, and I guess I will have > to stare at it some more (when I am more awake) to understand how it > uses empty username strings. > > I'm mainly confused as to what the behaviour of the /client/ should > be. You see I've also got patches against PuTTY, and the approach I > made it try for gssapi-with-mic/gss-keyex was > - try sending an empty username string first > - if that fails, try sending the username provided in config > - if that fails, try sending the non-realm elements of the upn :) > My plan was that the client should try to discover a way to login to > the server by trying older and older standards.. and guesswork. The > problem though is that sshd rejects the connection because it sees the > client is changing the username, and won't give the client a second > chance. The only workaround I can see is that the client re-try the > connection after it collapses (but that has its own hairy problems.) > > Bug 1100 is the one I entered on this topic. I have an implementation > (patch), for openssh but it only works without privsep at the moment. > > Cheers > > d > > Jim Basney wrote: > > Yes, we find the RFC 4462 empty user name string feature very useful for > > the GSI GSSAPI mechanism to ease single sign-on across systems where > > usernames differ. For interop, we have to be careful to only send an > > empty username if we know the server will accept it. We maintain our > > GSI patch for OpenSSH at . I submitted > > a version of the patch at > > which I'd be happy to > > update if there's interest. > > > > Cheers, > > Jim > > > > David Leonard wrote: > > > >> I'm all for multiple-auth in sshd, but the current impl appears to > >> conflict with an obscure feature of RFC4462 that I have been trying to > >> implement, namely where the username field can start off blank and the > >> server deduces the username from the credentials. Has anyone else looked > >> at this? sshd currently rejects connections when the username field > >> changes between separate auth attempts. > >> > >> d > >> _______________________________________________ > >> openssh-unix-dev mailing list > >> openssh-unix-dev at mindrot.org > >> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > > > > > > > From alon.barlev at gmail.com Wed Jul 26 04:01:23 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 25 Jul 2006 21:01:23 +0300 Subject: two factor authentication In-Reply-To: <44C65897.5090800@psc.edu> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> Message-ID: <9e0cf0bf0607251101o647d797bn83db76fc3bbd0e57@mail.gmail.com> On 7/25/06, Chris Rapier wrote: > Alon Bar-Lev wrote: > > Chris Rapier wrote: > >> Alon Bar-Lev wrote: > >> > >>> Smartcard *IS* two factor, this is why they exist. There is no > >>> better security solution than smartcards. > >> > >> Of course, smartcards can be easily defeated by a sufficiently scary > >> person holding a pair of garden shears. ;) > >> > > > > Well... I am not a native English speaker... What does it mean? > > > > Do you actually think there is a better security mechanism than smartcards? > However, the weakest link in any security chain is always the human. If > you *physically* attack the human then its very easy to gain access to > most any system. The mental I was trying to convey above is someone who > wants access to your systems and is willing to cut off your toes and > fingers with a pair of garden shears to get in. While some might > consider this to be extreme I'm personally surprised its not being doing > with some frequency. Oh! Thanks! I thought I am going insane! This is a redundant thread.... And the original poster called be rude... Since I don't agree with him, and requested him to check his requirements with the originate author of the document he introduced. I am totally agree with you. But the human factor is allways there... So I can cancel out it from the equation. Then we left with smartcard as the leading solution, in term of price/usability/security. The one neat feature I've seen in SecureID was the ability for the user to enter an "alert pin" in place of his regular pin so that the system grant the user access, but alert the administrator that the user was forced to do the action... Thank you for keeping me sane, Alon Bar-Lev. From fcusack at fcusack.com Wed Jul 26 06:03:09 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 25 Jul 2006 13:03:09 -0700 Subject: two factor authentication In-Reply-To: <44C5A952.1040302@gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> Message-ID: <875F9D313F622649CE0DB982@manatee.local> On July 25, 2006 8:17:06 AM +0300 Alon Bar-Lev wrote: > You can also consider biometric enabled smartcards, and have 3 factors. > But biometric is the worse from user perspective. Why is that? -frank From william at 25thandClement.com Wed Jul 26 07:06:05 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 25 Jul 2006 14:06:05 -0700 Subject: two factor authentication In-Reply-To: <44C65897.5090800@psc.edu> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> Message-ID: <20060725210605.GA27561@orville.25thandClement.com> On Tue, Jul 25, 2006 at 01:44:55PM -0400, Chris Rapier wrote: > > Now is there a better solution than smartcards? Well, smart cards are a > compromise between security and convenience. They provide reasonably > good security but its not perfect. In fact, if you think about it ATM > cards are two factor security - very much like smartcards - you need the > card and the pin to access your money. However, a little ingenuity and > you come up with > http://www.snopes.com/crime/warnings/atmcamera.asp > http://www.crimes-of-persuasion.com/Crimes/InPerson/atm_scams.htm > and > http://www.engadget.com/2005/03/29/beware-phony-atm-facades/ > > Anyway, this doesn't have much to do with OpenSSH. My point was really > just that most any security protocol can be broken by someone who is > determined enough to do it. ATM cards are not like smart cards wrt to a very critical characteristic, you cannot "copy" a smart card. An ATM card is just a piece of plastic w/ a number on it. You can copy a PIN, but with biometric smart cards, which would require, for instance, a fingerprint scan, you have an extremely strong security device with hard limitations. A smart card can still be exploited (i.e., stealing and chopping off a finger, for instance), but since it can't be copied it's faaaaarrrrrr easier to mitigate the effects of attacks than w/ most any other mechanism in use today. This is why I'd rather have a single-factor smart card than most any other two-factor mechanism. When I lose my smart card--and you know when you've lost it--I can disable my accounts and prepare a new smart card. It's impossible to know whether somebody else has your PIN, your bank account number, your super-secret Unix account password, or for that matter your RSA private key sitting on your harddrive (encrypted or not). Sometimes people make sarcastic comments like, "if you're afraid somebody is going to install a password sniffer or backdoor on your computer then you should keep your computer on your person at all times". Well, a smart card is a computer you keep in your pocket or at your side 24/7, and even more it's a computer that is, in all practicality, impossible to install malware on. From Jefferson.Ogata at noaa.gov Wed Jul 26 07:14:42 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 25 Jul 2006 21:14:42 +0000 Subject: two factor authentication In-Reply-To: <20060725210605.GA27561@orville.25thandClement.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> Message-ID: <44C689C2.6090900@noaa.gov> On 2006-07-25 21:06, William Ahern wrote: > ATM cards are not like smart cards wrt to a very critical characteristic, > you cannot "copy" a smart card. > Well, a smart card > is a computer you keep in your pocket or at your side 24/7, and even more > it's a computer that is, in all practicality, impossible to install malware > on. The thing to remember is that those assertions are true in theory, but because of the closed nature of a smartcard, such assertions are actually much harder to test than equivalent assertions about other systems. Smartcards are a bit like closed DRE voting machines in this respect. And just as in election systems, the target market--high-security applications--is inherently one which someone could benefit greatly by exploiting. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From rapier at psc.edu Wed Jul 26 07:19:36 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 25 Jul 2006 17:19:36 -0400 Subject: two factor authentication In-Reply-To: <20060725210605.GA27561@orville.25thandClement.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> Message-ID: <44C68AE8.9090809@psc.edu> William Ahern wrote: > You can copy a PIN, but with biometric smart cards, which would require, for > instance, a fingerprint scan, you have an extremely strong security device > with hard limitations. A smart card can still be exploited (i.e., stealing > and chopping off a finger, for instance), but since it can't be copied it's > faaaaarrrrrr easier to mitigate the effects of attacks than w/ most any > other mechanism in use today. This is true but its *only* strong if the person trying to get access isn't *really* motivated. If they are motivated its not going to stop them and they'll have all the time they need. Like you said, chopping off a finger is a possibility. More likely they'd just beat/torture you to get access. We tend to discount that as being unlikely. I'm not so sure it will remain that way. The 'panic' code idea is a good one though. From william at 25thandClement.com Wed Jul 26 07:30:04 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 25 Jul 2006 14:30:04 -0700 Subject: two factor authentication In-Reply-To: <44C68AE8.9090809@psc.edu> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C68AE8.9090809@psc.edu> Message-ID: <20060725213004.GC27561@orville.25thandClement.com> On Tue, Jul 25, 2006 at 05:19:36PM -0400, Chris Rapier wrote: > > > William Ahern wrote: > > > You can copy a PIN, but with biometric smart cards, which would require, for > > instance, a fingerprint scan, you have an extremely strong security device > > with hard limitations. A smart card can still be exploited (i.e., stealing > > and chopping off a finger, for instance), but since it can't be copied it's > > faaaaarrrrrr easier to mitigate the effects of attacks than w/ most any > > other mechanism in use today. > > This is true but its *only* strong if the person trying to get access > isn't *really* motivated. If they are motivated its not going to stop > them and they'll have all the time they need. Like you said, chopping > off a finger is a possibility. More likely they'd just beat/torture you > to get access. We tend to discount that as being unlikely. I'm not so > sure it will remain that way. The 'panic' code idea is a good one though. It's not just the fingerprint that can't be copied, it's the card itself. But the important bit is that the exploit is self-limiting. You can collect millions of passwords to e-mail accounts, or millions of credit card numbers, and a criminal has the utmost flexibility to do his crime while eluding the law. Not so w/ a smart card. From william at 25thandClement.com Wed Jul 26 07:41:02 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 25 Jul 2006 14:41:02 -0700 Subject: two factor authentication In-Reply-To: <44C689C2.6090900@noaa.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C689C2.6090900@noaa.gov> Message-ID: <20060725214102.GD27561@orville.25thandClement.com> On Tue, Jul 25, 2006 at 09:14:42PM +0000, Jefferson Ogata wrote: > On 2006-07-25 21:06, William Ahern wrote: > > ATM cards are not like smart cards wrt to a very critical characteristic, > > you cannot "copy" a smart card. > > > Well, a smart card > > is a computer you keep in your pocket or at your side 24/7, and even more > > it's a computer that is, in all practicality, impossible to install malware > > on. > > The thing to remember is that those assertions are true in theory, but > because of the closed nature of a smartcard, such assertions are > actually much harder to test than equivalent assertions about other systems. > > Smartcards are a bit like closed DRE voting machines in this respect. > And just as in election systems, the target market--high-security > applications--is inherently one which someone could benefit greatly by > exploiting. I disagree. IBM researchers and others have published how-to's for breaking smart cards, and the design of smart cards themselves is fairly open. However, so far the only way to break into a smart card inevitably destroys the card itself. That's not to say it's impossible to get the private key w/o destroying the card (maybe through design flaws by some of the many manufacturers--maybe I'm wrong about "many"), but the problem looks pretty darn hard, and it's the intractibility of the problem which limits all or most attacks. Certainly rendering impossible many classes of attacks used today against common secrecy mechanisms and devices. Actually, one of the issues comes down to software versus hardware. W/o a hardware token that will not or cannot disclose it's private information (as opposed to common finger print scanners, for instance, which must send the data to software running on external devices for processing), inevitably somebody will write software to automate attacks. That's what software does best, automating sophisticated tasks. From deengert at anl.gov Wed Jul 26 07:42:20 2006 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 25 Jul 2006 16:42:20 -0500 Subject: two factor authentication In-Reply-To: <20060725210605.GA27561@orville.25thandClement.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> Message-ID: <44C6903C.1020107@anl.gov> William Ahern wrote: > > Sometimes people make sarcastic comments like, "if you're afraid somebody is > going to install a password sniffer or backdoor on your computer then you > should keep your computer on your person at all times". Well, a smart card > is a computer you keep in your pocket or at your side 24/7, and even more > it's a computer that is, in all practicality, impossible to install malware > on. But most don't have any self contained I/O or logging capability. They depend on the machine into which they are inserted. Once the pin has been given, to unlock the card, the card does not know what it is signing, and the user can not even tell if the card is being used, thus it could still be misused by some back door to make a few more ssh conections, or sign a few more documents without the user's knowledge. So if you want to call it the computer in your pocket, it should have some output indicator to at least tell the user it is being used. A reader with these capabilitoes cound alos help. I am not saying there is anything better, but a smart card could be smarter. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From william at 25thandClement.com Wed Jul 26 08:11:25 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 25 Jul 2006 15:11:25 -0700 Subject: two factor authentication In-Reply-To: <44C6903C.1020107@anl.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> Message-ID: <20060725221125.GA14905@orville.25thandClement.com> On Tue, Jul 25, 2006 at 04:42:20PM -0500, Douglas E. Engert wrote: > But most don't have any self contained I/O or logging capability. They > depend > on the machine into which they are inserted. Once the pin has been given, to > unlock the card, the card does not know what it is signing, and the user can > not even tell if the card is being used, thus it could still be misused by > some > back door to make a few more ssh conections, or sign a few more documents > without the user's knowledge. > > So if you want to call it the computer in your pocket, it should have > some output indicator to at least tell the user it is being used. A reader > with these capabilitoes cound alos help. > > I am not saying there is anything better, but a smart card could be > smarter. True. We were just discussing that at work. Requiring a finger print scan for every signing operation would be nice. Or something more specific: a bank issued smart card used w/ Mozilla's PKCS#11 support would know the bank's public key. Whenever the card established a TLS connection to the bank a green light might be illuminated. The smart card can definitely be improved upon, but the real point is that it's a fundamental change in authentication technology... sort of like when OpenSSH killed telnet ;) It allows one to construct a system w/ hard guarantees (well, an incomparably greater degree of assurance), something not feasible today. From fcusack at fcusack.com Wed Jul 26 08:16:38 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 25 Jul 2006 15:16:38 -0700 Subject: two factor authentication In-Reply-To: <44C6903C.1020107@anl.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> Message-ID: <93B03C77AFA445712A8CEA8E@manatee.local> On July 25, 2006 4:42:20 PM -0500 "Douglas E. Engert" wrote: > But most don't have any self contained I/O or logging capability. They depend > on the machine into which they are inserted. Once the pin has been given, to > unlock the card, the card does not know what it is signing, and the user can > not even tell if the card is being used, thus it could still be misused by some > back door to make a few more ssh conections, or sign a few more documents > without the user's knowledge. That's why the VISA/EMV requirement is for the reader to have a PIN pad. The PIN cannot then be software cached for additional transactions. -frank From Jefferson.Ogata at noaa.gov Wed Jul 26 09:55:34 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 25 Jul 2006 23:55:34 +0000 Subject: two factor authentication In-Reply-To: <20060725214102.GD27561@orville.25thandClement.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C689C2.6090900@noaa.gov> <20060725214102.GD27561@orville.25thandClement.com> Message-ID: <44C6AF76.9010206@noaa.gov> On 2006-07-25 21:41, William Ahern wrote: > On Tue, Jul 25, 2006 at 09:14:42PM +0000, Jefferson Ogata wrote: >> The thing to remember is that those assertions are true in theory, but >> because of the closed nature of a smartcard, such assertions are >> actually much harder to test than equivalent assertions about other systems. >> >> Smartcards are a bit like closed DRE voting machines in this respect. >> And just as in election systems, the target market--high-security >> applications--is inherently one which someone could benefit greatly by >> exploiting. > > I disagree. IBM researchers and others have published how-to's for breaking > smart cards, and the design of smart cards themselves is fairly open. No howto can tell you whether there's a secret signaling sequence that will modify the behavior of the smartcard. Again this is just like DREs--you can test them all you like, but it just takes one person who knows the sequence of touches to invoke a modified behavior and swing an election. > However, so far the only way to break into a smart card inevitably destroys > the card itself. Which is exactly the problem. It's thus very difficult to tell whether there's a hardware back door because if you crack it open to check you may destroy it. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dkg-openssh.com at fifthhorseman.net Wed Jul 26 09:43:27 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jul 2006 19:43:27 -0400 Subject: two factor authentication In-Reply-To: <44C6903C.1020107@anl.gov> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> Message-ID: <17606.44191.582905.636085@squeak.fifthhorseman.net> On July 25, deengert at anl.gov said: > So if you want to call it the computer in your pocket, it should > have some output indicator to at least tell the user it is being > used. A reader with these capabilitoes cound alos help. i use a Cryptoflex eGate with their USB tokens with openssh [0] via opensc (i didn't think opensc was all that bad, incidentally). The USB token has an LED that flashes when it is computing and (i assume) stays off when it is not in use. So some output indicators do exist. However, i share your general ambivalence about smartcards, and only use the smartcard/USB token on a trusted machine anyway. A compromised ssh client on an untrustworthy machine can simply piggyback on a "properly" authenticated connection (yes, including one that uses smartcards), and set up backdoors or trash filesystems or other nasty things. I also share Jefferson Ogata's concerns about the closed nature of the hardware, though i note that some smartcards are being developed with what appears to be an open process [1]. Smartcards are definitely not a panacea. --dkg [0] http://lair.fifthhorseman.net/~dkg/egate/ [1] http://www.g10code.com/p-card.html From alon.barlev at gmail.com Wed Jul 26 15:32:59 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 26 Jul 2006 08:32:59 +0300 Subject: two factor authentication In-Reply-To: <875F9D313F622649CE0DB982@manatee.local> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <875F9D313F622649CE0DB982@manatee.local> Message-ID: <44C6FE8B.4070507@gmail.com> Frank Cusack wrote: > On July 25, 2006 8:17:06 AM +0300 Alon Bar-Lev > wrote: >> You can also consider biometric enabled smartcards, and have 3 factors. >> But biometric is the worse from user perspective. > > Why is that? > > -frank > Since my testings showed that the low cost readers used in smartcard readers are too weak... The user usually should try an average 2 times to login... And there are 15% of people that cannot use these readers at all, since there biometric produces too much or too few heat. I also think that a computer software that sits between the reader and the driver can transmit a finger print without it being read from the reader... I know there is a new reader that update the APDU sent to the card with the fingerprint... When this will be available and the reader will be improved I think it would be nice. Best Regards, Alon Bar-Lev. From william at 25thandClement.com Wed Jul 26 15:55:02 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 25 Jul 2006 22:55:02 -0700 Subject: two factor authentication In-Reply-To: <44C6FD51.2000101@gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> <17606.44191.582905.636085@squeak.fifthhorseman.net> <44C6FD51.2000101@gmail.com> Message-ID: <20060726055502.GA9069@orville.25thandClement.com> On Wed, Jul 26, 2006 at 08:27:45AM +0300, Alon Bar-Lev wrote: > Daniel Kahn Gillmor wrote: > >I also share Jefferson Ogata's concerns about the closed nature of the > >hardware, though i note that some smartcards are being developed with > >what appears to be an open process [1]. > > > >Smartcards are definitely not a panacea. > > Right. > It is better putting your private key on a file and use password to > access the server... > He didn't say that. What he said was in the same vein as "ice is cold". ;) I think we all understand that smart cards do not present a panacea in the realm of authentiation. But I argue that they do provide a critical, heretofore absent link in end-to-end security across the network. And significantly a link whose properties allow it to become a dependable component in a coherent, parameterizable security system. To say any password-based system--employed within a network--is comparable sounds like, pardon me, a joke. Anyhoo, this is dragging on.... From alon.barlev at gmail.com Wed Jul 26 15:27:45 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 26 Jul 2006 08:27:45 +0300 Subject: two factor authentication In-Reply-To: <17606.44191.582905.636085@squeak.fifthhorseman.net> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> <17606.44191.582905.636085@squeak.fifthhorseman.net> Message-ID: <44C6FD51.2000101@gmail.com> Daniel Kahn Gillmor wrote: > I also share Jefferson Ogata's concerns about the closed nature of the > hardware, though i note that some smartcards are being developed with > what appears to be an open process [1]. > > Smartcards are definitely not a panacea. Right. It is better putting your private key on a file and use password to access the server... I don't believe what I read! You don't trust the vendors that manufacture the smartcards, but you don't offer any other security solution that is close to the level smartcards offer. Just select the company you trust... Exactly the same can be said on your computer manufacturer, network card manufacturer, even the modem chip manufacturer, and the sound chip manufacturer that can make your computer as a tap device. The DOD use smartcards (CAC) all over their application... They are stupid too... And also violates the white house requirements Jefferson referred to, right? Best Regards, Alon Bar-Lev. From fcusack at fcusack.com Wed Jul 26 16:04:33 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 25 Jul 2006 23:04:33 -0700 Subject: two factor authentication In-Reply-To: <44C6FE8B.4070507@gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <875F9D313F622649CE0DB982@manatee.local> <44C6FE8B.4070507@gmail.com> Message-ID: <26AAFA0056B5CD6EBF62234C@manatee.local> On July 26, 2006 8:32:59 AM +0300 Alon Bar-Lev wrote: > Frank Cusack wrote: >> On July 25, 2006 8:17:06 AM +0300 Alon Bar-Lev >> wrote: >>> You can also consider biometric enabled smartcards, and have 3 factors. >>> But biometric is the worse from user perspective. >> >> Why is that? >> >> -frank >> > > Since my testings showed that the low cost readers used in smartcard readers > are too weak... The user usually should try an average 2 times to login... And there > are 15% of people that cannot use these readers at all, since there biometric > produces too much or too few heat. > > I also think that a computer software that sits between the reader and the driver > can transmit a finger print without it being read from the reader... > > I know there is a new reader that update the APDU sent to the card with the fingerprint... > When this will be available and the reader will be improved I think it would be nice. Or my company's cards, www.tri-dsystems.com, where the reader is on the card. enroll-on-card, match-on-card. It can be used 2-factor (no pin) or 3-factor. (Well, it will soon. Today it only works as an OTP token.) The reader is a mechanical device, heat doesn't matter. However folks with very slight fingerprints will have a problem. -frank From alon.barlev at gmail.com Wed Jul 26 17:00:23 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 26 Jul 2006 09:00:23 +0200 Subject: two factor authentication In-Reply-To: <20060726055502.GA9069@orville.25thandClement.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> <17606.44191.582905.636085@squeak.fifthhorseman.net> <44C6FD51.2000101@gmail.com> <20060726055502.GA9069@orville.25thandClement.com> Message-ID: <9e0cf0bf0607260000i40b60b21yfa1b20df626b688b@mail.gmail.com> On 7/26/06, William Ahern wrote: > But I argue that they do provide a critical, heretofore absent link in > end-to-end security across the network. And significantly a link whose > properties allow it to become a dependable component in a coherent, > parameterizable security system. To say any password-based system--employed > within a network--is comparable sounds like, pardon me, a joke. OK. This summerize this thread correctly. I hope it I will stop here. Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Wed Jul 26 17:14:34 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 26 Jul 2006 09:14:34 +0200 Subject: two factor authentication In-Reply-To: <26AAFA0056B5CD6EBF62234C@manatee.local> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <875F9D313F622649CE0DB982@manatee.local> <44C6FE8B.4070507@gmail.com> <26AAFA0056B5CD6EBF62234C@manatee.local> Message-ID: <9e0cf0bf0607260014n25410ba4wef34d816bdaca8c4@mail.gmail.com> On 7/26/06, Frank Cusack wrote: > Or my company's cards, www.tri-dsystems.com, where the reader is on the card. > enroll-on-card, match-on-card. It can be used 2-factor (no pin) or 3-factor. > > (Well, it will soon. Today it only works as an OTP token.) > > The reader is a mechanical device, heat doesn't matter. However folks with > very slight fingerprints will have a problem. > > -frank > Nice device! I was not aware that someone put a biometric reader on the PVC. I will be happy to test one when you integrate the biometric reader into the smartcard support! Which smartcard chip do you use? Will it work with PKCS#15 complaint middleware such as OpenSC? Or you provide a PKCS#11? What is the estimated cost of such card? (1000 units). Best Regards, Alon Bar-Lev. From carson at taltos.org Wed Jul 26 22:57:25 2006 From: carson at taltos.org (Carson Gaspar) Date: Wed, 26 Jul 2006 05:57:25 -0700 Subject: two factor authentication In-Reply-To: <9e0cf0bf0607260014n25410ba4wef34d816bdaca8c4@mail.gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <875F9D313F622649CE0DB982@manatee.local> <44C6FE8B.4070507@gmail.com> <26AAFA0056B5CD6EBF62234C@manatee.local> <9e0cf0bf0607260014n25410ba4wef34d816bdaca8c4@mail.gmail.com> Message-ID: --On Wednesday, July 26, 2006 9:14 AM +0200 Alon Bar-Lev wrote: > Nice device! > I was not aware that someone put a biometric reader on the PVC. I'm pretty sure the Sony Puppy (FIU-710 and friends - looks like some newer models are out, but possibly only in Japan) has had that for quite some time now. -- Carson From bob at proulx.com Thu Jul 27 02:02:37 2006 From: bob at proulx.com (Bob Proulx) Date: Wed, 26 Jul 2006 10:02:37 -0600 Subject: How to use SSH with Failed Login attempts and locking accounts In-Reply-To: <273CACD967F9BC47B023F758ACBC3A8C075855F4@NASEV06.hca.corpad.net> References: <273CACD967F9BC47B023F758ACBC3A8C075855F4@NASEV06.hca.corpad.net> Message-ID: <20060726160237.GA21432@dementia.proulx.com> Hughes Andy wrote: > I am using openssh (OpenSSH_4.2p1, OpenSSL 0.9.8 05 Jul 2005) on MP-RAS > Version 3.3.1.8 and 3.2 and I desire to allow a user to fail login for > any reason only 3 (three) times and then lock the account. That is a very bad idea for many reasons. If you search around you will find references to denial of service attacks due to configurations such as what you propose. The basic problem is that an attacker will disable the account for a valid user. Why do you want to do this? It is computationally infeasible to brute force through a password cracking attempt from the remote interface. Bob From fcusack at fcusack.com Thu Jul 27 03:00:50 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 26 Jul 2006 10:00:50 -0700 Subject: two factor authentication In-Reply-To: References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5343C.5080607@noaa.gov> <44C5A952.1040302@gmail.com> <875F9D313F622649CE0DB982@manatee.local> <44C6FE8B.4070507@gmail.com> <26AAFA0056B5CD6EBF62234C@manatee.local> <9e0cf0bf0607260014n25410ba4wef34d816bdaca8c4@mail.gmail.com> Message-ID: <32D97FA54C14F1A11C79295F@manatee.local> On July 26, 2006 5:57:25 AM -0700 Carson Gaspar wrote: > > > --On Wednesday, July 26, 2006 9:14 AM +0200 Alon Bar-Lev > wrote: > >> Nice device! >> I was not aware that someone put a biometric reader on the PVC. > > I'm pretty sure the Sony Puppy (FIU-710 and friends - looks like some newer > models are out, but possibly only in Japan) has had that for quite some > time now. But not in ISO-7816 form factor. -frank From amesbury at umn.edu Thu Jul 27 05:22:56 2006 From: amesbury at umn.edu (Alan Amesbury) Date: Wed, 26 Jul 2006 14:22:56 -0500 Subject: [PATCH] Correction to ssh_config(5) Message-ID: <44C7C110.2070808@umn.edu> Based on http://www.openssh.org/report.html I'm assuming that non-security patch submissions should go through here. If not, please point me in the appropriate direction. Attached is a patch that cleans up a small section in ssh_config(5). As a user of FreeBSD, I submitted it to them. They pointed out that it was in their contrib section, and that suggesting the change to you would be the best course of action. The patch is based on OpenSSH_4.2p1 as it appears in FreeBSD 6.1-RELEASE, which has these Id strings: $OpenBSD: ssh_config.5,v 1.61 2005/07/08 12:53:10 jmc Exp $ $FreeBSD: src/crypto/openssh/ssh_config.5,v 1.17.2.1 2005/09/11 16:50:35 des Exp $ Patch is attached, let me know if you need more information, and thanks in advance! -- Alan Amesbury University of Minnesota -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh_config.5.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060726/0b9e74d5/attachment.ksh From andreas at schigold.de Sat Jul 29 07:06:40 2006 From: andreas at schigold.de (Andreas Schigold) Date: Fri, 28 Jul 2006 23:06:40 +0200 Subject: my development with new feature MaxIdleTime Message-ID: <44CA7C60.3000303@schigold.de> Hello, at July, 20th I wrote about a new feature I developed. But to this mail I got no reaction til this moment. Did I made something wrong? Do You have no interest for this? Do I be inside the wrong community? There is no hurry, I only interested for your feedback. Thank you for your attention and kind regards, Andreas Schigold -- ############################# # Andreas Schigold # # mail: andreas at schigold.de # ############################# From langosh.l at comcast.net Sat Jul 29 08:26:36 2006 From: langosh.l at comcast.net (Lucas Langosh) Date: Fri, 28 Jul 2006 16:26:36 -0600 Subject: I have some problems Message-ID: <000601c6b294$f2ab3bd0$6401a8c0@luke> I use Open SSH and love it. It's wonderful program. I have a problem though. When I use it at school, I can connect out to the internet and to my home machine and then login in to my machine. The problem is that the school has BESS, which blocks out sites that they claim that are not fit for students and some of my sites are filtered even through the SSH client I use. Can I bypass this using OpenSSH? They already figured out that using a proxy on port 3124 would bypass it and have fixed that so this was the only way I knew to get what I want. The next step would be to find the admin password for their network, but i'm no hacker so I was just curious. From amit.prsh at gmail.com Sat Jul 29 16:05:12 2006 From: amit.prsh at gmail.com (amit sh) Date: Sat, 29 Jul 2006 11:35:12 +0530 Subject: cross compiling SSH for MIPS Message-ID: Hi I am new to the ever lasting SSH world. Please do help me in compiling the SSH gcc application on mips cross compiler. I am facing lot of problems while compiling the SSH application for mips using the mips-linux-gcc compiler. Do suggest. Regards Amit From stuge-openssh-unix-dev at cdy.org Sun Jul 30 04:54:43 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 29 Jul 2006 20:54:43 +0200 Subject: cross compiling SSH for MIPS In-Reply-To: References: Message-ID: <20060729185443.25966.qmail@cdy.org> On Sat, Jul 29, 2006 at 11:35:12AM +0530, amit sh wrote: > I am new to the ever lasting SSH world. > Please do help me in compiling the SSH gcc application on > mips cross compiler. I am facing lot of problems while compiling > the SSH application for mips using the mips-linux-gcc compiler. > Do suggest. Hi, it's impossible to suggest anything without knowing exactly what problem your are faced with. Please provide the error messages that are presented to you. If you are new to reporting bugs in general I recommend reading "How to Report Bugs Efficiently" which is available online at http://www.chiark.greenend.org.uk/~sgtatham/bugs.html since it provides a number of good tips. //Peter From Jefferson.Ogata at noaa.gov Mon Jul 31 05:06:32 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 30 Jul 2006 19:06:32 +0000 Subject: two factor authentication In-Reply-To: <9e0cf0bf0607260000i40b60b21yfa1b20df626b688b@mail.gmail.com> References: <450DD3FC22F51F95172A9AD0@manatee.local> <44C5A952.1040302@gmail.com> <44C634D5.9000004@psc.edu> <44C650F5.9010100@gmail.com> <44C65897.5090800@psc.edu> <20060725210605.GA27561@orville.25thandClement.com> <44C6903C.1020107@anl.gov> <17606.44191.582905.636085@squeak.fifthhorseman.net> <44C6FD51.2000101@gmail.com> <20060726055502.GA9069@orville.25thandClement.com> <9e0cf0bf0607260000i40b60b21yfa1b20df626b688b@mail.gmail.com> Message-ID: <44CD0338.8090100@noaa.gov> On 2006-07-26 07:00, Alon Bar-Lev wrote: > On 7/26/06, William Ahern wrote: >> But I argue that they do provide a critical, heretofore absent link in >> end-to-end security across the network. And significantly a link whose >> properties allow it to become a dependable component in a coherent, >> parameterizable security system. To say any password-based system--employed >> within a network--is comparable sounds like, pardon me, a joke. > > OK. > This summerize this thread correctly. > I hope it I will stop here. Alon, I'll try to spell this out for you one more time. I don't want to resurrect a discussion of the minutiae of this issue--this is intended as a big-picture overview. There is, cryptographically speaking, no difference between a one-time password system and a smartcard. To see this, imagine the following two scenarios: 1. Admin generates a keypair on a smartcard, and adds the public key to his authentication system. At authentication time, the system challenges the user, and the smartcard uses the challenge and private key to calculate a response. 2. Admin generates a keypair in software. No part of the keypair is divulged to the user. The keypair is used to generate a list of n challenge-response pairs; these are given to the user on a piece of paper. At authentication time, the system challenges the user, and the user locates the response on the piece of paper. The algorithmic difference between these two scenarios is whether the crypto is being done at authentication time in hardware on a smartcard--i.e. the smartcard calculates the response using the challenge and the private key--or at some earlier time when the challenge-response pairs are pre-generated. In other words, a smartcard /is/ a one-time password system, where the responses are related to the challenges by a cryptographic operation that depends on the private key stored in the smartcard. The smartcard has the advantage (or disadvantage, depending on your requirements) that you don't need to distribute a new set of challenge-response pairs to the user when the old set is exhausted, since calculation of a response can be performed by the smartcard an unlimited number of times. And it's convenient for the user, because he doesn't have to type a long one-time password. But because the smartcard is a sealed device, there is no way to know whether it will also calculate responses at the request of a sufficiently well informed attacker sitting nearby in the coffee shop, either because of incompetent or deliberate design flaw. The essential properties of a smartcard--it incorporates cryptographic algorithms and is difficult to disassemble without destruction--make it an ideal place to hide a back door. The piece of paper has the advantage that it is more flexible because the challenge-response pairs don't actually have to be cryptographically related--they can be completely random, so long as the system performing authentication has access to the same list that was given to the user. Even if a cryptographic algorithm is used, the user doesn't carry a device on which the underlying secret resides. (A smartcard with these properties could be built, but this is not the traditional approach.) Of course the piece of paper has a number of disadvantages of convenience and physical security, but from a theoretical standpoint it is no different from a smartcard--it relates unique challenges to responses in a way that may be made entirely opaque to the user, and access to the challenge-response relation, rather than knowledge of some fixed secret, is the authenticator. In both cases, the question is how you protect access to the challenge-response relation, whether it exists as an infinite cryptographic function in silicon, or as ink on a finite piece of paper in the user's pocket, against unauthorized users. And in both cases, whatever method is chosen may fail. Estimating the probability of this failure's occurring in a smartcard is practically impossible, since it may be due to either incompetence or deliberate design of the vendor or manufacturer. This is why if you use smartcards and you want to have any confidence in your security, it is /necessary/ to combine them with another, completely independent, authentication factor; even a lowly fixed password is better than nothing. Now before you respond again, please go back and read the entire thread thoroughly. Also, note that I am not the original poster, nor does the White House memo that I excerpted completely encompass the principles that are at work in this discussion; it is merely an example of some people's requirements. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service