From djm at mindrot.org Thu Nov 1 02:55:57 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2012 02:55:57 +1100 (EST) Subject: AuthorizedKeysCommand support added In-Reply-To: <2DBD0E67-B9AA-48F7-91A3-275BAF6C6ECF@alex.org.uk> References: <2241E4D3-5360-4811-AE77-7F1CB0E35A78@alex.org.uk> <2DBD0E67-B9AA-48F7-91A3-275BAF6C6ECF@alex.org.uk> Message-ID: On Wed, 31 Oct 2012, Alex Bligh wrote: > > On 31 Oct 2012, at 08:01, Damien Miller wrote: > > >> > >> Or have you by this time checked the username is in some way sane? > > > > It is only invoked if the user actually has an account on the host, so > > there is no risk of bad usernames percolating through to the helper. > > My concern was partly the LDAP case where (at least with the ldap patches) > it lets you if there is an account on the LDAP server. I'm not sure whether > there is some form of escalation opportunity here. I think with the > Match group thing, perhaps not. Can we guarantee that the username is > a string for which getpwnam returns an entry? Yes. > If so, perhaps this isn't > a problem, as if admins permit users with | `` < > $ {} etc in, then they > deserve all they get if they don't write safe scripts. It would be useful > to document that the script can rely on the fact that $1 is a username > for which getpwnam returned something sometime in the recent past. I'd rather leave them paranoid if it encourages proper care :) -d From djm at mindrot.org Thu Nov 1 02:57:35 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2012 02:57:35 +1100 (EST) Subject: AW: AuthorizedKeysCommand support added In-Reply-To: <2ECE9D9EEF1F524185270138AE2326590179CF@S0MSMAIL112.arc.local> References: <2ECE9D9EEF1F524185270138AE2326590179CF@S0MSMAIL112.arc.local> Message-ID: On Wed, 31 Oct 2012, Fiedler Roman wrote: > Hi, > > Just curious: > > > ... > > The program is executed (directly, not via the shell) with a single > > argument of the user being logged in. It produces on stdout zero or more > > lines in authorized_keys format. The program must terminate normally and > > with a zero exit status or its output is disregarded. > > > > The program is executed as the user being logged in, unless a different > > user is specified using AuthorizedKeysCommandUser. > > Does this allow: > > * Login as user x > * Fork a daemon process to stay alive after logout > * Logout > * Login again > * Let the daemon process running as x attach to the key-fetch-script running as x, take over fds, .. > * Let key-fetch-script return something nice > > This would of course only work, if e.g. ptrace-attach to non-children > with same UID is allowed, which is OK on older kernels/distros, new > ones should block that. Well, it would let you break into your own account. This is a risk of using the target user for the login script, which is something we explicitly recommend against. -d From djm at mindrot.org Thu Nov 1 03:00:03 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2012 03:00:03 +1100 (EST) Subject: AuthorizedKeysCommand support added In-Reply-To: <201210311118.01858.philipp.marek@linbit.com> References: <201210310748.03009.philipp.marek@linbit.com> <201210311118.01858.philipp.marek@linbit.com> Message-ID: On Wed, 31 Oct 2012, Philipp Marek wrote: > > > Furthermore, how about setting alarm(60) or some similar timeout, and > > > perhaps a CPU limit in the child handler, so that it doesn't run > > > forever? > > > > The helper is subject to the global login grace timeout (sshd_config > > LoginGraceTime). > But I see no code that would kill the process then - only the authentication > would fail, right? search for killpg in sshd.c > > > TBH, I can see the point that having a simple shell script inbetween - > > > that can do all of this, too. > > > > No - the shell environment is too complicated for something that can > > be triggered before authentication. > Sorry for being unclear, I meant setting CPU (and other) ulimits, STDERR > redirection and so on - these things can be done by a shell script. > (Even syslog, by using logger(1).) Why not build them into the helper directly? It isn't someting that will be need to be written more than once per backend directory. -d From Roman.Fiedler at ait.ac.at Thu Nov 1 03:14:20 2012 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Wed, 31 Oct 2012 16:14:20 +0000 Subject: AW: AW: AuthorizedKeysCommand support added In-Reply-To: References: <2ECE9D9EEF1F524185270138AE2326590179CF@S0MSMAIL112.arc.local> Message-ID: <2ECE9D9EEF1F524185270138AE232659017BFB@S0MSMAIL112.arc.local> Hi, > -----Urspr?ngliche Nachricht----- > Von: Damien Miller [mailto:djm at mindrot.org] > An: Fiedler Roman > Cc: openssh-unix-dev at mindrot.org > Betreff: Re: AW: AuthorizedKeysCommand support added > > On Wed, 31 Oct 2012, Fiedler Roman wrote: > > > Hi, > > > > Just curious: > > > > > ... > > > The program is executed (directly, not via the shell) with a single > > > argument of the user being logged in. It produces on stdout zero or more > > > lines in authorized_keys format. The program must terminate normally > and > > > with a zero exit status or its output is disregarded. > > > > > > The program is executed as the user being logged in, unless a different > > > user is specified using AuthorizedKeysCommandUser. > > > > Does this allow: > > > > * Login as user x > > * Fork a daemon process to stay alive after logout > > * Logout > > * Login again > > * Let the daemon process running as x attach to the key-fetch-script > running as x, take over fds, .. > > * Let key-fetch-script return something nice > > > > This would of course only work, if e.g. ptrace-attach to non-children > > with same UID is allowed, which is OK on older kernels/distros, new > > ones should block that. > > Well, it would let you break into your own account. It would let you break in your own account if you just return your keys. Would spread harvoc if any fds from sshd other than stdout are open. I've just looked at the patch and are not quite sure if code might be vulnerable: You are switching uids before close of fds>STDERR+1. Is it possible to attach to the script between setresuid and closefrom? If kernel allows that, this would give access to all open sshd fds. To verify, I would have to check the specs or setup a test instance (or do you have one?) > This is a risk of using > the target user for the login script, which is something we explicitly > recommend against. OK, then documentation is quite important: if I understand it right, the default will be this unsafe mode, unless one uses AuthorizedKeysCommandUser Roman From djm at mindrot.org Thu Nov 1 07:44:32 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2012 07:44:32 +1100 (EST) Subject: AW: AW: AuthorizedKeysCommand support added In-Reply-To: <2ECE9D9EEF1F524185270138AE232659017BFB@S0MSMAIL112.arc.local> References: <2ECE9D9EEF1F524185270138AE2326590179CF@S0MSMAIL112.arc.local> <2ECE9D9EEF1F524185270138AE232659017BFB@S0MSMAIL112.arc.local> Message-ID: On Wed, 31 Oct 2012, Fiedler Roman wrote: > > Well, it would let you break into your own account. > > It would let you break in your own account if you just return your > keys. Would spread harvoc if any fds from sshd other than stdout are > open. I've just looked at the patch and are not quite sure if code > might be vulnerable: > > You are switching uids before close of fds>STDERR+1. Is it possible to >attach to the script between setresuid and closefrom? If kernel allows >that, this would give access to all open sshd fds. No sane kernel allows ptrace of processes that have changed uid or gid by the destination uid or gid. > > This is a risk of using > > the target user for the login script, which is something we explicitly > > recommend against. > > OK, then documentation is quite important: if I understand it > right, the default will be this unsafe mode, unless one uses > AuthorizedKeysCommandUser yes, though "unsafe" is relative here. It would be nice to have a dedicated _ssh_helper account or somesuch that we could rely on to be the default. Perhaps it would be better to ship with no default whatsoever but support %u as an option. -d From lars.schade at berlin.de Thu Nov 1 21:22:35 2012 From: lars.schade at berlin.de (Lars Schade) Date: Thu, 01 Nov 2012 11:22:35 +0100 Subject: sftp authentication failure only as cronjob Message-ID: <1351765355.2612.23.camel@rosinante.berlin> Hi all, I have a problem using sftp which I cannot get solved even after searching all over the web, so maybe one of you has a useful hint: I want to run a simple script that puts a file on a server using sftp. Keys are setup correctly, everything works fine if I run the script from within a terminal. When I run the same script from the crontab (my personal crontab as user) the script runs fine on one installation (running OpenSSH_5.4 on an older fedora 13 machine) but fails on another machine (running OpenSSH_5.3 on a recent centos 6.3). I assume that the failure is not caused by the older version of OpenSSH but rather due to some difference in setup but simply cannot get to the root of the problem. The ssh_config files are identical on both machines. The debug trace (using -v) when run interactively on the centos system is a follows: OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to www.lars-schade.de [82.165.88.246] port 22. debug1: Connection established. debug1: identity file /home/lars/.ssh/id_rsa type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH debug1: match: OpenSSH pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'www.lars-schade.de' is known and matches the DSA host key. debug1: Found key in /home/lars/.ssh/known_hosts:2 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /home/lars/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: Authentication succeeded (publickey). ... When the same script is run from the crontab the trace is identical except that the authentication fails: OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to www.lars-schade.de [82.165.88.246] port 22. debug1: Connection established. debug1: identity file /home/lars/.ssh/id_rsa type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH debug1: match: OpenSSH pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'www.lars-schade.de' is known and matches the DSA host key. debug1: Found key in /home/lars/.ssh/known_hosts:2 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /home/lars/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type debug1: No more authentication methods to try. Permission denied (publickey,password). Couldn't read packet: Connection reset by peer Again the script runs fine from the crontab on the fedora 13 machine but fails on the centos 6.3 machine (even though it works there interactively). Anyone any ideas or hints what the cause of the authentication failure could be or where to look at? Thanks, Lars From djm at mindrot.org Fri Nov 2 07:48:38 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 Nov 2012 07:48:38 +1100 (EST) Subject: sftp authentication failure only as cronjob In-Reply-To: <1351765355.2612.23.camel@rosinante.berlin> References: <1351765355.2612.23.camel@rosinante.berlin> Message-ID: On Thu, 1 Nov 2012, Lars Schade wrote: > Hi all, > > I have a problem using sftp which I cannot get solved even after > searching all over the web, so maybe one of you has a useful hint: > > I want to run a simple script that puts a file on a server using sftp. > Keys are setup correctly, everything works fine if I run the script from > within a terminal. When I run the same script from the crontab (my > personal crontab as user) the script runs fine on one installation > (running OpenSSH_5.4 on an older fedora 13 machine) but fails on another > machine (running OpenSSH_5.3 on a recent centos 6.3). > > I assume that the failure is not caused by the older version of OpenSSH > but rather due to some difference in setup but simply cannot get to the > root of the problem. The ssh_config files are identical on both > machines. > > The debug trace (using -v) when run interactively on the centos system > is a follows: ... > debug1: Offering public key: /home/lars/.ssh/id_rsa > debug1: Server accepts key: pkalg ssh-rsa blen 277 > debug1: PEM_read_PrivateKey failed The only thing that appears different is that the private key is failing to load. You aren't using ssh-agent are you? (it doesn't look like you are) Is SELinux enabled? It might be preventing jobs launched by cron from accessing your private keys. You could test this by trying to run something like "md5sum /home/lars/.ssh/id_rsa" from cron and seeing if it succeeds (or by finding errors in the logs) -d From lars.schade at berlin.de Fri Nov 2 09:12:09 2012 From: lars.schade at berlin.de (Lars Schade) Date: Thu, 01 Nov 2012 23:12:09 +0100 Subject: sftp authentication failure only as cronjob In-Reply-To: References: <1351765355.2612.23.camel@rosinante.berlin> Message-ID: <1351807929.19027.8.camel@rosinante.berlin> Hi Damien, thanks for the quick reply. I just ran the same test with SELinux in permissive mode - same result. And SELinux is enabled on the fedora 13 machine where the script runs from the crontab. Any other ideas, anything else I should check? Regards, Lars Am Freitag, den 02.11.2012, 07:48 +1100 schrieb Damien Miller: > On Thu, 1 Nov 2012, Lars Schade wrote: > > > Hi all, > > > > I have a problem using sftp which I cannot get solved even after > > searching all over the web, so maybe one of you has a useful hint: > > > > I want to run a simple script that puts a file on a server using sftp. > > Keys are setup correctly, everything works fine if I run the script from > > within a terminal. When I run the same script from the crontab (my > > personal crontab as user) the script runs fine on one installation > > (running OpenSSH_5.4 on an older fedora 13 machine) but fails on another > > machine (running OpenSSH_5.3 on a recent centos 6.3). > > > > I assume that the failure is not caused by the older version of OpenSSH > > but rather due to some difference in setup but simply cannot get to the > > root of the problem. The ssh_config files are identical on both > > machines. > > > > The debug trace (using -v) when run interactively on the centos system > > is a follows: > > ... > > > debug1: Offering public key: /home/lars/.ssh/id_rsa > > debug1: Server accepts key: pkalg ssh-rsa blen 277 > > debug1: PEM_read_PrivateKey failed > > The only thing that appears different is that the private key is failing > to load. You aren't using ssh-agent are you? (it doesn't look like you are) > > Is SELinux enabled? It might be preventing jobs launched by cron from > accessing your private keys. You could test this by trying to run something > like "md5sum /home/lars/.ssh/id_rsa" from cron and seeing if it succeeds > (or by finding errors in the logs) > > -d From mouring at offwriting.org Fri Nov 2 09:41:43 2012 From: mouring at offwriting.org (Ben Lindstrom) Date: Thu, 1 Nov 2012 17:41:43 -0500 Subject: sftp authentication failure only as cronjob In-Reply-To: <1351807929.19027.8.camel@rosinante.berlin> References: <1351765355.2612.23.camel@rosinante.berlin> <1351807929.19027.8.camel@rosinante.berlin> Message-ID: <90755FDB-EC98-4518-ADF4-E787535E8D97@offwriting.org> Are you using krb5 as an internal authentication? If so your cron will need a krb5 keytab to be given true permission to access and manipulate files. - Ben On Nov 1, 2012, at 5:12 PM, Lars Schade wrote: > Hi Damien, > > thanks for the quick reply. I just ran the same test with SELinux in > permissive mode - same result. And SELinux is enabled on the fedora 13 > machine where the script runs from the crontab. > > Any other ideas, anything else I should check? > > Regards, Lars > > Am Freitag, den 02.11.2012, 07:48 +1100 schrieb Damien Miller: >> On Thu, 1 Nov 2012, Lars Schade wrote: >> >>> Hi all, >>> >>> I have a problem using sftp which I cannot get solved even after >>> searching all over the web, so maybe one of you has a useful hint: >>> >>> I want to run a simple script that puts a file on a server using sftp. >>> Keys are setup correctly, everything works fine if I run the script from >>> within a terminal. When I run the same script from the crontab (my >>> personal crontab as user) the script runs fine on one installation >>> (running OpenSSH_5.4 on an older fedora 13 machine) but fails on another >>> machine (running OpenSSH_5.3 on a recent centos 6.3). >>> >>> I assume that the failure is not caused by the older version of OpenSSH >>> but rather due to some difference in setup but simply cannot get to the >>> root of the problem. The ssh_config files are identical on both >>> machines. >>> >>> The debug trace (using -v) when run interactively on the centos system >>> is a follows: >> >> ... >> >>> debug1: Offering public key: /home/lars/.ssh/id_rsa >>> debug1: Server accepts key: pkalg ssh-rsa blen 277 >>> debug1: PEM_read_PrivateKey failed >> >> The only thing that appears different is that the private key is failing >> to load. You aren't using ssh-agent are you? (it doesn't look like you are) >> >> Is SELinux enabled? It might be preventing jobs launched by cron from >> accessing your private keys. You could test this by trying to run something >> like "md5sum /home/lars/.ssh/id_rsa" from cron and seeing if it succeeds >> (or by finding errors in the logs) >> >> -d > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From lars.schade at berlin.de Sat Nov 3 04:55:47 2012 From: lars.schade at berlin.de (Lars Schade) Date: Fri, 02 Nov 2012 18:55:47 +0100 Subject: sftp authentication failure only as cronjob In-Reply-To: <90755FDB-EC98-4518-ADF4-E787535E8D97@offwriting.org> References: <1351765355.2612.23.camel@rosinante.berlin> <1351807929.19027.8.camel@rosinante.berlin> <90755FDB-EC98-4518-ADF4-E787535E8D97@offwriting.org> Message-ID: <1351878947.2677.3.camel@rosinante.berlin> Hi Ben, thanks for the hint. The machine is a standard centos 6.3 install so it should be using a standard UNIX password database (/etc/passwd) as far as I know. How can I check to be sure? Regards Lars Am Donnerstag, den 01.11.2012, 17:41 -0500 schrieb Ben Lindstrom: > Are you using krb5 as an internal authentication? If so your cron will need a krb5 > keytab to be given true permission to access and manipulate files. > > - Ben > > On Nov 1, 2012, at 5:12 PM, Lars Schade wrote: > > > Hi Damien, > > > > thanks for the quick reply. I just ran the same test with SELinux in > > permissive mode - same result. And SELinux is enabled on the fedora 13 > > machine where the script runs from the crontab. > > > > Any other ideas, anything else I should check? > > > > Regards, Lars > > > > Am Freitag, den 02.11.2012, 07:48 +1100 schrieb Damien Miller: > >> On Thu, 1 Nov 2012, Lars Schade wrote: > >> > >>> Hi all, > >>> > >>> I have a problem using sftp which I cannot get solved even after > >>> searching all over the web, so maybe one of you has a useful hint: > >>> > >>> I want to run a simple script that puts a file on a server using sftp. > >>> Keys are setup correctly, everything works fine if I run the script from > >>> within a terminal. When I run the same script from the crontab (my > >>> personal crontab as user) the script runs fine on one installation > >>> (running OpenSSH_5.4 on an older fedora 13 machine) but fails on another > >>> machine (running OpenSSH_5.3 on a recent centos 6.3). > >>> > >>> I assume that the failure is not caused by the older version of OpenSSH > >>> but rather due to some difference in setup but simply cannot get to the > >>> root of the problem. The ssh_config files are identical on both > >>> machines. > >>> > >>> The debug trace (using -v) when run interactively on the centos system > >>> is a follows: > >> > >> ... > >> > >>> debug1: Offering public key: /home/lars/.ssh/id_rsa > >>> debug1: Server accepts key: pkalg ssh-rsa blen 277 > >>> debug1: PEM_read_PrivateKey failed > >> > >> The only thing that appears different is that the private key is failing > >> to load. You aren't using ssh-agent are you? (it doesn't look like you are) > >> > >> Is SELinux enabled? It might be preventing jobs launched by cron from > >> accessing your private keys. You could test this by trying to run something > >> like "md5sum /home/lars/.ssh/id_rsa" from cron and seeing if it succeeds > >> (or by finding errors in the logs) > >> > >> -d > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Sun Nov 4 22:16:43 2012 From: djm at mindrot.org (Damien Miller) Date: Sun, 4 Nov 2012 22:16:43 +1100 (EST) Subject: AW: AW: AuthorizedKeysCommand support added In-Reply-To: References: <2ECE9D9EEF1F524185270138AE2326590179CF@S0MSMAIL112.arc.local> <2ECE9D9EEF1F524185270138AE232659017BFB@S0MSMAIL112.arc.local> Message-ID: On Thu, 1 Nov 2012, Damien Miller wrote: > > > This is a risk of using > > > the target user for the login script, which is something we explicitly > > > recommend against. > > > > OK, then documentation is quite important: if I understand it > > right, the default will be this unsafe mode, unless one uses > > AuthorizedKeysCommandUser > > yes, though "unsafe" is relative here. It would be nice to have a dedicated > _ssh_helper account or somesuch that we could rely on to be the default. > > Perhaps it would be better to ship with no default whatsoever but support > %u as an option. I just committed this - there is no default AuthorizedKeysCommandUser now; admins are required to specify one. Hopefully they'll pick a good one :) -d From djm at mindrot.org Mon Nov 5 12:28:52 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Nov 2012 12:28:52 +1100 (EST) Subject: Unix socket forwarding In-Reply-To: <20120305194405.GA702@wilbur.25thandClement.com> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> Message-ID: thread, rise from your grave! On Mon, 5 Mar 2012, William Ahern wrote: > If there's real interest by the team to accept the feature, I'd be happy to > update my patch and workout any integration issues and misgivings. But for > years there's been nothing but stone cold silence concerning this feature. Hi, I've finally found some time to work though long-standing feature requests (so far: authorized_keys from a command, multiple required authentication), and I'd like to take a proper look at Unix domain socket forwarding. Is there a more current patch than the one on your website available? I'd like to see if I can get it in for 6.2 if possible. -d From lars at public.noschinski.de Wed Nov 7 03:04:36 2012 From: lars at public.noschinski.de (Lars Noschinski) Date: Tue, 6 Nov 2012 17:04:36 +0100 Subject: Semantics of known_hosts file Message-ID: <20121106160436.GA3037@lars.home.noschinski.de> Hi everyone, I am trying to get Debian bug #668239 [1] resolved, which is concerned with the way paramiko (a SSH implementation in Python) deals with OpenSSH's known_hosts file when non-standard ports are used. Hence, I want to make sure that I correctly understand OpenSSH's behaviour. If this is not a topic for this list, please point me to a more appropriate list. As far as I can gather from readin sshd(8) and the source code (get_hostfile_hostname_ipaddr), at most two key lookups are performed: (a) [Only for protocol version 1] One for the ip address of the remote host, with put_host_port(ntop, port) (b) One for the hostname. (1) If it is an HostKeyAlias, just look for the hostname, (2) else for put_host_port(hostname, port). Is this an accurate description? In the bugzilla entry #910 [2], I found that a fallback option (look for hostname only, if (b.2) fails) was discussed, but if I understand it correctly, this never was included. Best regards, Lars Noschinski [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668239 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=910 From yxejamir at gmail.com Wed Nov 7 21:52:07 2012 From: yxejamir at gmail.com (Amir Yalon) Date: Wed, 7 Nov 2012 12:52:07 +0200 Subject: ssh-copy-id usability improvement Message-ID: Hi, I had trouble recently with using the ssh-copy-id -i switch (in portable OpenSSH?s contrib/), where it told me that ?no identities found?, while I the file existed and contained a valid public key text line. The problem was, that the file was named something.key in stead of something.pub, and the script tried to read the non-existent something.key.pub. The two small patches below fix that, by checking that something.key.pub exists before adding the .pub suffix to something.key. Feedback is welcome, of course. Regards, Amir commit 2b739db206d2bce48e3a52dd269c2a2bb641e55d Author: Amir Yalon Date: Wed Nov 7 12:26:23 2012 +0200 ssh-copy-id: enable suffix other than .pub in argument to -i diff --git a/contrib/ssh-copy-id b/contrib/ssh-copy-id index 9451ace..15a1646 100644 --- a/contrib/ssh-copy-id +++ b/contrib/ssh-copy-id @@ -11,10 +11,10 @@ if [ "-i" = "$1" ]; then shift # check if we have 2 parameters left, if so the first is the new ID file if [ -n "$2" ]; then - if expr "$1" : ".*\.pub" > /dev/null ; then - ID_FILE="$1" - else + if [ -f "$1.pub" ]; then ID_FILE="$1.pub" + else + ID_FILE="$1" fi shift # and this should leave $1 as the target name fi And also a patch for the proposed new ssh-copy-id script at http://git.hands.com/ssh-copy-id: commit ff8993ba2cefbb28b4648d643a73f01fec64617c Author: Amir Yalon Date: Wed Nov 7 12:44:40 2012 +0200 Enable suffix other than .pub in argument to -i diff --git a/ssh-copy-id b/ssh-copy-id index 8cdad28..efa0d29 100755 --- a/ssh-copy-id +++ b/ssh-copy-id @@ -23,10 +23,10 @@ usage () { use_id_file() { local L_ID_FILE=$1 - if expr "$L_ID_FILE" : ".*\.pub$" >/dev/null ; then - PUB_ID_FILE="$L_ID_FILE" - else + if [ -f "$L_ID_FILE.pub" ]; then PUB_ID_FILE="$L_ID_FILE.pub" + else + PUB_ID_FILE="$L_ID_FILE" fi PRIV_ID_FILE=$(dirname "$PUB_ID_FILE")/$(basename "$PUB_ID_FILE" .pub) From ras at anzio.com Thu Nov 8 06:28:26 2012 From: ras at anzio.com (Bob Rasmussen) Date: Wed, 7 Nov 2012 11:28:26 -0800 (PST) Subject: Timing of banner In-Reply-To: <4E0E2505.8070307@fifthhorseman.net> References: <4E0E2505.8070307@fifthhorseman.net> Message-ID: I'd like to revisit this issue, as it has come up from another customer. The Issue: the customer (and their lawyers) would like to issue a banner to be displayed to a user BEFORE the user attempts to authenticate to the customer's server. This may be a legal disclaimer, terms and conditions, or whatever. The current design of sshd prevents this, and will issue a banner only after the user has sent a username. Earlier responses: One was that the current design allows different banners on a per-user basis. Perhaps that's important. Other responses had to do with security implications. I think those are not relevant to the issue. The spec: RFC4252, section 5.4, includes these statements: "In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection." "This message contains text to be displayed to the client user before authentication is attempted." Note *before*. I would argue that the current implementation does not comply with the standard. One possible compromise would be to have a config switch to control sending the "issue" (such as /etc/issue) if it exists. Please consider making this change. On Fri, 1 Jul 2011, Daniel Kahn Gillmor wrote: > On 07/01/2011 03:20 PM, Bob Rasmussen wrote: > > My user's point has a certain validity, I think: the user isn't seeing > > what they're logging into before giving a username. One might even > > consider it a security issue, identifying yourself before you know who > > you're talking to (although I realize the fingerprint verification > > mitigates this). > > From a security standpoint, the fingerprint verification doesn't just > mitigate this; it is the *only* thing that addresses this security > concern. Reliance on a trivially replayable banner for identifying the > host would be an insecure practice. > > i haven't thought through the rest of the tradeoffs (there may well be a > case to be made for an earlier banner in the opening > handshake/negotiation); i just wanted to be clear that the argument by > security (for users to identify the host) is flawed. > > --dkg > > Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From keisial at gmail.com Thu Nov 8 08:28:45 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 07 Nov 2012 22:28:45 +0100 Subject: Timing of banner In-Reply-To: References: <4E0E2505.8070307@fifthhorseman.net> Message-ID: <509AD28D.6050608@gmail.com> On 07/11/12 20:28, Bob Rasmussen wrote: > I'd like to revisit this issue, as it has come up from another customer. > > The Issue: the customer (and their lawyers) would like to issue a banner > to be displayed to a user BEFORE the user attempts to authenticate to the > customer's server. This may be a legal disclaimer, terms and conditions, > or whatever. The current design of sshd prevents this, and will issue a > banner only after the user has sent a username. > > Earlier responses: One was that the current design allows different > banners on a per-user basis. Perhaps that's important. Other responses had > to do with security implications. I think those are not relevant to the > issue. > > The spec: RFC4252, section 5.4, includes these statements: > > "In some jurisdictions, sending a warning message before > authentication may be relevant for getting legal protection." > > "This message contains text to be displayed to the client user before > authentication is attempted." Note *before*. > > I would argue that the current implementation does not comply with the > standard. > > One possible compromise would be to have a config switch to control > sending the "issue" (such as /etc/issue) if it exists. > > Please consider making this change. If you are willing to patch your openssh, I think the change is as simple as adding on the top of sshd_exchange_identification (about line 409 of sshd.c) #define MESSAGE "Whatever text you want to send, encoded in ISO-10646 UTF-8" if (roaming_atomicio(vwrite, sock_out, MESSAGE "\r\n", sizeof(MESSAGE) + 1) != sizeof(MESSAGE) + 1) { logit("Could not sent legalese to %s", get_remote_ipaddr()); cleanup_exit(255); } It is up to the client to show or ignore the message, but all clients must be able to cope with them (rfc4253 4.2). You can't send the banner any earlier. As an alternative to patching ssh, you could run sshd from inetd, and use a shell script wrapper which simply outputs your banner before passing control to sshd. From phil at hands.com Thu Nov 8 21:58:07 2012 From: phil at hands.com (Philip Hands) Date: Thu, 08 Nov 2012 10:58:07 +0000 Subject: ssh-copy-id usability improvement In-Reply-To: References: Message-ID: <87625g4b0g.fsf@poker.hands.com> Amir Yalon writes: > Hi, Hi Amir, > I had trouble recently with using the ssh-copy-id -i switch (in > portable OpenSSH?s contrib/), where it told me that ?no identities > found?, while I the file existed and contained a valid public key text > line. The problem was, that the file was named something.key in stead > of something.pub, and the script tried to read the non-existent > something.key.pub. > > The two small patches below fix that, by checking that > something.key.pub exists before adding the .pub suffix to > something.key. Feedback is welcome, of course. The advantage of the current approach is that it will only publish a file to another server if it has the .pub suffix. With your patch, I see the very slight possibility that one might manage to lose the .pub file for a key, and then end up mistakenly using ssh-copy-id to push a copy of your private key out. Given that one can fix the problem you had by adding a symlink: something.key.pub --> something.key I would think that the problem that perhaps needs fixing is that the error message you were given could probably have been more helpful. BTW I have a more up to date version of ssh-copy-id here: http://git.hands.com/ssh-copy-id which checks that the key you specified is loadable before bothering to push the .pub, which will work even less well for your scenario I'm afraid, as it will not be able to work out the name of the private key. If you can see a useful way of making this work for you, feel free to suggest it, or clone the git and send me a patch or the URL for your git once you have a patch. Cheers, Phil. P.S. regarding my previous attempt to get my version of ssh-copy-id adopted for the ssh contrib dir, I note that I dropped the ball on this bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1980 I've now fixed the ${1%:} problem, so I'll update the bug and perhaps we can get the new version into ssh's contrib. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From lists at eitanadler.com Mon Nov 12 03:45:42 2012 From: lists at eitanadler.com (Eitan Adler) Date: Sun, 11 Nov 2012 11:45:42 -0500 Subject: improved ssh-copy-id Message-ID: Hey all, The attached copy of ssh-copy-id has support for ssh's -o options as well as a -p option for the port. I opted to write this cleanroom because at the time I didn't know the origin of the ssh-copy-id script and wasn't sure of license concerns. Comments / Suggestions welcome. -- Eitan Adler -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-copy-id.sh Type: application/x-sh Size: 2629 bytes Desc: not available URL: From djm at mindrot.org Mon Nov 12 18:00:33 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2012 18:00:33 +1100 (EST) Subject: improved ssh-copy-id In-Reply-To: References: Message-ID: On Sun, 11 Nov 2012, Eitan Adler wrote: > Hey all, > > The attached copy of ssh-copy-id has support for ssh's -o options as > well as a -p option for the port. I opted to write this cleanroom > because at the time I didn't know the origin of the ssh-copy-id script > and wasn't sure of license concerns. I'd rather you coordinate with Phil Hands via https://bugzilla.mindrot.org/show_bug.cgi?id=1980 My plan is to update our copy of ssh-copy-id to his git sometime soon. If you have changes to make, then it's best to discuss them in the bug. Cheers, Damien From landry at openbsd.org Wed Nov 14 07:38:58 2012 From: landry at openbsd.org (Landry Breuil) Date: Tue, 13 Nov 2012 21:38:58 +0100 Subject: problem with AuthorizedKeysCommand on OpenBSD In-Reply-To: <20121113203428.GA1303@bewilderbeast.blackhelicopters.org> References: <20121113203428.GA1303@bewilderbeast.blackhelicopters.org> Message-ID: <20121113203858.GJ14865@dawn.rhaalovely.net> On Tue, Nov 13, 2012 at 03:34:28PM -0500, Michael W. Lucas wrote: > Hi, > > I'm attempting to test the AuthorizedKeysCommand feature with the new > port of ssh-ldap-wrapper to OpenBSD. I'm running yesterday's > OpenBSD-current i386 snapshot, which includes AuthorizedKeysCommand. > > The port of ssh-ldap-helper (at > http://old.nabble.com/-new--ssh-ldap-helper-td34667413.html) contains > all the bits I need, and the individual pieces appear to work once > configured: > > # sudo -u nobody /usr/local/libexec/ssh-ldap-wrapper mwlucas > ssh-rsa AAAAB3NzaC1yc... > > ssh-rsa AAAAB3NzaC1yc2EA... > > (Two keys come out, with a blank line between them) > > My sshd_config has: > > AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper > AuthorizedKeysCommandUser nobody > > (Yes, a user other than nobody will go into production, but I'm just > trying to make the blasted thing work right now.) > > The keys don't seem to be making it to the SSH server, however. Run > with debugging, I get: > > ... > debug3: mm_request_receive entering > debug3: monitor_read: checking request 20 > debug3: mm_answer_keyallowed entering > debug3: mm_answer_keyallowed: key_from_blob: 0x81973440 > debug1: temporarily_use_uid: 32767/32767 (e=0/0) > debug3: Running AuthorizedKeysCommand: "/usr/local/libexec/ssh-ldap-wrapper" as "nobody" > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 32767/32767 (e=0/0) > debug2: key not found > user_key_command_allowed2: dup2: Bad file descriptor > AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper returned status 1 > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 1000/1000 (e=0/0) > ... > > > Any suggestions, folks? I was testing it on my shellbox, and i'm stuck at the exact same problem. dup2() on the child's stdout returns EBADF. same if AuthorizedKeysCommandUser is root. Landry From landry at openbsd.org Wed Nov 14 08:21:27 2012 From: landry at openbsd.org (Landry Breuil) Date: Tue, 13 Nov 2012 22:21:27 +0100 Subject: problem with AuthorizedKeysCommand on OpenBSD In-Reply-To: <20121113203858.GJ14865@dawn.rhaalovely.net> References: <20121113203428.GA1303@bewilderbeast.blackhelicopters.org> <20121113203858.GJ14865@dawn.rhaalovely.net> Message-ID: <20121113212127.GL14865@dawn.rhaalovely.net> On Tue, Nov 13, 2012 at 09:38:58PM +0100, Landry Breuil wrote: > On Tue, Nov 13, 2012 at 03:34:28PM -0500, Michael W. Lucas wrote: > > Hi, > > > > I'm attempting to test the AuthorizedKeysCommand feature with the new > > port of ssh-ldap-wrapper to OpenBSD. I'm running yesterday's > > OpenBSD-current i386 snapshot, which includes AuthorizedKeysCommand. > > > > The port of ssh-ldap-helper (at > > http://old.nabble.com/-new--ssh-ldap-helper-td34667413.html) contains > > all the bits I need, and the individual pieces appear to work once > > configured: > > > > # sudo -u nobody /usr/local/libexec/ssh-ldap-wrapper mwlucas > > ssh-rsa AAAAB3NzaC1yc... > > > > ssh-rsa AAAAB3NzaC1yc2EA... > > > > (Two keys come out, with a blank line between them) > > > > My sshd_config has: > > > > AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper > > AuthorizedKeysCommandUser nobody > > > > (Yes, a user other than nobody will go into production, but I'm just > > trying to make the blasted thing work right now.) > > > > The keys don't seem to be making it to the SSH server, however. Run > > with debugging, I get: > > > > ... > > debug3: mm_request_receive entering > > debug3: monitor_read: checking request 20 > > debug3: mm_answer_keyallowed entering > > debug3: mm_answer_keyallowed: key_from_blob: 0x81973440 > > debug1: temporarily_use_uid: 32767/32767 (e=0/0) > > debug3: Running AuthorizedKeysCommand: "/usr/local/libexec/ssh-ldap-wrapper" as "nobody" > > debug1: restore_uid: 0/0 > > debug1: temporarily_use_uid: 32767/32767 (e=0/0) > > debug2: key not found > > user_key_command_allowed2: dup2: Bad file descriptor > > AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper returned status 1 > > debug1: restore_uid: 0/0 > > debug1: temporarily_use_uid: 1000/1000 (e=0/0) > > ... > > > > > > Any suggestions, folks? > > I was testing it on my shellbox, and i'm stuck at the exact same > problem. dup2() on the child's stdout returns EBADF. same if > AuthorizedKeysCommandUser is root. After examinining the code in user_key_command_allowed2(), i've noted a strange thing (which doesnt explain the EBADF on dup2(p[1], STDOUT_FILENO)) : If AuthorizedKeysCommandUser is say, nobody, then pw->pw_name (3rd arg of execl()) is 'nobody' when spawning the helper command (line 550 of auth2-pubkey.c), shouldnt it be user_pw->pw_name ? It works by accident if AuthorizedKeysCommandUser is %u, in that case user_pw == pw, otherwise the wrong username might be passed to the helper command. So should that diff apply ? diff -u -r1.32 auth2-pubkey.c --- auth2-pubkey.c 4 Nov 2012 10:38:43 -0000 1.32 +++ auth2-pubkey.c 13 Nov 2012 21:16:53 -0000 @@ -547,7 +547,7 @@ } execl(options.authorized_keys_command, - options.authorized_keys_command, pw->pw_name, NULL); + options.authorized_keys_command, user_pw->pw_name, NULL); Also tried with UsePrivilegeSeparation yes to avoid using the sandbox, same EBADF issue. Landry From mwlucas at michaelwlucas.com Wed Nov 14 07:34:28 2012 From: mwlucas at michaelwlucas.com (Michael W. Lucas) Date: Tue, 13 Nov 2012 15:34:28 -0500 Subject: problem with AuthorizedKeysCommand on OpenBSD Message-ID: <20121113203428.GA1303@bewilderbeast.blackhelicopters.org> Hi, I'm attempting to test the AuthorizedKeysCommand feature with the new port of ssh-ldap-wrapper to OpenBSD. I'm running yesterday's OpenBSD-current i386 snapshot, which includes AuthorizedKeysCommand. The port of ssh-ldap-helper (at http://old.nabble.com/-new--ssh-ldap-helper-td34667413.html) contains all the bits I need, and the individual pieces appear to work once configured: # sudo -u nobody /usr/local/libexec/ssh-ldap-wrapper mwlucas ssh-rsa AAAAB3NzaC1yc... ssh-rsa AAAAB3NzaC1yc2EA... (Two keys come out, with a blank line between them) My sshd_config has: AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper AuthorizedKeysCommandUser nobody (Yes, a user other than nobody will go into production, but I'm just trying to make the blasted thing work right now.) The keys don't seem to be making it to the SSH server, however. Run with debugging, I get: ... debug3: mm_request_receive entering debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x81973440 debug1: temporarily_use_uid: 32767/32767 (e=0/0) debug3: Running AuthorizedKeysCommand: "/usr/local/libexec/ssh-ldap-wrapper" as "nobody" debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 32767/32767 (e=0/0) debug2: key not found user_key_command_allowed2: dup2: Bad file descriptor AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper returned status 1 debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) ... Any suggestions, folks? Thanks, ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery mwlucas at michaelwlucas.com, Twitter @mwlauthor From landry at openbsd.org Wed Nov 14 08:47:00 2012 From: landry at openbsd.org (Landry Breuil) Date: Tue, 13 Nov 2012 22:47:00 +0100 Subject: problem with AuthorizedKeysCommand on OpenBSD In-Reply-To: <20121113212127.GL14865@dawn.rhaalovely.net> References: <20121113203428.GA1303@bewilderbeast.blackhelicopters.org> <20121113203858.GJ14865@dawn.rhaalovely.net> <20121113212127.GL14865@dawn.rhaalovely.net> Message-ID: <20121113214700.GM14865@dawn.rhaalovely.net> On Tue, Nov 13, 2012 at 10:21:27PM +0100, Landry Breuil wrote: > On Tue, Nov 13, 2012 at 09:38:58PM +0100, Landry Breuil wrote: > > On Tue, Nov 13, 2012 at 03:34:28PM -0500, Michael W. Lucas wrote: > > > Hi, > > > > > > I'm attempting to test the AuthorizedKeysCommand feature with the new > > > port of ssh-ldap-wrapper to OpenBSD. I'm running yesterday's > > > OpenBSD-current i386 snapshot, which includes AuthorizedKeysCommand. > > > > > > The port of ssh-ldap-helper (at > > > http://old.nabble.com/-new--ssh-ldap-helper-td34667413.html) contains > > > all the bits I need, and the individual pieces appear to work once > > > configured: > > > > > > # sudo -u nobody /usr/local/libexec/ssh-ldap-wrapper mwlucas > > > ssh-rsa AAAAB3NzaC1yc... > > > > > > ssh-rsa AAAAB3NzaC1yc2EA... > > > > > > (Two keys come out, with a blank line between them) > > > > > > My sshd_config has: > > > > > > AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper > > > AuthorizedKeysCommandUser nobody > > > > > > (Yes, a user other than nobody will go into production, but I'm just > > > trying to make the blasted thing work right now.) > > > > > > The keys don't seem to be making it to the SSH server, however. Run > > > with debugging, I get: > > > > > > ... > > > debug3: mm_request_receive entering > > > debug3: monitor_read: checking request 20 > > > debug3: mm_answer_keyallowed entering > > > debug3: mm_answer_keyallowed: key_from_blob: 0x81973440 > > > debug1: temporarily_use_uid: 32767/32767 (e=0/0) > > > debug3: Running AuthorizedKeysCommand: "/usr/local/libexec/ssh-ldap-wrapper" as "nobody" > > > debug1: restore_uid: 0/0 > > > debug1: temporarily_use_uid: 32767/32767 (e=0/0) > > > debug2: key not found > > > user_key_command_allowed2: dup2: Bad file descriptor > > > AuthorizedKeysCommand /usr/local/libexec/ssh-ldap-wrapper returned status 1 > > > debug1: restore_uid: 0/0 > > > debug1: temporarily_use_uid: 1000/1000 (e=0/0) > > > ... > > > > > > > > > Any suggestions, folks? > > > > I was testing it on my shellbox, and i'm stuck at the exact same > > problem. dup2() on the child's stdout returns EBADF. same if > > AuthorizedKeysCommandUser is root. > > After examinining the code in user_key_command_allowed2(), i've noted > a strange thing (which doesnt explain the EBADF on dup2(p[1], > STDOUT_FILENO)) : > > If AuthorizedKeysCommandUser is say, nobody, then pw->pw_name (3rd arg > of execl()) is 'nobody' when spawning the helper command (line 550 of > auth2-pubkey.c), shouldnt it be user_pw->pw_name ? It works by accident > if AuthorizedKeysCommandUser is %u, in that case user_pw == pw, > otherwise the wrong username might be passed to the helper command. > > So should that diff apply ? > diff -u -r1.32 auth2-pubkey.c > --- auth2-pubkey.c 4 Nov 2012 10:38:43 -0000 1.32 > +++ auth2-pubkey.c 13 Nov 2012 21:16:53 -0000 > @@ -547,7 +547,7 @@ > } > > execl(options.authorized_keys_command, > - options.authorized_keys_command, pw->pw_name, NULL); > + options.authorized_keys_command, user_pw->pw_name, NULL); > > Also tried with UsePrivilegeSeparation yes to avoid using the sandbox, > same EBADF issue. And i think i've found the cause of the issue; closefrom(STDERR_FILENO + 1) line 523 closes both p[0] and p[1], probably explaing the dup2(p[1], STDOUT_FILENO) failure. It was moved before setresgid() call in last commit making AuthorizedKeysCommandUser mandatory, while before it was after the dup2() block. Index: auth2-pubkey.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth2-pubkey.c,v retrieving revision 1.32 diff -u -r1.32 auth2-pubkey.c --- auth2-pubkey.c 4 Nov 2012 10:38:43 -0000 1.32 +++ auth2-pubkey.c 13 Nov 2012 21:40:44 -0000 @@ -520,7 +520,6 @@ for (i = 0; i < NSIG; i++) signal(i, SIG_DFL); - closefrom(STDERR_FILENO + 1); /* Don't use permanently_set_uid() here to avoid fatal() */ if (setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) != 0) { error("setresgid %u: %s", (u_int)pw->pw_gid, @@ -545,9 +544,10 @@ error("%s: dup2: %s", __func__, strerror(errno)); _exit(1); } + closefrom(STDERR_FILENO + 1); execl(options.authorized_keys_command, - options.authorized_keys_command, pw->pw_name, NULL); + options.authorized_keys_command, user_pw->pw_name, NULL); error("AuthorizedKeysCommand %s exec failed: %s", options.authorized_keys_command, strerror(errno)); fixes both issues for me. Working with %u or nobody in AuthorizedKeysCommandUser. looking for okays to commit that, if that looks sane. Landry From djm at mindrot.org Wed Nov 14 13:21:24 2012 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Nov 2012 13:21:24 +1100 (EST) Subject: problem with AuthorizedKeysCommand on OpenBSD In-Reply-To: <20121113212127.GL14865@dawn.rhaalovely.net> References: <20121113203428.GA1303@bewilderbeast.blackhelicopters.org> <20121113203858.GJ14865@dawn.rhaalovely.net> <20121113212127.GL14865@dawn.rhaalovely.net> Message-ID: On Tue, 13 Nov 2012, Landry Breuil wrote: > After examinining the code in user_key_command_allowed2(), i've noted > a strange thing (which doesnt explain the EBADF on dup2(p[1], > STDOUT_FILENO)) : It's the closefrom() that I moved without properly retesting :( Here's a diff: diff --git auth2-pubkey.c auth2-pubkey.c index aa197aa..0a7161a 100644 --- auth2-pubkey.c +++ auth2-pubkey.c @@ -501,8 +501,8 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key) goto out; } - debug3("Running AuthorizedKeysCommand: \"%s\" as \"%s\"", - options.authorized_keys_command, pw->pw_name); + debug3("Running AuthorizedKeysCommand: \"%s %s\" as \"%s\"", + options.authorized_keys_command, user_pw->pw_name, pw->pw_name); /* * Don't want to call this in the child, where it can fatal() and @@ -520,7 +520,19 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key) for (i = 0; i < NSIG; i++) signal(i, SIG_DFL); + if ((devnull = open(_PATH_DEVNULL, O_RDWR)) == -1) { + error("%s: open %s: %s", __func__, _PATH_DEVNULL, + strerror(errno)); + _exit(1); + } + /* Keep stderr around a while longer to catch errors */ + if (dup2(devnull, STDIN_FILENO) == -1 || + dup2(p[1], STDOUT_FILENO) == -1) { + error("%s: dup2: %s", __func__, strerror(errno)); + _exit(1); + } closefrom(STDERR_FILENO + 1); + /* Don't use permanently_set_uid() here to avoid fatal() */ if (setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) != 0) { error("setresgid %u: %s", (u_int)pw->pw_gid, @@ -532,22 +544,14 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key) strerror(errno)); _exit(1); } - - close(p[0]); - if ((devnull = open(_PATH_DEVNULL, O_RDWR)) == -1) { - error("%s: open %s: %s", __func__, _PATH_DEVNULL, - strerror(errno)); - _exit(1); - } - if (dup2(devnull, STDIN_FILENO) == -1 || - dup2(p[1], STDOUT_FILENO) == -1 || - dup2(devnull, STDERR_FILENO) == -1) { + /* stdin is pointed to /dev/null at this point */ + if (dup2(STDIN_FILENO, STDERR_FILENO) == -1) { error("%s: dup2: %s", __func__, strerror(errno)); _exit(1); } execl(options.authorized_keys_command, - options.authorized_keys_command, pw->pw_name, NULL); + options.authorized_keys_command, user_pw->pw_name, NULL); error("AuthorizedKeysCommand %s exec failed: %s", options.authorized_keys_command, strerror(errno)); From phil at hands.com Thu Nov 15 22:39:37 2012 From: phil at hands.com (Philip Hands) Date: Thu, 15 Nov 2012 11:39:37 +0000 Subject: improved ssh-copy-id In-Reply-To: References: Message-ID: <87pq3fyu12.fsf@poker.hands.com> Damien Miller writes: ... > I'd rather you coordinate with Phil Hands via > https://bugzilla.mindrot.org/show_bug.cgi?id=1980 > > My plan is to update our copy of ssh-copy-id to his git sometime soon. If > you have changes to make, then it's best to discuss them in the bug. Hi Damien, That's good to hear :-) Eitan, You'll note that my version (http://git.hands.com/ssh-copy-id) already includes the -p option. The -o option seems reasonable, although I'd quite like to know what you use it for, as I personally would always put the options into my .ssh/config because I'm not into typing long command lines. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From lists at eitanadler.com Fri Nov 16 05:32:45 2012 From: lists at eitanadler.com (Eitan Adler) Date: Thu, 15 Nov 2012 13:32:45 -0500 Subject: improved ssh-copy-id In-Reply-To: <87pq3fyu12.fsf@poker.hands.com> References: <87pq3fyu12.fsf@poker.hands.com> Message-ID: On 15 November 2012 06:39, Philip Hands wrote: > Damien Miller writes: > ... >> I'd rather you coordinate with Phil Hands via >> https://bugzilla.mindrot.org/show_bug.cgi?id=1980 >> >> My plan is to update our copy of ssh-copy-id to his git sometime soon. If >> you have changes to make, then it's best to discuss them in the bug. > > Hi Damien, > > That's good to hear :-) > > Eitan, > > You'll note that my version (http://git.hands.com/ssh-copy-id) already > includes the -p option. The -o option seems reasonable, although I'd > quite like to know what you use it for, as I personally would always put > the options into my .ssh/config because I'm not into typing long command > lines. I usually use it to either disable the ControlMaster temporarily or to reduce the strictness of some of the tests (StrictHostKeyChecking). It isn't critical for ssh-copy-id. In any case I think your version had more features so there isn't any reason to use this version. I had just written before becoming aware of the origin of s-c-i. -- Eitan Adler From lars.schade at berlin.de Mon Nov 19 04:05:23 2012 From: lars.schade at berlin.de (Lars Schade) Date: Sun, 18 Nov 2012 18:05:23 +0100 Subject: sftp authentication failure only as cronjob Message-ID: <1353258323.2602.13.camel@rosinante.berlin> Hi all, my problem with the sftp connection run as cron job is finally solved. As in most cases the problem sits in front of the computer. My script ran fine from the command line in my gnome session because the ssh-agent provided the password for the private key in the background. When run by the cron daemon the ssh-agent is not started and the prompt for the password is for some reason not explicitly visible even in the verbose log. So I simply removed the password from the key and now the script runs fine even as cron job. PS: On the other machine things worked fine right away because there the keys were not password protected to begin with. Sorry to have bothered you, this was just a bit tricky to diagnose. Regards, Lars From nkadel at gmail.com Mon Nov 19 06:42:13 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 18 Nov 2012 14:42:13 -0500 Subject: sftp authentication failure only as cronjob In-Reply-To: <1353258323.2602.13.camel@rosinante.berlin> References: <1353258323.2602.13.camel@rosinante.berlin> Message-ID: On Sun, Nov 18, 2012 at 12:05 PM, Lars Schade wrote: > Hi all, > > my problem with the sftp connection run as cron job is finally solved. > As in most cases the problem sits in front of the computer. > > My script ran fine from the command line in my gnome session because the > ssh-agent provided the password for the private key in the background. > When run by the cron daemon the ssh-agent is not started and the prompt > for the password is for some reason not explicitly visible even in the > verbose log. So I simply removed the password from the key and now the > script runs fine even as cron job. And you now have a non-passphrase protected key that can be stolen and used. The level of security of this approach is like putting a key to your front door in your mailbox. If you really trust your environment, it might be tolerable, but if it's in your $HOME/.ssh/id_dsa,, and it's usable for shell logins. The risks are enhanced by the common use of unsecured, NFS mounted home directories and poor security of backup tapes. > PS: On the other machine things worked fine right away because there the > keys were not password protected to begin with. **Ouch*. Look, this is a longstanding security issue with most SSH clients. You can reduce the risk somewhat by using a non-standard key location, by making sure it's only on a local disk and not backup tapes or NFS storage, or by using wrappers like the "keychain" perl script that stores the SSH_AUTH_SOCK settings in a text file that can be sourced by other scripts. You can also use the "force-command" in the published authorized_keys file settings to restrict the permitted operations. > Sorry to have bothered you, this was just a bit tricky to diagnose. And I'm afraid that you've used a common approach that is the first thing you'll find with a Google search, but has some really fundamental risks. The fastest approach is probably to use the "keychain" Perl script to make the keys accessible if and only if needed. From Malo.Marie at hydro.qc.ca Wed Nov 21 03:34:50 2012 From: Malo.Marie at hydro.qc.ca (Malo.Marie at hydro.qc.ca) Date: Tue, 20 Nov 2012 11:34:50 -0500 Subject: =?iso-8859-1?Q?Traduction_d=27un_terme_demand=E9e?= Message-ID: Bonjour, On m'a demand? de trouver le terme fran?ais pour jump server ou jump host tel que d?fini dans cet article de Wikipedia : http://en.wikipedia.org/wiki/Jump_host. Mille mercis pour votre aide, Marie Malo Terminologue Direction principale - Environnement et affaires corporatives T?l. : 514 289-2211, poste 4018 malo.marie at hydro.qc.ca From g.esp at free.fr Wed Nov 21 04:35:23 2012 From: g.esp at free.fr (g.esp at free.fr) Date: Tue, 20 Nov 2012 18:35:23 +0100 (CET) Subject: =?utf-8?Q?Re:_Traduction_d'un_terme_demand=C3=A9e?= In-Reply-To: Message-ID: <1953438927.56910708.1353432923219.JavaMail.root@zimbra33-e6.priv.proxad.net> ----- Mail original ----- > De: "Malo Marie" > ?: openssh-unix-dev at mindrot.org > Envoy?: Mardi 20 Novembre 2012 17:34:50 > Objet: Traduction d'un terme demand?e > > Bonjour, > > On m'a demand? de trouver le terme fran?ais pour jump server ou jump > host tel que d?fini dans cet article de Wikipedia : > http://en.wikipedia.org/wiki/Jump_host. > serveur de rebond? http://wiki.ouitech.fr/doku.php/tutoriels/gnu_linux/general/creer_un_serveur_de_rebont_ssh Gilles From arif at mail.nih.gov Wed Nov 21 06:51:36 2012 From: arif at mail.nih.gov (Anthony R Fletcher) Date: Tue, 20 Nov 2012 14:51:36 -0500 Subject: Connection info with AuthorizedKeysCommand Message-ID: <20121120195136.GA31621@cosy.cit.nih.gov> I see that support for AuthorizedKeysCommand has been added. The arguments supplied to the command is just the authenticating user. Can we add the SSH connection details (ie. source and destination IPs and ports) as well? This command seems to be the idea way of requiring one set of credentials from inside an organisation (say the user's own authorized_keys file) and another set from outside (say 2 factor smart card keys). To do this the command needs to know where the connection is coming from. I can see a similar reason for knowing the destination IP or port. We could use a cumbersome Match statement, but why not make all the information available to the AuthorizedKeysCommand command? Anthony From keisial at gmail.com Wed Nov 21 08:37:49 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 20 Nov 2012 22:37:49 +0100 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121120195136.GA31621@cosy.cit.nih.gov> References: <20121120195136.GA31621@cosy.cit.nih.gov> Message-ID: <50ABF82D.4090508@gmail.com> On 20/11/12 20:51, Anthony R Fletcher wrote: > I see that support for AuthorizedKeysCommand has been added. The > arguments supplied to the command is just the authenticating user. Can > we add the SSH connection details (ie. source and destination IPs and > ports) as well? > > This command seems to be the idea way of requiring one set of > credentials from inside an organisation (say the user's own > authorized_keys file) and another set from outside (say 2 factor smart > card keys). > > To do this the command needs to know where the connection is coming > from. I can see a similar reason for knowing the destination IP or port. > > We could use a cumbersome Match statement, but why not make all the > information available to the AuthorizedKeysCommand command? Maybe it should get the environment variable SSH_CONNECTION that is sent on a ssh session. (the deprecated SSH_CLIENT is a subset, so no need to expose that) From peter at stuge.se Wed Nov 21 09:06:33 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 20 Nov 2012 23:06:33 +0100 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <50ABF82D.4090508@gmail.com> References: <20121120195136.GA31621@cosy.cit.nih.gov> <50ABF82D.4090508@gmail.com> Message-ID: <20121120220633.6394.qmail@stuge.se> ?ngel Gonz?lez wrote: > > why not make all the information available to the > > AuthorizedKeysCommand command? > > Maybe it should get the environment variable SSH_CONNECTION that > is sent on a ssh session. What would a patch look like? //Peter From scott_n at xypro.com Wed Nov 21 09:19:44 2012 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 20 Nov 2012 14:19:44 -0800 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121120220633.6394.qmail@stuge.se> References: <20121120195136.GA31621@cosy.cit.nih.gov> <50ABF82D.4090508@gmail.com> <20121120220633.6394.qmail@stuge.se> Message-ID: <78DD71C304F38B41885A242996B96F7303ECF8A6@xyservd.XYPRO-23.LOCAL> > -----Original Message----- > From: openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org > [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On > Behalf Of Peter Stuge > Sent: Tuesday, November 20, 2012 2:07 PM > To: openssh-unix-dev at mindrot.org > Subject: Re: Connection info with AuthorizedKeysCommand > > ?ngel Gonz?lez wrote: > > > why not make all the information available to the > > > AuthorizedKeysCommand command? > > > > Maybe it should get the environment variable SSH_CONNECTION that is > > sent on a ssh session. > > What would a patch look like? [[SAN]] I think the AuthorizedKeysCommand should just read its environment for SSH_CONNECTION. From djm at mindrot.org Wed Nov 21 10:50:56 2012 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Nov 2012 10:50:56 +1100 (EST) Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121120195136.GA31621@cosy.cit.nih.gov> References: <20121120195136.GA31621@cosy.cit.nih.gov> Message-ID: On Tue, 20 Nov 2012, Anthony R Fletcher wrote: > I see that support for AuthorizedKeysCommand has been added. The > arguments supplied to the command is just the authenticating user. Can > we add the SSH connection details (ie. source and destination IPs and > ports) as well? > > This command seems to be the idea way of requiring one set of > credentials from inside an organisation (say the user's own > authorized_keys file) and another set from outside (say 2 factor smart > card keys). > > To do this the command needs to know where the connection is coming > from. I can see a similar reason for knowing the destination IP or port. An AuthorizedKeysCommand can emit lines with from="" phrases to achieve the same effect. Anything that works in authorized_keys works in the output of AuthorizedKeysCommand. > We could use a cumbersome Match statement, but why not make all the > information available to the AuthorizedKeysCommand command? AuthorizedKeysCommand should be as simple as possible, I don't want to burden it with lots of options, especially when the authorized_keys format is quite powerful as it is. -d From peter at stuge.se Wed Nov 21 11:15:51 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 21 Nov 2012 01:15:51 +0100 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: References: <20121120195136.GA31621@cosy.cit.nih.gov> Message-ID: <20121121001551.16222.qmail@stuge.se> Damien Miller wrote: > > why not make all the information available to the > > AuthorizedKeysCommand command? > > AuthorizedKeysCommand should be as simple as possible, I don't want > to burden it with lots of options, especially when the > authorized_keys format is quite powerful as it is. It's about providing the child process information about who is connected. Is SSH_CONNECTION already being set in the child environment? //Peter From highc at us.ibm.com Wed Nov 21 11:18:08 2012 From: highc at us.ibm.com (Chris High) Date: Tue, 20 Nov 2012 19:18:08 -0500 Subject: AUTO: Chris High/Endicott/IBM is out of the office until 07/08/2002. (returning 12/03/2012) Message-ID: I am out of the office until 12/03/2012. Vacation 1/2 day, starting 1pm ET 11/20 Vacation day 11/21 (may attend an SSAE16 crit sit meeting, otherwise not available) US Holiday 11/22 Site Holiday 11/23 Sun: Travel to Schaumberg Ill Nov 25 business, generally not available. Mon-Fri Off site crit sit meeting for SSAE16 9am-9pm. I will do my best to respond, but most items will have to wait until after the crit sit meetings complete and I return to the office Monday Dec 3. Sat: Travel Home, generally not available. (May attend SSAE16 crit sit meeting Sat morn) 11/21 pm - general coverage by Doug Barlett. 11/22 -self - cover - call 720 395 9374 and leave a message. I will return your call w/in one business day. 11/23 - 24 no cover. 11/26-30 -self - cover - call 720 395 9374 and leave a message. I will return your call w/in one business day. Specific issue coverage: Topics related to IAM's picking up of Pre-production ID Provisioning from SSO-SMD - self cover, my backup is also at the SSAE16 meetings. Topics related to the 'Self Enablement of APC' - self cover, my backup on THIS topic is also at the SSAE16 meetings. Questions regard AG sudo deployment, including questions about sudo templates? Sudo Deployment AG/Hartford/IBM, SA & D 'ownership of items' items for L2 SA teams can best be directed to: Jeannie Carlson/Chicago/IBM, Issues requiring immediate management attention may be referred to my manager, Harish Dindigal/Whippany/IBM Note: This is an automated response to your message "openssh-unix-dev Digest, Vol 115, Issue 5" sent on 11/20/2012 17:19:56. This is the only notification you will receive while this person is away. From arif at mail.nih.gov Wed Nov 21 12:52:38 2012 From: arif at mail.nih.gov (Anthony R Fletcher) Date: Tue, 20 Nov 2012 20:52:38 -0500 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: Message-ID: <20121121015238.GA25294@cosy.cit.nih.gov> <20121121001551.16222.qmail at stuge.se> On 21 Nov 2012 at 01:15:51, Peter Stuge wrote: > It's about providing the child process information about who is > connected. Is SSH_CONNECTION already being set in the child > environment? Sadly the environment contains very little and not SSH_CONNECTION. I just checked with openssh-SNAP-20121121. On 21 Nov 2012 at 10:50:56, Damien Miller wrote: > An AuthorizedKeysCommand can emit lines with from="" phrases to > achieve the same effect. Anything that works in authorized_keys works > in the output of AuthorizedKeysCommand. Excellent idea; I can make it work with that. Thanks. > > We could use a cumbersome Match statement, but why not make all the > > information available to the AuthorizedKeysCommand command? > > AuthorizedKeysCommand should be as simple as possible, I don't want to > burden it with lots of options, especially when the authorized_keys format > is quite powerful as it is. Agreed and I forgot that there was lots of power in the authorized_file format. What if we wanted the authorisation keys to depend on the server port? Anthony. -- Anthony R Fletcher Room 2033, Building 12A, http://dcb.cit.nih.gov/~arif National Institutes of Health, arif at mail.nih.gov 12A South Drive, Bethesda, Phone: (+1) 301 402 1741. MD 20892-5624, USA. From dtucker at zip.com.au Wed Nov 21 13:48:37 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 21 Nov 2012 13:48:37 +1100 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121121015238.GA25294@cosy.cit.nih.gov> References: <20121121015238.GA25294@cosy.cit.nih.gov> Message-ID: <20121121024837.GA8000@gate.dtucker.net> On Tue, Nov 20, 2012 at 08:52:38PM -0500, Anthony R Fletcher wrote: > Agreed and I forgot that there was lots of power in the authorized_file > format. What if we wanted the authorisation keys to depend on the server > port? You can specify different AuthorizedKeysCommand directives inside a "Match Port" block. Not super elegant if you have a lot of them, but for two or three... -- 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 arif at mail.nih.gov Thu Nov 22 01:16:13 2012 From: arif at mail.nih.gov (Anthony R Fletcher) Date: Wed, 21 Nov 2012 09:16:13 -0500 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121121024837.GA8000@gate.dtucker.net> References: <20121121015238.GA25294@cosy.cit.nih.gov> <20121121024837.GA8000@gate.dtucker.net> Message-ID: <20121121141613.GA11407@cosy.cit.nih.gov> On 21 Nov 2012 at 13:48:37, Darren Tucker wrote: > On Tue, Nov 20, 2012 at 08:52:38PM -0500, Anthony R Fletcher wrote: > > Agreed and I forgot that there was lots of power in the authorized_file > > format. What if we wanted the authorisation keys to depend on the server > > port? > > You can specify different AuthorizedKeysCommand directives inside a > "Match Port" block. Not super elegant if you have a lot of them, but > for two or three... > True and I can't see having to run on many ports. Back to my original case of inside and outside sets of authorised keys, I have to process the user's original authorized_keys file. One problem is that the AuthorizedKeysCommand command needs to be able to read that file. This is especially acute when we are using NFS home directories. AuthorizedKeysCommandUser Specifies the user under whose account the AuthorizedKeysCommand is run. It is recommended to use a dedicated user that has no other role on the host than running authorized keys commands. This is a required option when using AuthorizedKeysCommand. Can we have the option to run as the authenticating user? Otherwise I need to use some kind of sudo magic. If I set a extra from= option on each of the user's keys, am I right in thinking that this is an extra restriction and doesn't just overwrite any from= option originally there? Anthony. -- Anthony R Fletcher Room 2033, Building 12A, http://dcb.cit.nih.gov/~arif National Institutes of Health, arif at mail.nih.gov 12A South Drive, Bethesda, Phone: (+1) 301 402 1741. MD 20892-5624, USA. From dkg at fifthhorseman.net Thu Nov 22 02:20:22 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 21 Nov 2012 10:20:22 -0500 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121121141613.GA11407@cosy.cit.nih.gov> References: <20121121015238.GA25294@cosy.cit.nih.gov> <20121121024837.GA8000@gate.dtucker.net> <20121121141613.GA11407@cosy.cit.nih.gov> Message-ID: <50ACF136.1030805@fifthhorseman.net> On 11/21/2012 09:16 AM, Anthony R Fletcher wrote: > AuthorizedKeysCommandUser > Specifies the user under whose account the AuthorizedKeysCommand is > run. It is recommended to use a dedicated user that has no other > role on the host than running authorized keys commands. > > This is a required option when using AuthorizedKeysCommand. > > Can we have the option to run as the authenticating user? Otherwise I > need to use some kind of sudo magic. isn't this what "AuthorizedKeysCommandUser %u" is supposed to do? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From arif at mail.nih.gov Thu Nov 22 05:33:06 2012 From: arif at mail.nih.gov (Anthony R Fletcher) Date: Wed, 21 Nov 2012 13:33:06 -0500 Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <50ACF136.1030805@fifthhorseman.net> References: <20121121015238.GA25294@cosy.cit.nih.gov> <20121121024837.GA8000@gate.dtucker.net> <20121121141613.GA11407@cosy.cit.nih.gov> <50ACF136.1030805@fifthhorseman.net> Message-ID: <20121121183306.GA7571@cosy.cit.nih.gov> On 21 Nov 2012 at 10:20:22, Daniel Kahn Gillmor wrote: > On 11/21/2012 09:16 AM, Anthony R Fletcher wrote: > > AuthorizedKeysCommandUser > > Specifies the user under whose account the AuthorizedKeysCommand is > > run. It is recommended to use a dedicated user that has no other > > role on the host than running authorized keys commands. > > > > This is a required option when using AuthorizedKeysCommand. > > > > Can we have the option to run as the authenticating user? Otherwise I > > need to use some kind of sudo magic. > > isn't this what "AuthorizedKeysCommandUser %u" is supposed to do? Yes, that works. Thanks :-) Can we add it to the manual page? Anthony. -- Anthony R Fletcher Room 2033, Building 12A, http://dcb.cit.nih.gov/~arif National Institutes of Health, arif at mail.nih.gov 12A South Drive, Bethesda, Phone: (+1) 301 402 1741. MD 20892-5624, USA. From andrew at acooke.org Thu Nov 22 05:49:30 2012 From: andrew at acooke.org (andrew cooke) Date: Wed, 21 Nov 2012 15:49:30 -0300 Subject: HostKey in hardware? Message-ID: <20121121184930.GX11406@acooke.org> Hi, Is there any way to store HostKey in hardware (and delegate the related processing)? I have been using Roumen Petrov's x509 patch for clients, which works via an OpenSSL engine, but it does not seem to support server HostKey: http://roumenpetrov.info/pipermail/ssh_x509_roumenpetrov.info/2012q4/000019.html For PKCS#11, I have found an email on this list from a year back suggesting this might happen http://marc.info/?l=openssh-unix-dev&m=131501200216440&w=2 and there's also a mention in this talk http://www.openbsd.org/papers/asiabsdcon2011_openssh_whats_new.pdf but I can find no evidence that anything has been implemented yet. The hardware I am using (Spyrus Lynks II) doesn't have PKCS#11 support, so I would prefer the OpenSSL route (since I already have an engine), but if necessary I would consider writing a minimal PKCS#11 implementation (can anyone give a rough idea of the amount of work involved to get HostKey working, only?) Anyway, any pointers would be appreciated. Thanks, Andrew From dan at doxpara.com Thu Nov 22 11:05:11 2012 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 21 Nov 2012 16:05:11 -0800 Subject: Safe Anonymous SFTP Message-ID: Do we have any solid guidance how to do safe, anonymous, SFTP? Even with a dedicated shell, port forwarding creates open proxies (which I know can be disabled, but still). From nkadel at gmail.com Thu Nov 22 14:23:47 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 21 Nov 2012 22:23:47 -0500 Subject: Safe Anonymous SFTP In-Reply-To: References: Message-ID: On Wed, Nov 21, 2012 at 7:05 PM, Dan Kaminsky wrote: > Do we have any solid guidance how to do safe, anonymous, SFTP? > > Even with a dedicated shell, port forwarding creates open proxies (which I > know can be disabled, but still). I gave up on this a *long* time ago, for a lot of reasons, and switched to WebDAV over HTTPS. It's built into myst web clients, there are lightweight Java applications for upload, and the separation of the service from shell access helps prevent people from doing clever but dangerious configurations. And there are good UNIX and Linux server configurations built into Apache, easily configurable and with good support for both anonymous and non-anonymous access. From peter at stuge.se Thu Nov 22 15:08:49 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 22 Nov 2012 05:08:49 +0100 Subject: Safe Anonymous SFTP In-Reply-To: References: Message-ID: <20121122040849.31564.qmail@stuge.se> Dan Kaminsky wrote: > Do we have any solid guidance how to do safe, anonymous, SFTP? > > Even with a dedicated shell, port forwarding creates open proxies > (which I know can be disabled, but still). I don't understand the issue? SFTP is one channel, port forwarding is another. Servers can allow SFTP and block both direct-tcpip and tcpip-forward channels. Define safe, and define anonymous? //Peter From pjd at FreeBSD.org Thu Nov 22 21:16:58 2012 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu, 22 Nov 2012 11:16:58 +0100 Subject: AuthenticationMethods option. Message-ID: <20121122101658.GC1419@garage.freebsd.pl> Hi. I can see that SSH partial success functionality was implemented very recently in the OpenSSH server. That's great news. I just tried it and I don't seem to be able to make it work with both public key authentication and password authentication through PAM. I wonder if this is a bug or something that won't be implemented for now or if this is still WIP and I should be more patient? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From djm at mindrot.org Fri Nov 23 10:19:11 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Nov 2012 10:19:11 +1100 (EST) Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121121001551.16222.qmail@stuge.se> References: <20121120195136.GA31621@cosy.cit.nih.gov> <20121121001551.16222.qmail@stuge.se> Message-ID: On Wed, 21 Nov 2012, Peter Stuge wrote: > Damien Miller wrote: > > > why not make all the information available to the > > > AuthorizedKeysCommand command? > > > > AuthorizedKeysCommand should be as simple as possible, I don't want > > to burden it with lots of options, especially when the > > authorized_keys format is quite powerful as it is. > > It's about providing the child process information about who is > connected. Is SSH_CONNECTION already being set in the child > environment? No From djm at mindrot.org Fri Nov 23 10:25:46 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Nov 2012 10:25:46 +1100 (EST) Subject: Connection info with AuthorizedKeysCommand In-Reply-To: <20121121141613.GA11407@cosy.cit.nih.gov> References: <20121121015238.GA25294@cosy.cit.nih.gov> <20121121024837.GA8000@gate.dtucker.net> <20121121141613.GA11407@cosy.cit.nih.gov> Message-ID: On Wed, 21 Nov 2012, Anthony R Fletcher wrote: > Can we have the option to run as the authenticating user? Otherwise I > need to use some kind of sudo magic. You can use "AuthorizedKeysCommand %u" to get this. We don't advertise it in the manual pages because it generally isn't a good idea. -d From djm at mindrot.org Fri Nov 23 12:18:14 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Nov 2012 12:18:14 +1100 (EST) Subject: HostKey in hardware? In-Reply-To: <20121121184930.GX11406@acooke.org> References: <20121121184930.GX11406@acooke.org> Message-ID: On Wed, 21 Nov 2012, andrew cooke wrote: > > Hi, > > Is there any way to store HostKey in hardware (and delegate the related > processing)? I've been wanting to do this for a while, but hadn't got around to it. Congratulations, you managed to troll me into action :) (see below) > The hardware I am using (Spyrus Lynks II) doesn't have PKCS#11 support, so I > would prefer the OpenSSL route (since I already have an engine), but if > necessary I would consider writing a minimal PKCS#11 implementation (can > anyone give a rough idea of the amount of work involved to get HostKey > working, only?) We aren't likely to add support for anything other than PKCS#11 host keys. Here's a (lightly tested) patch for PKCS#11 host keys. At the moment, the keys are loaded using a fixed PIN of 0000, but there's probably a better way to do it. I don't really want sshd to block at startup time while looking for a password, but my PKCS#15-fu isn't good enough to know how to create keys that don't require a PIN at all. diff --git servconf.c servconf.c index 9919778..3670a2f 100644 --- servconf.c +++ servconf.c @@ -67,6 +67,7 @@ initialize_server_options(ServerOptions *options) options->listen_addrs = NULL; options->address_family = -1; options->num_host_key_files = 0; + options->num_host_key_pkcs11_providers = 0; options->num_host_cert_files = 0; options->pid_file = NULL; options->server_key_bits = -1; @@ -160,6 +161,7 @@ fill_default_server_options(ServerOptions *options) _PATH_HOST_ECDSA_KEY_FILE; } } + /* No PKCS#11 providers by default */ /* No certificates by default */ if (options->num_ports == 0) options->ports[options->num_ports++] = SSH_DEFAULT_PORT; @@ -281,7 +283,8 @@ fill_default_server_options(ServerOptions *options) /* Keyword tokens. */ typedef enum { sBadOption, /* == unknown option */ - sPort, sHostKeyFile, sServerKeyBits, sLoginGraceTime, sKeyRegenerationTime, + sPort, sHostKeyFile, sHostKeyPKCS11, sServerKeyBits, + sLoginGraceTime, sKeyRegenerationTime, sPermitRootLogin, sLogFacility, sLogLevel, sRhostsRSAAuthentication, sRSAAuthentication, sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTicketCleanup, @@ -324,6 +327,7 @@ static struct { { "port", sPort, SSHCFG_GLOBAL }, { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ + { "hostkeypkcs11", sHostKeyPKCS11, SSHCFG_GLOBAL }, { "pidfile", sPidFile, SSHCFG_GLOBAL }, { "serverkeybits", sServerKeyBits, SSHCFG_GLOBAL }, { "logingracetime", sLoginGraceTime, SSHCFG_GLOBAL }, @@ -907,22 +911,33 @@ process_server_config_line(ServerOptions *options, char *line, fatal("%s line %d: missing file name.", filename, linenum); if (*activep && *charptr == NULL) { - *charptr = derelativise_path(arg); + if (strcasecmp(arg, "none") == 0) + *charptr = xstrdup("none"); + else + *charptr = derelativise_path(arg); /* increase optional counter */ if (intptr != NULL) *intptr = *intptr + 1; } break; + case sHostKeyPKCS11: + intptr = &options->num_host_key_pkcs11_providers; + if (*intptr >= MAX_HOSTPKCS11) + fatal("%s line %d: too many host key PKCS#11 providers " + "specified (max %d).", filename, linenum, + MAX_HOSTPKCS11); + charptr = &options->host_key_pkcs11_providers[*intptr]; + goto parse_filename; + case sHostCertificate: intptr = &options->num_host_cert_files; - if (*intptr >= MAX_HOSTKEYS) + if (*intptr >= MAX_HOSTCERTS) fatal("%s line %d: too many host certificates " "specified (max %d).", filename, linenum, MAX_HOSTCERTS); charptr = &options->host_cert_files[*intptr]; goto parse_filename; - break; case sPidFile: charptr = &options->pid_file; @@ -1918,7 +1933,9 @@ dump_config(ServerOptions *o) o->authorized_keys_files); dump_cfg_strarray(sHostKeyFile, o->num_host_key_files, o->host_key_files); - dump_cfg_strarray(sHostKeyFile, o->num_host_cert_files, + dump_cfg_strarray(sHostKeyPKCS11, o->num_host_key_pkcs11_providers, + o->host_key_pkcs11_providers); + dump_cfg_strarray(sHostCertificate, o->num_host_cert_files, o->host_cert_files); dump_cfg_strarray(sAllowUsers, o->num_allow_users, o->allow_users); dump_cfg_strarray(sDenyUsers, o->num_deny_users, o->deny_users); diff --git servconf.h servconf.h index da2374b..e48b38a 100644 --- servconf.h +++ servconf.h @@ -23,8 +23,9 @@ #define MAX_ALLOW_GROUPS 256 /* Max # groups on allow list. */ #define MAX_DENY_GROUPS 256 /* Max # groups on deny list. */ #define MAX_SUBSYSTEMS 256 /* Max # subsystems. */ -#define MAX_HOSTKEYS 256 /* Max # hostkeys. */ -#define MAX_HOSTCERTS 256 /* Max # host certificates. */ +#define MAX_HOSTKEYS 16 /* Max # hostkeys. */ +#define MAX_HOSTCERTS 16 /* Max # host certificates. */ +#define MAX_HOSTPKCS11 16 /* Max # host key PKCS#11 providers. */ #define MAX_ACCEPT_ENV 256 /* Max # of env vars. */ #define MAX_MATCH_GROUPS 256 /* Max # of groups for Match. */ #define MAX_AUTHKEYS_FILES 256 /* Max # of authorized_keys files. */ @@ -55,10 +56,17 @@ typedef struct { char *listen_addr; /* Address on which the server listens. */ struct addrinfo *listen_addrs; /* Addresses on which the server listens. */ int address_family; /* Address family used by the server. */ - char *host_key_files[MAX_HOSTKEYS]; /* Files containing host keys. */ - int num_host_key_files; /* Number of files for host keys. */ - char *host_cert_files[MAX_HOSTCERTS]; /* Files containing host certs. */ - int num_host_cert_files; /* Number of files for host certs. */ + + /* Host key files */ + char *host_key_files[MAX_HOSTKEYS]; + int num_host_key_files; + /* Host key PKCS#11 providers */ + char *host_key_pkcs11_providers[MAX_HOSTPKCS11]; + int num_host_key_pkcs11_providers; + /* Host certificate files */ + char *host_cert_files[MAX_HOSTCERTS]; + int num_host_cert_files; + char *pid_file; /* Where to put our pid */ int server_key_bits;/* Size of the server key. */ int login_grace_time; /* Disconnect if no auth in this time diff --git sshd.c sshd.c index d3f53c0..83eab58 100644 --- sshd.c +++ sshd.c @@ -105,6 +105,13 @@ #include "ssh-sandbox.h" #include "version.h" +#ifdef ENABLE_PKCS11 +#include "ssh-pkcs11.h" +#endif + +/* PIN used for PKCS#11 providers */ +#define SSHD_PKCS11_PIN "0000" /* XXX */ + #ifdef LIBWRAP #include #include @@ -188,6 +195,7 @@ Kex *xxx_kex; struct { Key *server_key; /* ephemeral server key */ Key *ssh1_host_key; /* ssh1 host key */ + int num_host_keys; /* number of private host keys */ Key **host_keys; /* all private host keys */ Key **host_certificates; /* all public host certificates */ int have_ssh1_key; @@ -534,7 +542,7 @@ destroy_sensitive_data(void) key_free(sensitive_data.server_key); sensitive_data.server_key = NULL; } - for (i = 0; i < options.num_host_key_files; i++) { + for (i = 0; i < sensitive_data.num_host_keys; i++) { if (sensitive_data.host_keys[i]) { key_free(sensitive_data.host_keys[i]); sensitive_data.host_keys[i] = NULL; @@ -561,7 +569,7 @@ demote_sensitive_data(void) sensitive_data.server_key = tmp; } - for (i = 0; i < options.num_host_key_files; i++) { + for (i = 0; i < sensitive_data.num_host_keys; i++) { if (sensitive_data.host_keys[i]) { tmp = key_demote(sensitive_data.host_keys[i]); key_free(sensitive_data.host_keys[i]); @@ -747,7 +755,7 @@ list_hostkey_types(void) Key *key; buffer_init(&b); - for (i = 0; i < options.num_host_key_files; i++) { + for (i = 0; i < sensitive_data.num_host_keys; i++) { key = sensitive_data.host_keys[i]; if (key == NULL) continue; @@ -791,7 +799,7 @@ get_hostkey_by_type(int type, int need_private) int i; Key *key; - for (i = 0; i < options.num_host_key_files; i++) { + for (i = 0; i < sensitive_data.num_host_keys; i++) { switch (type) { case KEY_RSA_CERT_V00: case KEY_DSA_CERT_V00: @@ -826,7 +834,7 @@ get_hostkey_private_by_type(int type) Key * get_hostkey_by_index(int ind) { - if (ind < 0 || ind >= options.num_host_key_files) + if (ind < 0 || ind >= sensitive_data.num_host_keys) return (NULL); return (sensitive_data.host_keys[ind]); } @@ -836,7 +844,7 @@ get_hostkey_index(Key *key) { int i; - for (i = 0; i < options.num_host_key_files; i++) { + for (i = 0; i < sensitive_data.num_host_keys; i++) { if (key_is_cert(key)) { if (key == sensitive_data.host_certificates[i]) return (i); @@ -1296,7 +1304,7 @@ main(int ac, char **av) { extern char *optarg; extern int optind; - int opt, i, j, on = 1; + int opt, i, j, nkeys, on = 1; int sock_in = -1, sock_out = -1, newsock = -1; const char *remote_ip; int remote_port; @@ -1305,7 +1313,7 @@ main(int ac, char **av) u_int n; u_int64_t ibytes, obytes; mode_t new_umask; - Key *key; + Key *key, **keys; Authctxt *authctxt; struct connection_info *connection_info = get_connection_info(0, 0); @@ -1530,20 +1538,54 @@ main(int ac, char **av) debug("sshd version %.100s", SSH_VERSION); /* load private host keys */ - sensitive_data.host_keys = xcalloc(options.num_host_key_files, - sizeof(Key *)); - for (i = 0; i < options.num_host_key_files; i++) - sensitive_data.host_keys[i] = NULL; + sensitive_data.host_keys = xcalloc(options.num_host_key_files + + options.num_host_key_pkcs11_providers, sizeof(Key *)); + sensitive_data.num_host_keys = 0; + +#ifdef ENABLE_PKCS11 + if (options.num_host_key_pkcs11_providers > 0) { + if (pkcs11_init(0) != 0) + fatal("Could not initialise PKCS#11 for host keys"); + for (i = 0; i < options.num_host_key_pkcs11_providers; i++) { + nkeys = pkcs11_add_provider( + options.host_key_pkcs11_providers[i], + SSHD_PKCS11_PIN, &keys); + if (nkeys == -1) + fatal("Failed to add PKCS#11 provider \"%s\"", + options.host_key_pkcs11_providers[i]); + if (nkeys == 0) { + error("PKCS#11 provider \"%s\" yielded no keys", + options.host_key_pkcs11_providers[i]); + continue; + } + for (j = 0; j < nkeys; j++) { + sensitive_data.host_keys[ + sensitive_data.num_host_keys++] = keys[j]; + } + free(keys); + } + } +#endif /* ENABLE_PKCS11 */ for (i = 0; i < options.num_host_key_files; i++) { + if (strcasecmp(options.host_key_files[i], "none") == 0) + continue; key = key_load_private(options.host_key_files[i], "", NULL); - sensitive_data.host_keys[i] = key; + sensitive_data.host_keys[sensitive_data.num_host_keys++] = key; if (key == NULL) { error("Could not load host key: %s", options.host_key_files[i]); - sensitive_data.host_keys[i] = NULL; continue; } + debug("private host key: #%d type %d %s", + sensitive_data.num_host_keys - 1, key->type, key_type(key)); + } + + /* Figure out whether we have loaded keys for protocols 1 and 2 */ + for (i = 0; i < sensitive_data.num_host_keys; i++) { + key = sensitive_data.host_keys[i]; + if (key == NULL) + continue; switch (key->type) { case KEY_RSA1: sensitive_data.ssh1_host_key = key; @@ -1555,9 +1597,8 @@ main(int ac, char **av) sensitive_data.have_ssh2_key = 1; break; } - debug("private host key: #%d type %d %s", i, key->type, - key_type(key)); } + if ((options.protocol & SSH_PROTO_1) && !sensitive_data.have_ssh1_key) { logit("Disabling protocol version 1. Could not load host key"); options.protocol &= ~SSH_PROTO_1; @@ -1575,9 +1616,9 @@ main(int ac, char **av) * Load certificates. They are stored in an array at identical * indices to the public keys that they relate to. */ - sensitive_data.host_certificates = xcalloc(options.num_host_key_files, + sensitive_data.host_certificates = xcalloc(sensitive_data.num_host_keys, sizeof(Key *)); - for (i = 0; i < options.num_host_key_files; i++) + for (i = 0; i < sensitive_data.num_host_keys; i++) sensitive_data.host_certificates[i] = NULL; for (i = 0; i < options.num_host_cert_files; i++) { @@ -1594,14 +1635,14 @@ main(int ac, char **av) continue; } /* Find matching private key */ - for (j = 0; j < options.num_host_key_files; j++) { + for (j = 0; j < sensitive_data.num_host_keys; j++) { if (key_equal_public(key, sensitive_data.host_keys[j])) { sensitive_data.host_certificates[j] = key; break; } } - if (j >= options.num_host_key_files) { + if (j >= sensitive_data.num_host_keys) { error("No matching private key for certificate: %s", options.host_cert_files[i]); key_free(key); diff --git sshd_config.5 sshd_config.5 index 91935d0..5ec06f2 100644 --- sshd_config.5 +++ sshd_config.5 @@ -517,6 +517,10 @@ for protocol version 1, and and .Pa /etc/ssh/ssh_host_rsa_key for protocol version 2. +It is possible to skip loading of host keys by specifying a path of +.Pa none +in cases where keys are supplied via +.Cm HostKeyPKCS11 . Note that .Xr sshd 8 will refuse to use a file if it is group/world-accessible. @@ -528,6 +532,15 @@ keys are used for version 1 and or .Dq rsa are used for version 2 of the SSH protocol. +.It Cm HostKeyPKCS11 +Specify a PKCS#11 provider for host keys. +.Nm +will attempt to load all keys in this device assuming a PIN of +.Dq 0000 +and use them as host keys. +This option may be specified more than once to allow loading of host keys +from multiple devices. +The default is not to attempt to load host keys from PKCS#11 devices. .It Cm IgnoreRhosts Specifies that .Pa .rhosts From djm at mindrot.org Fri Nov 23 12:36:10 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Nov 2012 12:36:10 +1100 (EST) Subject: AuthenticationMethods option. In-Reply-To: <20121122101658.GC1419@garage.freebsd.pl> References: <20121122101658.GC1419@garage.freebsd.pl> Message-ID: On Thu, 22 Nov 2012, Pawel Jakub Dawidek wrote: > Hi. > > I can see that SSH partial success functionality was implemented very > recently in the OpenSSH server. That's great news. > > I just tried it and I don't seem to be able to make it work with both > public key authentication and password authentication through PAM. > I wonder if this is a bug or something that won't be implemented for now > or if this is still WIP and I should be more patient? Yes, there is a bug in there - the monitor is becoming confused by returns from monitor_read() that don't reset auth_method to an expected method name. I'll take a look. -d From peter at stuge.se Fri Nov 23 14:35:28 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 23 Nov 2012 04:35:28 +0100 Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> Message-ID: <20121123033528.18949.qmail@stuge.se> Damien Miller wrote: > At the moment, the keys are loaded using a fixed PIN of 0000, but > there's probably a better way to do it. Maybe take PIN from the config file, although it's not too awesome.. //Peter From djm at mindrot.org Fri Nov 23 15:09:17 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Nov 2012 15:09:17 +1100 (EST) Subject: HostKey in hardware? In-Reply-To: <20121123033528.18949.qmail@stuge.se> References: <20121121184930.GX11406@acooke.org> <20121123033528.18949.qmail@stuge.se> Message-ID: On Fri, 23 Nov 2012, Peter Stuge wrote: > Damien Miller wrote: > At the moment, the keys are loaded using a > fixed PIN of 0000, but > there's probably a better way to do it. > > Maybe take PIN from the config file, although it's not too awesome.. If you can steal access to the token then you can almost certainly steal sshd_config, so I think that would be false security for most people. I'd prefer to stipulate that any keys used for hostkeys are PIN-less, but I can't find any documentation on how one would actually create these. It looks like it should be possible using OpenSC and a custom pkcs15.profile, but I don't know enough about PKCS#15 or the vagaries of various tokens' behaviour to actually do it or say that it would work reliably :( -d From djm at mindrot.org Fri Nov 23 15:11:39 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Nov 2012 15:11:39 +1100 (EST) Subject: AuthenticationMethods option. In-Reply-To: References: <20121122101658.GC1419@garage.freebsd.pl> Message-ID: On Fri, 23 Nov 2012, Damien Miller wrote: > On Thu, 22 Nov 2012, Pawel Jakub Dawidek wrote: > > > Hi. > > > > I can see that SSH partial success functionality was implemented very > > recently in the OpenSSH server. That's great news. > > > > I just tried it and I don't seem to be able to make it work with both > > public key authentication and password authentication through PAM. > > I wonder if this is a bug or something that won't be implemented for now > > or if this is still WIP and I should be more patient? > > Yes, there is a bug in there - the monitor is becoming confused by > returns from monitor_read() that don't reset auth_method to an > expected method name. > > I'll take a look. I think this fixes it: Index: auth.c =================================================================== RCS file: /var/cvs/openssh/auth.c,v retrieving revision 1.152 diff -u -p -r1.152 auth.c --- auth.c 30 Oct 2012 21:58:59 -0000 1.152 +++ auth.c 23 Nov 2012 04:09:56 -0000 @@ -251,7 +251,8 @@ allowed_user(struct passwd * pw) } void -auth_log(Authctxt *authctxt, int authenticated, char *method, char *info) +auth_log(Authctxt *authctxt, int authenticated, int partial, + const char *method, const char *submethod, const char *info) { void (*authlog) (const char *fmt,...) = verbose; char *authmsg; @@ -268,12 +269,15 @@ auth_log(Authctxt *authctxt, int authent if (authctxt->postponed) authmsg = "Postponed"; + else if (partial) + authmsg = "Partial"; else authmsg = authenticated ? "Accepted" : "Failed"; - authlog("%s %s for %s%.100s from %.200s port %d%s", + authlog("%s %s%s%s for %s%.100s from %.200s port %d%s", authmsg, method, + submethod != NULL ? "/" : "", submethod == NULL ? "" : submethod, authctxt->valid ? "" : "invalid user ", authctxt->user, get_remote_ipaddr(), @@ -303,7 +307,7 @@ auth_log(Authctxt *authctxt, int authent * Check whether root logins are disallowed. */ int -auth_root_allowed(char *method) +auth_root_allowed(const char *method) { switch (options.permit_root_login) { case PERMIT_YES: Index: auth.h =================================================================== RCS file: /var/cvs/openssh/auth.h,v retrieving revision 1.89 diff -u -p -r1.89 auth.h --- auth.h 4 Nov 2012 12:21:41 -0000 1.89 +++ auth.h 23 Nov 2012 04:09:56 -0000 @@ -148,10 +148,12 @@ void disable_forwarding(void); void do_authentication(Authctxt *); void do_authentication2(Authctxt *); -void auth_log(Authctxt *, int, char *, char *); -void userauth_finish(Authctxt *, int, char *); +void auth_log(Authctxt *, int, int, const char *, const char *, + const char *); +void userauth_finish(Authctxt *, int, const char *, const char *); +int auth_root_allowed(const char *); + void userauth_send_banner(const char *); -int auth_root_allowed(char *); char *auth2_read_banner(void); int auth2_methods_valid(const char *, int); Index: auth1.c =================================================================== RCS file: /var/cvs/openssh/auth1.c,v retrieving revision 1.128 diff -u -p -r1.128 auth1.c --- auth1.c 4 Nov 2012 12:21:41 -0000 1.128 +++ auth1.c 23 Nov 2012 04:09:56 -0000 @@ -253,7 +253,8 @@ do_authloop(Authctxt *authctxt) if (options.use_pam && (PRIVSEP(do_pam_account()))) #endif { - auth_log(authctxt, 1, "without authentication", ""); + auth_log(authctxt, 1, 0, "without authentication", + NULL, ""); return; } } @@ -352,7 +353,8 @@ do_authloop(Authctxt *authctxt) skip: /* Log before sending the reply */ - auth_log(authctxt, authenticated, get_authname(type), info); + auth_log(authctxt, authenticated, 0, get_authname(type), + NULL, info); if (client_user != NULL) { xfree(client_user); Index: auth2-chall.c =================================================================== RCS file: /var/cvs/openssh/auth2-chall.c,v retrieving revision 1.38 diff -u -p -r1.38 auth2-chall.c --- auth2-chall.c 28 Jan 2009 05:13:39 -0000 1.38 +++ auth2-chall.c 23 Nov 2012 04:09:56 -0000 @@ -283,7 +283,7 @@ input_userauth_info_response(int type, u KbdintAuthctxt *kbdintctxt; int authenticated = 0, res; u_int i, nresp; - char **response = NULL, *method; + char *devicename = NULL, **response = NULL; if (authctxt == NULL) fatal("input_userauth_info_response: no authctxt"); @@ -329,9 +329,7 @@ input_userauth_info_response(int type, u /* Failure! */ break; } - - xasprintf(&method, "keyboard-interactive/%s", kbdintctxt->device->name); - + devicename = kbdintctxt->device->name; if (!authctxt->postponed) { if (authenticated) { auth2_challenge_stop(authctxt); @@ -341,8 +339,8 @@ input_userauth_info_response(int type, u auth2_challenge_start(authctxt); } } - userauth_finish(authctxt, authenticated, method); - xfree(method); + userauth_finish(authctxt, authenticated, "keyboard-interactive", + devicename); } void Index: auth2-gss.c =================================================================== RCS file: /var/cvs/openssh/auth2-gss.c,v retrieving revision 1.20 diff -u -p -r1.20 auth2-gss.c --- auth2-gss.c 5 May 2011 04:04:11 -0000 1.20 +++ auth2-gss.c 23 Nov 2012 04:09:56 -0000 @@ -163,7 +163,7 @@ input_gssapi_token(int type, u_int32_t p } authctxt->postponed = 0; dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); - userauth_finish(authctxt, 0, "gssapi-with-mic"); + userauth_finish(authctxt, 0, "gssapi-with-mic", NULL); } else { if (send_tok.length != 0) { packet_start(SSH2_MSG_USERAUTH_GSSAPI_TOKEN); @@ -251,7 +251,7 @@ input_gssapi_exchange_complete(int type, dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, NULL); dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_MIC, NULL); dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, NULL); - userauth_finish(authctxt, authenticated, "gssapi-with-mic"); + userauth_finish(authctxt, authenticated, "gssapi-with-mic", NULL); } static void @@ -291,7 +291,7 @@ input_gssapi_mic(int type, u_int32_t ple dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, NULL); dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_MIC, NULL); dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, NULL); - userauth_finish(authctxt, authenticated, "gssapi-with-mic"); + userauth_finish(authctxt, authenticated, "gssapi-with-mic", NULL); } Authmethod method_gssapi = { Index: auth2-jpake.c =================================================================== RCS file: /var/cvs/openssh/auth2-jpake.c,v retrieving revision 1.5 diff -u -p -r1.5 auth2-jpake.c --- auth2-jpake.c 31 Aug 2010 12:41:14 -0000 1.5 +++ auth2-jpake.c 23 Nov 2012 04:09:56 -0000 @@ -556,7 +556,7 @@ input_userauth_jpake_client_confirm(int authctxt->postponed = 0; jpake_free(authctxt->jpake_ctx); authctxt->jpake_ctx = NULL; - userauth_finish(authctxt, authenticated, method_jpake.name); + userauth_finish(authctxt, authenticated, method_jpake.name, NULL); } #endif /* JPAKE */ Index: auth2.c =================================================================== RCS file: /var/cvs/openssh/auth2.c,v retrieving revision 1.155 diff -u -p -r1.155 auth2.c --- auth2.c 4 Nov 2012 12:21:41 -0000 1.155 +++ auth2.c 23 Nov 2012 04:09:56 -0000 @@ -286,7 +286,7 @@ input_userauth_request(int type, u_int32 debug2("input_userauth_request: try method %s", method); authenticated = m->userauth(authctxt); } - userauth_finish(authctxt, authenticated, method); + userauth_finish(authctxt, authenticated, method, NULL); xfree(service); xfree(user); @@ -294,7 +294,8 @@ input_userauth_request(int type, u_int32 } void -userauth_finish(Authctxt *authctxt, int authenticated, char *method) +userauth_finish(Authctxt *authctxt, int authenticated, const char *method, + const char *submethod) { char *methods; int partial = 0; @@ -302,6 +303,8 @@ userauth_finish(Authctxt *authctxt, int if (!authctxt->valid && authenticated) fatal("INTERNAL ERROR: authenticated invalid user %s", authctxt->user); + if (authenticated && authctxt->postponed) + fatal("INTERNAL ERROR: authenticated and postponed"); /* Special handling for root */ if (authenticated && authctxt->pw->pw_uid == 0 && @@ -312,6 +315,19 @@ userauth_finish(Authctxt *authctxt, int #endif } + if (authenticated && options.num_auth_methods != 0) { + if (!auth2_update_methods_lists(authctxt, method)) { + authenticated = 0; + partial = 1; + } + } + + /* Log before sending the reply */ + auth_log(authctxt, authenticated, partial, method, submethod, " ssh2"); + + if (authctxt->postponed) + return; + #ifdef USE_PAM if (options.use_pam && authenticated) { if (!PRIVSEP(do_pam_account())) { @@ -330,22 +346,9 @@ userauth_finish(Authctxt *authctxt, int #ifdef _UNICOS if (authenticated && cray_access_denied(authctxt->user)) { authenticated = 0; - fatal("Access denied for user %s.",authctxt->user); + fatal("Access denied for user %s.", authctxt->user); } #endif /* _UNICOS */ - - /* Log before sending the reply */ - auth_log(authctxt, authenticated, method, " ssh2"); - - if (authctxt->postponed) - return; - - if (authenticated && options.num_auth_methods != 0) { - if (!auth2_update_methods_lists(authctxt, method)) { - authenticated = 0; - partial = 1; - } - } if (authenticated == 1) { /* turn off userauth */ Index: monitor.c =================================================================== RCS file: /var/cvs/openssh/monitor.c,v retrieving revision 1.153 diff -u -p -r1.153 monitor.c --- monitor.c 4 Nov 2012 12:21:41 -0000 1.153 +++ monitor.c 23 Nov 2012 04:09:56 -0000 @@ -199,6 +199,7 @@ static int key_blobtype = MM_NOKEY; static char *hostbased_cuser = NULL; static char *hostbased_chost = NULL; static char *auth_method = "unknown"; +static char *auth_submethod = NULL; static u_int session_id2_len = 0; static u_char *session_id2 = NULL; static pid_t monitor_child_pid; @@ -352,7 +353,7 @@ void monitor_child_preauth(Authctxt *_authctxt, struct monitor *pmonitor) { struct mon_table *ent; - int authenticated = 0; + int authenticated = 0, partial = 0; debug3("preauth child monitor started"); @@ -379,7 +380,9 @@ monitor_child_preauth(Authctxt *_authctx /* The first few requests do not require asynchronous access */ while (!authenticated) { + partial = 0; auth_method = "unknown"; + auth_submethod = NULL; authenticated = (monitor_read(pmonitor, mon_dispatch, &ent) == 1); /* Special handling for multiple required authentications */ @@ -393,6 +396,7 @@ monitor_child_preauth(Authctxt *_authctx debug3("%s: method %s: partial", __func__, auth_method); authenticated = 0; + partial = 1; } } @@ -417,7 +421,8 @@ monitor_child_preauth(Authctxt *_authctx #endif } if (ent->flags & (MON_AUTHDECIDE|MON_ALOG)) { - auth_log(authctxt, authenticated, auth_method, + auth_log(authctxt, authenticated, partial, + auth_method, auth_submethod, compat20 ? " ssh2" : ""); if (!authenticated) authctxt->failures++; @@ -943,7 +948,7 @@ mm_answer_bsdauthrespond(int sock, Buffe mm_request_send(sock, MONITOR_ANS_BSDAUTHRESPOND, m); if (compat20) - auth_method = "keyboard-interactive"; + auth_method = "keyboard-interactive"; /* XXX auth_submethod */ else auth_method = "bsdauth"; @@ -1084,7 +1089,8 @@ mm_answer_pam_query(int sock, Buffer *m) xfree(prompts); if (echo_on != NULL) xfree(echo_on); - auth_method = "keyboard-interactive/pam"; + auth_method = "keyboard-interactive"; + auth_submethod = "pam"; mm_request_send(sock, MONITOR_ANS_PAM_QUERY, m); return (0); } @@ -1113,7 +1119,8 @@ mm_answer_pam_respond(int sock, Buffer * buffer_clear(m); buffer_put_int(m, ret); mm_request_send(sock, MONITOR_ANS_PAM_RESPOND, m); - auth_method = "keyboard-interactive/pam"; + auth_method = "keyboard-interactive"; + auth_submethod = "pam"; if (ret == 0) sshpam_authok = sshpam_ctxt; return (0); @@ -1127,7 +1134,8 @@ mm_answer_pam_free_ctx(int sock, Buffer (sshpam_device.free_ctx)(sshpam_ctxt); buffer_clear(m); mm_request_send(sock, MONITOR_ANS_PAM_FREE_CTX, m); - auth_method = "keyboard-interactive/pam"; + auth_method = "keyboard-interactive"; + auth_submethod = "pam"; return (sshpam_authok == sshpam_ctxt); } #endif @@ -1201,7 +1209,8 @@ mm_answer_keyallowed(int sock, Buffer *m hostbased_chost = chost; } else { /* Log failed attempt */ - auth_log(authctxt, 0, auth_method, compat20 ? " ssh2" : ""); + auth_log(authctxt, 0, 0, auth_method, NULL, + compat20 ? " ssh2" : ""); xfree(blob); xfree(cuser); xfree(chost); From pjd at FreeBSD.org Fri Nov 23 22:22:22 2012 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri, 23 Nov 2012 12:22:22 +0100 Subject: AuthenticationMethods option. In-Reply-To: References: <20121122101658.GC1419@garage.freebsd.pl> Message-ID: <20121123112222.GC1499@garage.freebsd.pl> On Fri, Nov 23, 2012 at 03:11:39PM +1100, Damien Miller wrote: > On Fri, 23 Nov 2012, Damien Miller wrote: > > > On Thu, 22 Nov 2012, Pawel Jakub Dawidek wrote: > > > > > Hi. > > > > > > I can see that SSH partial success functionality was implemented very > > > recently in the OpenSSH server. That's great news. > > > > > > I just tried it and I don't seem to be able to make it work with both > > > public key authentication and password authentication through PAM. > > > I wonder if this is a bug or something that won't be implemented for now > > > or if this is still WIP and I should be more patient? > > > > Yes, there is a bug in there - the monitor is becoming confused by > > returns from monitor_read() that don't reset auth_method to an > > expected method name. > > > > I'll take a look. > > I think this fixes it: It does fix the problem for me, thanks a lot! And being able to log into important hosts with public key authentication and one-time password is really nice. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From gsustek at gmail.com Sat Nov 24 02:20:25 2012 From: gsustek at gmail.com (Goran Sustek) Date: Fri, 23 Nov 2012 16:20:25 +0100 Subject: Public Key Authentication Message-ID: Hi, I wonder, how can i use openssh Public key authentification with ActivCard pkcs11 x509 certificate store and login to only my account reading/using username provided from certificate DN, or principal name,friendly name ? b111887 and e411617 is administrator on this os. I have rights to put e411617 pub keys to b111887 home folder authorized keys. And because openssh ask's me to provide username, i logi nin his folder as him with my public keys?can i disable this in some ways? please see attachment. Regards, Goran. From aab at expert.ics.purdue.edu Sat Nov 24 11:58:23 2012 From: aab at expert.ics.purdue.edu (Paul Townsend) Date: Fri, 23 Nov 2012 19:58:23 -0500 (EST) Subject: ssh-keyscan continuity patch -- Message-ID: <201211240058.qAO0wNSQ024503@expert.ics.purdue.edu> I apologize, this patch should have been sent awhile ago. Between a lot of things that needed to be completed at work as a sysadmin for the Research Computing group at Purdue University and retiring from work after 38 years at the end of May (2012), I basically ignored it. This patch is from a clone of my workstation that I just activated at home. The patch was primarily written to fix the problem(s) that was(were) causing `ssh-keyscan' to abort its runs prematurely, mainly connection errors with an attendant immediate abort when sensed. It also addresses what I consider to be some "buggy" code, some error message clarification and adds a command line option so that a STDERR message will be printed for ALL hosts submitted for processing. The patch has been running with no apparent problems on several machines most specifically on Ubuntu, Debian and Solaris. I think I started using some form of it for openssh-5.6p1 and it has not basically changed for at least the last 4 openssh*p1 releases. See Bugzilla #1213 for some discussion. The Debian system and hardware was probably changed to a Redhat system with new hardware after I left. `ssh-keyscan' was running there once an hour. Ummm - I think I followed your coding specs except for one "#include" that was not in alphabetical order. Actually, that list was already out of order. Hey, is there any web page that can be used to submit patches? -- Paul Townsend (former sysadmin at Purdue University) diff -u openssh-6.1p1/kex.c.orig openssh-6.1p1/kex.c --- openssh-6.1p1/kex.c.orig 2010-09-24 08:11:14.000000000 -0400 +++ openssh-6.1p1/kex.c 2012-05-08 20:47:32.666853000 -0400 @@ -49,6 +49,7 @@ #include "dispatch.h" #include "monitor.h" #include "roaming.h" +#include "canohost.h" #if OPENSSL_VERSION_NUMBER >= 0x00907000L # if defined(HAVE_EVP_SHA256) @@ -366,11 +367,19 @@ choose_hostkeyalg(Kex *k, char *client, char *server) { char *hostkeyalg = match_list(client, server, NULL); - if (hostkeyalg == NULL) - fatal("no hostkey alg"); + if (hostkeyalg == NULL) { + if (k->server) + fatal("bad '%.100s' hostkey alg request from %.200s", client, get_remote_ipaddr()); + else + fatal("no '%.100s' hostkey alg(s) for %.200s", client, get_remote_ipaddr()); + } +/* + * Note that if KEY_UNSPEC is returned, BOTH the client and the server + * have the same bad key string. + */ k->hostkey_type = key_type_from_name(hostkeyalg); if (k->hostkey_type == KEY_UNSPEC) - fatal("bad hostkey alg '%s'", hostkeyalg); + fatal("unknown hostkey alg '%s'", hostkeyalg); xfree(hostkeyalg); } diff -u openssh-6.1p1/packet.c.orig openssh-6.1p1/packet.c --- openssh-6.1p1/packet.c.orig 2012-03-08 18:28:07.000000000 -0500 +++ openssh-6.1p1/packet.c 2012-11-23 18:18:00.233636000 -0500 @@ -1018,6 +1018,17 @@ } /* + * The following two global variables exist to pass connection error + * conditions detected by code in packet_read_seqnr() to ssh-keyscan. + */ + +int connclosed = 0; /* = 1 if connection closed by remote server */ + /* prior to necessary data being read */ +int conntimedout = 0; /* = 1 if connection timed out locally while */ + /* waiting for data from remote server */ + /* both currently used in ssh-keyscan.c */ + +/* * Waits until a packet has been received, and returns its type. Note that * no other data is processed until this returns, so this function should not * be used during the interactive session. @@ -1033,6 +1044,9 @@ DBG(debug("packet_read()")); + connclosed = 0; + conntimedout = 0; + setp = (fd_set *)xcalloc(howmany(active_state->connection_in + 1, NFDBITS), sizeof(fd_mask)); @@ -1087,6 +1101,7 @@ } } if (ret == 0) { + conntimedout = 1; logit("Connection to %.200s timed out while " "waiting to read", get_remote_ipaddr()); cleanup_exit(255); @@ -1098,11 +1113,12 @@ sizeof(buf), &cont); } while (len == 0 && cont); if (len == 0) { + connclosed = 1; /* if anybody wants to know */ logit("Connection closed by %.200s", get_remote_ipaddr()); cleanup_exit(255); } if (len < 0) - fatal("Read from socket failed: %.100s", strerror(errno)); + fatal("Read from %.200s failed: %.100s", get_remote_ipaddr(), strerror(errno)); /* Append it to the buffer. */ packet_process_incoming(buf, len); } diff -u openssh-6.1p1/ssh-keyscan.1.orig openssh-6.1p1/ssh-keyscan.1 --- openssh-6.1p1/ssh-keyscan.1.orig 2010-08-31 08:41:14.000000000 -0400 +++ openssh-6.1p1/ssh-keyscan.1 2012-05-08 20:47:32.776848000 -0400 @@ -15,7 +15,7 @@ .Sh SYNOPSIS .Nm ssh-keyscan .Bk -words -.Op Fl 46Hv +.Op Fl 46HLv .Op Fl f Ar file .Op Fl p Ar port .Op Fl T Ar timeout @@ -73,6 +73,8 @@ .Nm sshd , but they do not reveal identifying information should the file's contents be disclosed. +.It Fl L +If specified, all hosts for which no key is acquired will be logged. .It Fl p Ar port Port to connect to on the remote host. .It Fl T Ar timeout diff -u openssh-6.1p1/ssh-keyscan.c.orig openssh-6.1p1/ssh-keyscan.c --- openssh-6.1p1/ssh-keyscan.c.orig 2011-05-05 00:05:12.000000000 -0400 +++ openssh-6.1p1/ssh-keyscan.c 2012-05-08 20:47:32.826852000 -0400 @@ -45,6 +45,7 @@ #include "atomicio.h" #include "misc.h" #include "hostfile.h" +#include "canohost.h" /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ @@ -61,15 +62,20 @@ int hash_hosts = 0; /* Hash hostname on output */ +int log_verbose = 0; /* list all hosts checked */ + #define MAXMAXFD 256 /* The number of seconds after which to give up on a TCP connection */ +/* and the maximum time to wait for kex data from the remote server.*/ int timeout = 5; int maxfd; #define MAXCON (maxfd - 10) extern char *__progname; +extern int connclosed; +extern int conntimedout; fd_set *read_wait; size_t read_wait_nfdset; int ncon; @@ -243,7 +249,23 @@ { int j; +/* + * New fd and socket. Clear the possibly cached IP-address of the + * remote host (kex.c:canonical_host_ip) of the previous socket. Also + * clear the packet_read_seqnr() "Connection closed ..." and "Connection + * to ... timed out ..." flags (called by dispatch_run()). + */ + clear_cached_addr(); + connclosed = 0; + conntimedout = 0; + packet_set_connection(c->c_fd, c->c_fd); +/* + * Use our "timeout" value to set the maximum allowed wait time for data + * to become available in the `packet.c:packet_read_seqnr()' function. + */ + packet_set_timeout(timeout, 1); + enable_compat20(); myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = c->c_keytype == KT_DSA? "ssh-dss" : (c->c_keytype == KT_RSA ? "ssh-rsa" : @@ -296,8 +318,11 @@ memset(&hints, 0, sizeof(hints)); hints.ai_family = IPv4or6; hints.ai_socktype = SOCK_STREAM; - if ((gaierr = getaddrinfo(host, strport, &hints, &aitop)) != 0) - fatal("getaddrinfo %s: %s", host, ssh_gai_strerror(gaierr)); + if ((gaierr = getaddrinfo(host, strport, &hints, &aitop)) != 0) { + error("getaddrinfo %s: %s", host, ssh_gai_strerror(gaierr)); + s = -1; + return s; + } for (ai = aitop; ai; ai = ai->ai_next) { s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (s < 0) { @@ -388,8 +413,20 @@ { con *c = &fdcon[s]; int ret; + char *name; - ret = conalloc(c->c_namelist, c->c_output_name, c->c_keytype); +/* + * If "connclosed" isn't set, do the next host from c->c_namelist. Else, + * restore the original string in c->c_namebase and redo the current + * host. + */ + name = c->c_namelist; /* do next in list ?? */ + if (connclosed != 0) { /* nope so */ + if (name && *name != '\0') /* restore separator, if any */ + *(name - 1) = ','; /* and */ + name = c->c_namebase; /* redo current */ + } + ret = conalloc(name, c->c_output_name, c->c_keytype); confree(s); return (ret); } @@ -419,10 +456,12 @@ if (n == 0) { switch (errno) { case EPIPE: - error("%s: Connection closed by remote host", c->c_name); + error("read (%s): Connection closed by remote host", c->c_name); break; case ECONNREFUSED: - break; + if (! log_verbose) + break; + /* fall thru */ default: error("read (%s): %s", c->c_name, strerror(errno)); break; @@ -443,14 +482,20 @@ datafellows = 0; if (c->c_keytype != KT_RSA1) { if (!ssh2_capable(remote_major, remote_minor)) { + if (log_verbose) + logit("%s doesn't support ssh2", c->c_name); + else debug("%s doesn't support ssh2", c->c_name); - confree(s); - return; + confree(s); + return; } } else if (remote_major != 1) { + if (log_verbose) + logit("%s doesn't support ssh1", c->c_name); + else debug("%s doesn't support ssh1", c->c_name); - confree(s); - return; + confree(s); + return; } fprintf(stderr, "# %s %s\n", c->c_name, chop(buf)); n = snprintf(buf, sizeof buf, "SSH-%d.%d-OpenSSH-keyscan\r\n", @@ -466,13 +511,17 @@ confree(s); return; } +/* Read and print one of the ssh2 keys for this host. */ if (c->c_keytype != KT_RSA1) { keyprint(c, keygrab_ssh2(c)); confree(s); return; } +/* Continue the process of getting the ssh1 key. */ c->c_status = CS_SIZE; contouch(s); + return; + } static void @@ -520,7 +569,7 @@ struct timeval seltime, now; fd_set *r, *e; con *c; - int i; + int i, s; gettimeofday(&now, NULL); c = TAILQ_FIRST(&tq); @@ -550,20 +599,100 @@ if (FD_ISSET(i, e)) { error("%s: exception!", fdcon[i].c_name); confree(i); - } else if (FD_ISSET(i, r)) + } else if (FD_ISSET(i, r)) { conread(i); +/* + * Break if the read attempt in the `packet.c:packet_read_seqnr()' + * function failed because our "local" timeout was exceeded or because + * the remote host closed the connection before the packet data read + * was complete. The remote closure probably occurred because the + * LoginGraceTime was exceeded on the remote `sshd' server. + */ + if (conntimedout || connclosed) + break; + } } xfree(r); xfree(e); +/* + * If we have the "conntimedout" condition, the read attempt failed + * because the "local" timeout (set by the `packet_set_timeout()' + * function call) was exceeded. Give all hosts that currently have a + * "fdcon[s]" entry a fresh timeout. + */ + i = -1; c = TAILQ_FIRST(&tq); - while (c && (c->c_tv.tv_sec < now.tv_sec || - (c->c_tv.tv_sec == now.tv_sec && c->c_tv.tv_usec < now.tv_usec))) { - int s = c->c_fd; + + if (conntimedout) { + while (c) { + s = c->c_fd; +/* + * If i >= 0, fdcon[i] should be the first entry "touch"ed by + * the call to contouch() below. + */ + if (s == i) + break; +/* + * Save fd of first "touch"ed entry. If we encounter it again, we'll + * know that we've cycled through all of the original queue. + */ + contouch(s); /* a fresh timeout for fdcon[s] */ + if (i < 0) + i = s; + + c = TAILQ_NEXT(c, c_link); + } + + conntimedout = 0; + + return; + } + +/* + * If we have the "connclosed" condition, the read failed because the + * remote server closed the connection before sending the key. All hosts + * that currently have a viable "fdcon[s]" entry will be recycled below + * to negate the time used waiting for the server to respond. This is + * a very kludgy way to do this and should be necessary only if the + * "local" timeout value exceeds the remote servers LoginGraceTime or + * if there are a lot of very slow servers out there. + * + * Loop through the remaining open TAILQ entries. The loop covers two + * conditions: all entries for "connclosed" (described above) and the + * per entry timeout that occurs while waiting for the remote server to + * send its return greeting. + */ + while (c && (connclosed || + (c->c_tv.tv_sec < now.tv_sec || + (c->c_tv.tv_sec == now.tv_sec && + c->c_tv.tv_usec < now.tv_usec)))) { + s = c->c_fd; +/* + * If i >= 0, fdcon[i] should be the first of any new allocations that + * were made as a result of the call(s) to conrecycle() below. + */ + if (s == i) + break; + +/* + * If requested and if not recycling because of "connclosed", list this + * host as a connection time out. + */ + if (log_verbose && connclosed == 0) + logit("%s: Connection timed out.", c->c_name); + +/* + * Save fd of first new allocation. If we encounter it again, we'll + * know that we've cycled through all of the original queue. + */ + s = conrecycle(s); + if (i < 0) + i = s; c = TAILQ_NEXT(c, c_link); - conrecycle(s); } + connclosed = 0; } static void @@ -583,6 +712,19 @@ } } +/* + * Convert general remote aborts to continues while the `dispatch_run()' + * function is being executed. + */ +void +cleanup_exit(int i) +{ + if (nonfatal_fatal) + longjmp(kexjmp, -1); + else + exit(i); +} + void fatal(const char *fmt,...) { @@ -601,7 +743,7 @@ usage(void) { fprintf(stderr, - "usage: %s [-46Hv] [-f file] [-p port] [-T timeout] [-t type]\n" + "usage: %s [-46HLv] [-f file] [-p port] [-T timeout] [-t type]\n" "\t\t [host | addrlist namelist] ...\n", __progname); exit(1); @@ -629,11 +771,14 @@ if (argc <= 1) usage(); - while ((opt = getopt(argc, argv, "Hv46p:T:t:f:")) != -1) { + while ((opt = getopt(argc, argv, "HLv46p:T:t:f:")) != -1) { switch (opt) { case 'H': hash_hosts = 1; break; + case 'L': + log_verbose = 1; + break; case 'p': ssh_port = a2port(optarg); if (ssh_port <= 0) { @@ -714,7 +859,7 @@ fdlim_set(maxfd); fdcon = xcalloc(maxfd, sizeof(con)); - read_wait_nfdset = howmany(maxfd, NFDBITS); + read_wait_nfdset = howmany(maxfd + 1, NFDBITS); read_wait = xcalloc(read_wait_nfdset, sizeof(fd_mask)); for (j = 0; j < fopt_count; j++) { From balu9463 at gmail.com Tue Nov 27 22:17:24 2012 From: balu9463 at gmail.com (balu chandra) Date: Tue, 27 Nov 2012 16:47:24 +0530 Subject: OpenSSH banner doesnot display multibyte characters like korean In-Reply-To: References: Message-ID: I did not come across any UTF8 implementation of strnvis. Howver have modified strnvis() to display Multibyte char (tested the fix with Korean char). Though all calls to strnvis() could be extended to skip Multibyte char this fix is limited to skipping only for Banner message(introduced a flag for doing so). The fix is provided here for comments. [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod diff -ur openssh6.1/openbsd-compat/vis.c openssh6.1_mod/openbsd-compat/vis.c --- openssh6.1/openbsd-compat/vis.c 2012-11-27 16:12:23.986690241 +0530 +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183 +0530 @@ -50,6 +50,19 @@ (c) == '\007' || (c) == '\r' || \ isgraph((u_char)(c))))) +int multi_byte_banner = 0; +#ifdef WORDS_BIGENDIAN +#define FIRST_BYTE 0 +#define SECOND_BYTE 1 +#define THIRD_BYTE 2 +#define FOURTH_BYTE 3 +#else +#define FIRST_BYTE 3 +#define SECOND_BYTE 2 +#define THIRD_BYTE 1 +#define FOURTH_BYTE 0 +#endif + /* * vis - visually encode characters */ @@ -168,9 +181,15 @@ char *start, *end; char tbuf[5]; int c, i; + int multi_byte_num; i = 0; for (start = dst, end = start + siz - 1; (c = *src) && dst < end; ) { + multi_byte_num = 0; +/* if ( ( 0300 & c ) == 0200 ) { + *dst++ = c; + src++; + } */ if (isvisible(c)) { i = 1; *dst++ = c; @@ -185,6 +204,33 @@ } } src++; +/* Though ISO defines 6 bytes for UTF8, a valid unicode char is defined by 1-4 byte UTF8 sequence + For a one byte UTF8 char: + same as ASCII (0x00 - 0x7F) + two byte UTF8 char: + 1st byte is bit-110????? + 2nd byte is bit-10?????? + three byte UTF8 char: + 1st byte is bit-1110???? + 2nd and 3rd bytes are bit-10?????? + four byte UTF8 char: + 1st byte is bit-11110??? + 2nd, 3rd and 4th bytes are bit-10?????? */ + } else if ( multi_byte_banner && (((*src+FIRST_BYTE) & 0xE0) == 0xC0) && + ((*(src+SECOND_BYTE) & 0xC0) == 0x80) ) { + /* 2-byte char */ + multi_byte_num = 2; + } else if ( multi_byte_banner && (((*src+FIRST_BYTE) & 0xF0) == 0xE0) && + ((*(src+SECOND_BYTE) & 0xC0) == 0x80) && + ((*(src+THIRD_BYTE) & 0xC0) == 0x80) ) { + /* 3-byte char */ + multi_byte_num = 3; + } else if ( multi_byte_banner && (((*src+FIRST_BYTE) & 0xF1) == 0xF0) && + ((*(src+SECOND_BYTE) & 0xC0) == 0x80) && + ((*(src+THIRD_BYTE) & 0xC0) == 0x80) && + ((*(src+FOURTH_BYTE) & 0xC0) == 0x80) ) { + /* 4-byte char */ + multi_byte_num = 4; } else { i = vis(tbuf, c, flag, *++src) - tbuf; if (dst + i <= end) { @@ -195,6 +241,9 @@ break; } } + while (multi_byte_num--) { + *dst++ = *src++; + } } if (siz > 0) *dst = '\0'; @@ -203,6 +252,7 @@ while ((c = *src)) dst += vis(tbuf, c, flag, *++src) - tbuf; } + multi_byte_banner = 0; return (dst - start); } diff -ur openssh6.1/sshconnect2.c openssh6.1_mod/sshconnect2.c --- openssh6.1/sshconnect2.c 2012-11-27 16:11:34.084649708 +0530 +++ openssh6.1_mod/sshconnect2.c 2012-11-27 16:10:58.950588684 +0530 @@ -103,6 +103,7 @@ Kex *xxx_kex = NULL; +extern int multi_byte_banner; static int verify_host_key_callback(Key *hostkey) { @@ -535,6 +536,7 @@ if (len > 65536) len = 65536; msg = xmalloc(len * 4 + 1); /* max expansion from strnvis() */ + multi_byte_banner = 1; strnvis(msg, raw, len * 4 + 1, VIS_SAFE|VIS_OCTAL|VIS_NOSLASH); fprintf(stderr, "%s", msg); xfree(msg); Regards, Bala On 10/5/12, Darren Tucker wrote: > On Tue, Sep 25, 2012 at 9:12 PM, balu chandra wrote: >> I also found little information inthe changelog on why strnvis() was >> introduced in input_userauth_banner. Is it added to address any >> security vulnerability. > > I believe the intent was to prevent a malicious server from sending a > banner containing a terminal answerback command sequence. I'm not > aware of any UTF-8 aware equivalent of strnvis, though (if someone > knows of one we'll look at using it). > > -- > 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 roland.mainz at nrubsig.org Wed Nov 28 00:21:04 2012 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Tue, 27 Nov 2012 14:21:04 +0100 Subject: OpenSSH banner doesnot display multibyte characters like korean In-Reply-To: References: Message-ID: On Tue, Nov 27, 2012 at 12:17 PM, balu chandra wrote: > I did not come across any UTF8 implementation of strnvis. > Howver have modified strnvis() to display Multibyte char (tested the > fix with Korean char). > Though all calls to strnvis() could be extended to skip Multibyte char > this fix is limited to skipping only for Banner message(introduced a > flag for doing so). > > The fix is provided here for comments. > > [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod > diff -ur openssh6.1/openbsd-compat/vis.c openssh6.1_mod/openbsd-compat/vis.c > --- openssh6.1/openbsd-compat/vis.c 2012-11-27 16:12:23.986690241 +0530 > +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183 +0530 [snip] Erm... the problem with this code is that it is specific to UTF-8 only... but there are other multibyte encodings which are still in common use (like ja_JP.PCK/ShiftJIS on Solaris/Linux, both are used and mandated by goverment customers) and GB18030 (which is a) "modern" (e.g. not "legacy" like some people call the EUC encodings) and b) mandatory in PRC[1] (China)). AFAIK a possible fix would be to pass the data through the libc multibyte functions and filter anything out which looks like the ASCII control characters (since more or less all multibyte characters have ASCII as basis) + anything which matches |iswcntrl()| [1]=Erm... does anyone know how "Red Flag Linux" solved this ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From ras at anzio.com Wed Nov 28 00:54:47 2012 From: ras at anzio.com (Bob Rasmussen) Date: Tue, 27 Nov 2012 05:54:47 -0800 (PST) Subject: OpenSSH banner doesnot display multibyte characters like korean In-Reply-To: References: Message-ID: I believe the standard multibyte encodings (Shift-JIS, Big-5, GBK, etc.) all avoid using bytes in the control character range (0x00 to 0x1F) for the second character. Also, doesn't the SSH specification state that UTF-8 is the only allowable encoding for the banner? On Tue, 27 Nov 2012, Roland Mainz wrote: > On Tue, Nov 27, 2012 at 12:17 PM, balu chandra wrote: > > I did not come across any UTF8 implementation of strnvis. > > Howver have modified strnvis() to display Multibyte char (tested the > > fix with Korean char). > > Though all calls to strnvis() could be extended to skip Multibyte char > > this fix is limited to skipping only for Banner message(introduced a > > flag for doing so). > > > > The fix is provided here for comments. > > > > [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod > > diff -ur openssh6.1/openbsd-compat/vis.c openssh6.1_mod/openbsd-compat/vis.c > > --- openssh6.1/openbsd-compat/vis.c 2012-11-27 16:12:23.986690241 +0530 > > +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183 +0530 > [snip] > > Erm... the problem with this code is that it is specific to UTF-8 > only... but there are other multibyte encodings which are still in > common use (like ja_JP.PCK/ShiftJIS on Solaris/Linux, both are used > and mandated by goverment customers) and GB18030 (which is a) "modern" > (e.g. not "legacy" like some people call the EUC encodings) and b) > mandatory in PRC[1] (China)). > > AFAIK a possible fix would be to pass the data through the libc > multibyte functions and filter anything out which looks like the ASCII > control characters (since more or less all multibyte characters have > ASCII as basis) + anything which matches |iswcntrl()| > > [1]=Erm... does anyone know how "Red Flag Linux" solved this ? > > ---- > > Bye, > Roland > > -- > __ . . __ > (o.\ \/ /.o) roland.mainz at nrubsig.org > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 3992797 > (;O/ \/ \O;) > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From iszczesniak at gmail.com Wed Nov 28 03:29:22 2012 From: iszczesniak at gmail.com (Irek Szczesniak) Date: Tue, 27 Nov 2012 17:29:22 +0100 Subject: OpenSSH banner doesnot display multibyte characters like korean In-Reply-To: References: Message-ID: On Tue, Nov 27, 2012 at 2:54 PM, Bob Rasmussen wrote: > I believe the standard multibyte encodings (Shift-JIS, Big-5, GBK, etc.) > all avoid using bytes in the control character range (0x00 to 0x1F) for > the second character. I think they all have an ascii or ascii-like basis. > > Also, doesn't the SSH specification state that UTF-8 is the only allowable > encoding for the banner? In that case the PRC government will not allow openssh deployment for government usage. GB18030 violations are NOT tolerated. The rules for commercial software products in PRC are quite simple: you support GB18030 or their government will shut your China branch down. Permanently. There's no leeway for 'why?', 'if?' or 'can be have more time?' (than the usual two months you get when they find out that you violate their law). > > On Tue, 27 Nov 2012, Roland Mainz wrote: > >> On Tue, Nov 27, 2012 at 12:17 PM, balu chandra wrote: >> > I did not come across any UTF8 implementation of strnvis. >> > Howver have modified strnvis() to display Multibyte char (tested the >> > fix with Korean char). >> > Though all calls to strnvis() could be extended to skip Multibyte char >> > this fix is limited to skipping only for Banner message(introduced a >> > flag for doing so). >> > >> > The fix is provided here for comments. >> > >> > [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod >> > diff -ur openssh6.1/openbsd-compat/vis.c openssh6.1_mod/openbsd-compat/vis.c >> > --- openssh6.1/openbsd-compat/vis.c 2012-11-27 16:12:23.986690241 +0530 >> > +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183 +0530 >> [snip] >> >> Erm... the problem with this code is that it is specific to UTF-8 >> only... but there are other multibyte encodings which are still in >> common use (like ja_JP.PCK/ShiftJIS on Solaris/Linux, both are used >> and mandated by goverment customers) and GB18030 (which is a) "modern" >> (e.g. not "legacy" like some people call the EUC encodings) and b) >> mandatory in PRC[1] (China)). >> >> AFAIK a possible fix would be to pass the data through the libc >> multibyte functions and filter anything out which looks like the ASCII >> control characters (since more or less all multibyte characters have >> ASCII as basis) + anything which matches |iswcntrl()| >> >> [1]=Erm... does anyone know how "Red Flag Linux" solved this ? >> >> ---- >> >> Bye, >> Roland >> >> -- >> __ . . __ >> (o.\ \/ /.o) roland.mainz at nrubsig.org >> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer >> /O /==\ O\ TEL +49 641 3992797 >> (;O/ \/ \O;) >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> > > Regards, > ....Bob Rasmussen, President, Rasmussen Software, Inc. > > personal e-mail: ras at anzio.com > company e-mail: rsi at anzio.com > voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) > fax: (US) 503-624-0760 > web: http://www.anzio.com > street address: Rasmussen Software, Inc. > 10240 SW Nimbus, Suite L9 > Portland, OR 97223 USA > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Irek From iszczesniak at gmail.com Wed Nov 28 03:31:02 2012 From: iszczesniak at gmail.com (Irek Szczesniak) Date: Tue, 27 Nov 2012 17:31:02 +0100 Subject: OpenSSH banner doesnot display multibyte characters like korean In-Reply-To: References: Message-ID: On Tue, Nov 27, 2012 at 2:21 PM, Roland Mainz wrote: > On Tue, Nov 27, 2012 at 12:17 PM, balu chandra wrote: >> I did not come across any UTF8 implementation of strnvis. >> Howver have modified strnvis() to display Multibyte char (tested the >> fix with Korean char). >> Though all calls to strnvis() could be extended to skip Multibyte char >> this fix is limited to skipping only for Banner message(introduced a >> flag for doing so). >> >> The fix is provided here for comments. >> >> [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod >> diff -ur openssh6.1/openbsd-compat/vis.c openssh6.1_mod/openbsd-compat/vis.c >> --- openssh6.1/openbsd-compat/vis.c 2012-11-27 16:12:23.986690241 +0530 >> +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183 +0530 > [snip] > > Erm... the problem with this code is that it is specific to UTF-8 > only... but there are other multibyte encodings which are still in > common use (like ja_JP.PCK/ShiftJIS on Solaris/Linux, both are used > and mandated by goverment customers) and GB18030 (which is a) "modern" > (e.g. not "legacy" like some people call the EUC encodings) and b) > mandatory in PRC[1] (China)). > > AFAIK a possible fix would be to pass the data through the libc > multibyte functions and filter anything out which looks like the ASCII > control characters (since more or less all multibyte characters have > ASCII as basis) + anything which matches |iswcntrl()| > > [1]=Erm... does anyone know how "Red Flag Linux" solved this ? Red Flag Linux has disabled everything, including strnvis(), which interfered with GB18030. Irek From gsustek at gmail.com Wed Nov 28 04:04:18 2012 From: gsustek at gmail.com (Goran Sustek) Date: Tue, 27 Nov 2012 18:04:18 +0100 Subject: Public Key Authentication In-Reply-To: References: Message-ID: Hi, i setup X509 certificate patch with openssh 6.1p1. ssh user1 at HOST -i user2.pem So , both users are root, admins of this OS. If i do not know user1 password i can not login with ssh to server. i can su to server but this will be in logs. public key authentification like this bellow have some identificatio issue. If i copy my authorized key(user2) to user1 authorized key and try login with ssh like this ssh user1 at HOST -i user2.pem i will login like him..and this is BAD. I wan't to configure my ssh server just for certificate authentification, and that way that i can't impersionate some other user. Here is log. Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug1: fd 4 clearing O_NONBLOCK Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug1: Forked child 11534544. Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: send_rexec_state: entering fd = 7 config len 387 Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: ssh_msg_send: type 0 Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: send_rexec_state: done Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: inetd sockets after dupping: 5, 5 Nov 27 17:46:45 intrat10 auth|security:info sshd[11534544]: Connection from XX.XX.XX.XX port 58271 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1 PKIX Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: match: OpenSSH_6.1 PKIX pat OpenSSH* Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: Enabling compatibility mode for protocol 2.0 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: Local version string SSH-2.0-OpenSSH_6.1 PKIX Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: fd 5 setting O_NONBLOCK Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_sandbox_init: preparing rlimit sandbox Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: Network child is on pid 13041860 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: preauth child monitor started Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: privsep user:group 202:201 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: permanently_set_uid: 202/201 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_KEXINIT sent [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_KEXINIT received [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: reserved 0 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: x509v3-sign-rsa,ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa,x509v3-sign-dss,ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: mac_setup: found hmac-md5 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 0 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive_expect entering: type 1 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 0 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_moduli: got parameters: 1024 1024 8192 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 1 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: monitor_read: 0 used once, disabling now Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_choose_dh: remaining 0 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: dh_gen_key: priv key bits set: 125/256 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: bits set: 511/1024 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: bits set: 498/1024 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_key_sign entering [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 4 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive_expect entering: type 5 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 4 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_sign Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_sign: signature 20045ef8(271) Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 5 Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: monitor_read: 4 used once, disabling now Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: kex_derive_keys [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: set_newkeys: mode 1 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_NEWKEYS sent [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: set_newkeys: mode 0 [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: SSH2_MSG_NEWKEYS received [preauth] Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: KEX done [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug1: userauth-request for user user1 service ssh-connection method none [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug1: attempt 0 failures 0 [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_getpwnamallow entering [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 6 [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive_expect entering: type 7 [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 6 Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_pwnamallow Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: Trying to reverse map address 10.144.33.20. Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: parse_server_config: config reprocess config len 387 Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: AIX/setauthdb set registry 'LDAP' Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: aix_restoreauthdb: restoring old registry '' Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: AIX/loginrestrictions returned 0 msg (none) Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 7 Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: monitor_read: 6 used once, disabling now Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: input_userauth_request: setting up authctxt for user1 [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_inform_authserv entering [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 3 [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: input_userauth_request: try method none [preauth] Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 3 Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_authserv: service=ssh-connection, style= Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: monitor_read: 3 used once, disabling now Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: userauth-request for user user1 service ssh-connection method publickey [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: attempt 1 failures 0 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: input_userauth_request: try method publickey [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: key_from_blob(..., 1268) [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_from_blob: We have 1268 bytes available in BIO [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509_to_key: X509_get_pubkey done! [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_key_allowed entering [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 20 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive_expect entering: type 21 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 20 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_keyallowed entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: key_from_blob(..., 1268) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_from_blob: We have 1268 bytes available in BIO Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509_to_key: X509_get_pubkey done! Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_keyallowed: key_from_blob: 2008b2d8 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: temporarily_use_uid: 417/230 (e=0/0) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: trying public key file /home/user1/.ssh/authorized_keys Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: fd 4 clearing O_NONBLOCK Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_from_subject(9, [subject= C = XX, O = XX, OU = XX, CN = user2\n]) called Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_from_subject: subject=[C = XX, O = XX, OU = XX, CN = user2\n] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=2 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=4 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=12 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=7 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_str2X509NAME: return 1 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_from_subject: return 2008b678 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: key_match:found matching certificate Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: matching key found: file /home/user1/.ssh/authorized_keys, line 1 Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: Found matching RSA+cert key: 47:d7:9f:7c:e4:a6:df:67:be:bb:82:8f:91:99:12:f2 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509cert_check: for 'C=XX,O=XX,OU=XX,CN=user2' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=user2 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_ocsp_validate: for 'C=XX,O=XX,OU=XX,CN=user2' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_ocsp_validate: none Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_key_verify entering [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 22 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive_expect entering: type 23 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 22 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: key_from_blob(..., 1268) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509key_from_blob: We have 1268 bytes available in BIO Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: x509_to_key: X509_get_pubkey done! Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509_verify: signature format = x509v3-sign-rsa Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509_verify: md=rsa-sha1, loc=0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509cert_check: for 'C=XX,O=XX,OU=XX,CN=user2' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=user2 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_ocsp_validate: for 'C=XX,O=XX,OU=XX,CN=user2' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_ocsp_validate: none Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509cert_check: return 1(trusted) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: ssh_x509_verify: return 1 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_keyverify: key 2008ca68 signature verified Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 23 Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: Accepted publickey for user1 from XX.XX.XX.XX. port 58271 ssh2 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: AIX/setauthdb set registry 'LDAP' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: AIX/loginsuccess: msg Last unsuccessful login: \310et 22 Stu 2012 13:02:41 on ssh from user1.host.com\nLast login: Uto 27 Stu 2012 17:29:40 on /dev/pts/5 from intrat10.zbo\n Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: aix_restoreauthdb: restoring old registry '' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: userauth_pubkey: authenticated 1 pkalg x509v3-sign-rsa [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_send_keystate: Sending new keys: 20046118 20045e78 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_newkeys_to_blob: converting 20046118 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_newkeys_to_blob: converting 20045e78 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_send_keystate: New keys have been sent [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_send_keystate: Sending compression state [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 24 [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_send_keystate: Finished sending state [preauth] Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: monitor_read_log: child log fd closed Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: monitor_child_preauth: user1 has been authenticated by privileged process Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_get_keystate: Waiting for new keys Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive_expect entering: type 24 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_newkeys_from_blob: 2006cfa8(118) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: mac_setup: found hmac-md5 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_get_keystate: Waiting for second key Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_newkeys_from_blob: 2006cfa8(118) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: mac_setup: found hmac-md5 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_get_keystate: Getting compression state Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_get_keystate: Getting Network I/O buffers Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: User child is on pid 13041862 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: AIX/UsrInfo: set len 29 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: permanently_set_uid: 417/230 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: set_newkeys: mode 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: set_newkeys: mode 1 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: Entering interactive session for SSH2. Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: fd 8 setting O_NONBLOCK Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: fd 9 setting O_NONBLOCK Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: server_init_dispatch_20 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: input_session_request Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: channel 0: new [server-session] Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: session_new: allocate (allocated 0 max 10) Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: session_unused: session id 0 unused Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_new: session 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_open: channel 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_open: session 0: link with channel 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: server_input_channel_open: confirm session Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: server_input_channel_req: channel 0 request pty-req reply 1 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_by_channel: session 0 channel 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_input_channel_req: session 0 req pty-req Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: Allocating pty. Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: mm_request_send entering: type 25 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: mm_request_receive_expect entering: type 26 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: mm_request_receive entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_receive entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: monitor_read: checking request 25 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_pty entering Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: session_new: allocate (allocated 0 max 10) Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: session_unused: session id 0 unused Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: session_new: session 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: AIX/setauthdb set registry 'LDAP' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: AIX/loginsuccess: msg Last unsuccessful login: \310et 22 Stu 2012 13:02:41 on ssh from user1.host.com\nLast login: Uto 27 Stu 2012 17:46:55 on ssh from intrat10.zbo\n Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: aix_restoreauthdb: restoring old registry '' Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_request_send entering: type 26 Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: mm_answer_pty: tty /dev/pts/5 ptyfd 6 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_pty_req: session 0 alloc /dev/pts/5 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: server_input_channel_req: channel 0 request shell reply 1 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_by_channel: session 0 channel 0 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: session_input_channel_req: session 0 req shell Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: fd 5 setting TCP_NODELAY Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: packet_set_tos: set IP_TOS 0x10 Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: channel 0: rfd 12 isatty Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: fd 12 setting O_NONBLOCK Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: fd 10 is O_NONBLOCK From raubvogel at gmail.com Wed Nov 28 04:35:16 2012 From: raubvogel at gmail.com (Mauricio Tavares) Date: Tue, 27 Nov 2012 12:35:16 -0500 Subject: Public Key Authentication In-Reply-To: References: Message-ID: On Tue, Nov 27, 2012 at 12:04 PM, Goran Sustek wrote: > Hi, i setup X509 certificate patch with openssh 6.1p1. > > ssh user1 at HOST -i user2.pem > > So , both users are root, admins of this OS. > > If i do not know user1 password i can not login with ssh to server. i > can su to server but this will be in logs. > > public key authentification like this bellow have some identificatio > issue. If i copy my authorized key(user2) to user1 authorized key and > try login with ssh like this ssh user1 at HOST -i user2.pem i will login > like him..and this is BAD. > How is that bad? What you did was set the same authentication for both accounts, hence the file is called "authorized_keys". The same outcome would happen if you set both accounts with the same password and authenticate using it. > I wan't to configure my ssh server just for certificate > authentification, and that way that i can't impersionate some other > user. > How about if you had different public/private key pairs for the different accounts? > Here is log. > > > > > Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug1: > fd 4 clearing O_NONBLOCK > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > rexec start in 4 out 4 newsock 4 pipe 6 sock 7 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug1: > Forked child 11534544. > Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: > send_rexec_state: entering fd = 7 config len 387 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: > ssh_msg_send: type 0 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: > send_rexec_state: done > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > inetd sockets after dupping: 5, 5 > Nov 27 17:46:45 intrat10 auth|security:info sshd[11534544]: Connection > from XX.XX.XX.XX port 58271 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > Client protocol version 2.0; client software version OpenSSH_6.1 PKIX > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > match: OpenSSH_6.1 PKIX pat OpenSSH* > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > Enabling compatibility mode for protocol 2.0 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > Local version string SSH-2.0-OpenSSH_6.1 PKIX > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > fd 5 setting O_NONBLOCK > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_sandbox_init: preparing rlimit sandbox > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > Network child is on pid 13041860 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > preauth child monitor started > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > privsep user:group 202:201 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > permanently_set_uid: 202/201 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > list_hostkey_types: ssh-rsa,ssh-dss [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_KEXINIT sent [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_KEXINIT received [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: ssh-rsa,ssh-dss [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: none,zlib at openssh.com [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: none,zlib at openssh.com [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: first_kex_follows 0 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: reserved 0 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > x509v3-sign-rsa,ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa,x509v3-sign-dss,ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > mac_setup: found hmac-md5 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > kex: server->client aes128-ctr hmac-md5 none [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 0 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive_expect entering: type 1 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 0 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_moduli: got parameters: 1024 1024 8192 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 1 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > monitor_read: 0 used once, disabling now > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_choose_dh: remaining 0 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > dh_gen_key: priv key bits set: 125/256 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > bits set: 511/1024 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > bits set: 498/1024 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_key_sign entering [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 4 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive_expect entering: type 5 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 4 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_sign > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_sign: signature 20045ef8(271) > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 5 > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > monitor_read: 4 used once, disabling now > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > kex_derive_keys [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > set_newkeys: mode 1 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_NEWKEYS sent [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > expecting SSH2_MSG_NEWKEYS [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: > set_newkeys: mode 0 [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > SSH2_MSG_NEWKEYS received [preauth] > Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: > KEX done [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug1: > userauth-request for user user1 service ssh-connection method none > [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug1: > attempt 0 failures 0 [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_getpwnamallow entering [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 6 [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive_expect entering: type 7 [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 6 > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_pwnamallow > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > Trying to reverse map address 10.144.33.20. > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: > parse_server_config: config reprocess config len 387 > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > AIX/setauthdb set registry 'LDAP' > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > aix_restoreauthdb: restoring old registry '' > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > AIX/loginrestrictions returned 0 msg (none) > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 7 > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: > monitor_read: 6 used once, disabling now > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: > input_userauth_request: setting up authctxt for user1 [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_inform_authserv entering [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 3 [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: > input_userauth_request: try method none [preauth] > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 3 > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_authserv: service=ssh-connection, style= > Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: > monitor_read: 3 used once, disabling now > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > userauth-request for user user1 service ssh-connection method > publickey [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > attempt 1 failures 0 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: > input_userauth_request: try method publickey [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > key_from_blob(..., 1268) [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_from_blob: We have 1268 bytes available in BIO [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509_to_key: X509_get_pubkey done! [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_key_allowed entering [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 20 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive_expect entering: type 21 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 20 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_keyallowed entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > key_from_blob(..., 1268) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_from_blob: We have 1268 bytes available in BIO > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509_to_key: X509_get_pubkey done! > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_keyallowed: key_from_blob: 2008b2d8 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > temporarily_use_uid: 417/230 (e=0/0) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > trying public key file /home/user1/.ssh/authorized_keys > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > fd 4 clearing O_NONBLOCK > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_from_subject(9, [subject= C = XX, O = XX, OU = XX, CN = > user2\n]) called > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_from_subject: subject=[C = XX, O = XX, OU = XX, CN = user2\n] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=2 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=4 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=12 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=7 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_str2X509NAME: return 1 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_from_subject: return 2008b678 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > key_match:found matching certificate > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > matching key found: file /home/user1/.ssh/authorized_keys, line 1 > Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: Found > matching RSA+cert key: 47:d7:9f:7c:e4:a6:df:67:be:bb:82:8f:91:99:12:f2 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509cert_check: for 'C=XX,O=XX,OU=XX,CN=user2' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=user2 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_ocsp_validate: for 'C=XX,O=XX,OU=XX,CN=user2' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_ocsp_validate: none > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_key_verify entering [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 22 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive_expect entering: type 23 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 22 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > key_from_blob(..., 1268) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509key_from_blob: We have 1268 bytes available in BIO > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > x509_to_key: X509_get_pubkey done! > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509_verify: signature format = x509v3-sign-rsa > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509_verify: md=rsa-sha1, loc=0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509cert_check: for 'C=XX,O=XX,OU=XX,CN=user2' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=user2 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_ocsp_validate: for 'C=XX,O=XX,OU=XX,CN=user2' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_ocsp_validate: none > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509cert_check: return 1(trusted) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > ssh_x509_verify: return 1 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_keyverify: key 2008ca68 signature verified > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 23 > Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: Accepted > publickey for user1 from XX.XX.XX.XX. port 58271 ssh2 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > AIX/setauthdb set registry 'LDAP' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > AIX/loginsuccess: msg Last unsuccessful login: \310et 22 Stu 2012 > 13:02:41 on ssh from user1.host.com\nLast login: Uto 27 Stu 2012 > 17:29:40 on /dev/pts/5 from intrat10.zbo\n > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > aix_restoreauthdb: restoring old registry '' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: > userauth_pubkey: authenticated 1 pkalg x509v3-sign-rsa [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_send_keystate: Sending new keys: 20046118 20045e78 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_newkeys_to_blob: converting 20046118 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_newkeys_to_blob: converting 20045e78 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_send_keystate: New keys have been sent [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_send_keystate: Sending compression state [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 24 [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_send_keystate: Finished sending state [preauth] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > monitor_read_log: child log fd closed > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > monitor_child_preauth: user1 has been authenticated by privileged > process > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_get_keystate: Waiting for new keys > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive_expect entering: type 24 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_newkeys_from_blob: 2006cfa8(118) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: > mac_setup: found hmac-md5 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_get_keystate: Waiting for second key > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_newkeys_from_blob: 2006cfa8(118) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: > mac_setup: found hmac-md5 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_get_keystate: Getting compression state > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_get_keystate: Getting Network I/O buffers > Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: User child > is on pid 13041862 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > AIX/UsrInfo: set len 29 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > permanently_set_uid: 417/230 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > set_newkeys: mode 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > set_newkeys: mode 1 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > Entering interactive session for SSH2. > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > fd 8 setting O_NONBLOCK > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > fd 9 setting O_NONBLOCK > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > server_init_dispatch_20 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > input_session_request > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > channel 0: new [server-session] > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > session_new: allocate (allocated 0 max 10) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > session_unused: session id 0 unused > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_new: session 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_open: channel 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_open: session 0: link with channel 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > server_input_channel_open: confirm session > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > server_input_global_request: rtype no-more-sessions at openssh.com > want_reply 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > server_input_channel_req: channel 0 request pty-req reply 1 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_by_channel: session 0 channel 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_input_channel_req: session 0 req pty-req > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > Allocating pty. > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > mm_request_send entering: type 25 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > mm_pty_allocate: waiting for MONITOR_ANS_PTY > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > mm_request_receive_expect entering: type 26 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > mm_request_receive entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_receive entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > monitor_read: checking request 25 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_pty entering > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: > session_new: allocate (allocated 0 max 10) > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > session_unused: session id 0 unused > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > session_new: session 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > AIX/setauthdb set registry 'LDAP' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: > AIX/loginsuccess: msg Last unsuccessful login: \310et 22 Stu 2012 > 13:02:41 on ssh from user1.host.com\nLast login: Uto 27 Stu 2012 > 17:46:55 on ssh from intrat10.zbo\n > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > aix_restoreauthdb: restoring old registry '' > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_request_send entering: type 26 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: > mm_answer_pty: tty /dev/pts/5 ptyfd 6 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_pty_req: session 0 alloc /dev/pts/5 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > server_input_channel_req: channel 0 request shell reply 1 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_by_channel: session 0 channel 0 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: > session_input_channel_req: session 0 req shell > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > fd 5 setting TCP_NODELAY > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > packet_set_tos: set IP_TOS 0x10 > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > channel 0: rfd 12 isatty > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: > fd 12 setting O_NONBLOCK > Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: > fd 10 is O_NONBLOCK > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From gsustek at gmail.com Wed Nov 28 04:52:19 2012 From: gsustek at gmail.com (Goran Sustek) Date: Tue, 27 Nov 2012 18:52:19 +0100 Subject: Public Key Authentication In-Reply-To: References: Message-ID: Hi, this is bad because changing password is legitimate action like su and i just know this password, We audit this action. In both cases i can't impersonate user1 knowing his old password. And just one copy of authorized_keys file impersonate user1, without knowing anything,changing anything(then copy back user1 original authorized keys file). I lookin something like this. "The documentation for OpenSSH certificates (introduced in OpenSSH 5.4) " http://blog.habets.pp.se/2011/07/OpenSSH-certificates ssh-keygen -s user_ca -I user_thomas -n thomas,thomas2 -V +52w /path/to/id_rsa.pub Valid: from 2011-07-07T15:37:00 to 2012-07-05T15:38:11 Principals: thomas thomas2 Critical Options: permit-agent-forwarding permit-port-forwarding Now, my prinicpals(or cn, or some other certificate atribute) in my certificate must corespond to my userid on OS...Just i have my certificate,my publickeys,and just i know my pin for my PKCS11 storage card. Regards, Goran. On Tue, Nov 27, 2012 at 6:35 PM, Mauricio Tavares wrote: > On Tue, Nov 27, 2012 at 12:04 PM, Goran Sustek wrote: >> Hi, i setup X509 certificate patch with openssh 6.1p1. >> >> ssh user1 at HOST -i user2.pem >> >> So , both users are root, admins of this OS. >> >> If i do not know user1 password i can not login with ssh to server. i >> can su to server but this will be in logs. >> >> public key authentification like this bellow have some identificatio >> issue. If i copy my authorized key(user2) to user1 authorized key and >> try login with ssh like this ssh user1 at HOST -i user2.pem i will login >> like him..and this is BAD. >> > How is that bad? What you did was set the same authentication > for both accounts, hence the file is called "authorized_keys". The > same outcome would happen if you set both accounts with the same > password and authenticate using it. > >> I wan't to configure my ssh server just for certificate >> authentification, and that way that i can't impersionate some other >> user. >> > How about if you had different public/private key pairs for the > different accounts? > >> Here is log. >> >> >> >> >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug1: >> fd 4 clearing O_NONBLOCK >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> rexec start in 4 out 4 newsock 4 pipe 6 sock 7 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug1: >> Forked child 11534544. >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: >> send_rexec_state: entering fd = 7 config len 387 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: >> ssh_msg_send: type 0 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[10289316]: debug3: >> send_rexec_state: done >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> inetd sockets after dupping: 5, 5 >> Nov 27 17:46:45 intrat10 auth|security:info sshd[11534544]: Connection >> from XX.XX.XX.XX port 58271 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> Client protocol version 2.0; client software version OpenSSH_6.1 PKIX >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> match: OpenSSH_6.1 PKIX pat OpenSSH* >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> Enabling compatibility mode for protocol 2.0 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> Local version string SSH-2.0-OpenSSH_6.1 PKIX >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> fd 5 setting O_NONBLOCK >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_sandbox_init: preparing rlimit sandbox >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> Network child is on pid 13041860 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> preauth child monitor started >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> privsep user:group 202:201 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> permanently_set_uid: 202/201 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> list_hostkey_types: ssh-rsa,ssh-dss [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_KEXINIT sent [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_KEXINIT received [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: ssh-rsa,ssh-dss [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: none,zlib at openssh.com [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: none,zlib at openssh.com [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: first_kex_follows 0 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: reserved 0 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> x509v3-sign-rsa,ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa,x509v3-sign-dss,ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_parse_kexinit: >> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> mac_setup: found hmac-md5 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> kex: server->client aes128-ctr hmac-md5 none [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 0 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive_expect entering: type 1 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 0 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_moduli: got parameters: 1024 1024 8192 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 1 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> monitor_read: 0 used once, disabling now >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_choose_dh: remaining 0 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> dh_gen_key: priv key bits set: 125/256 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> bits set: 511/1024 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> bits set: 498/1024 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_key_sign entering [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 4 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive_expect entering: type 5 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 4 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_sign >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_sign: signature 20045ef8(271) >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 5 >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> monitor_read: 4 used once, disabling now >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> kex_derive_keys [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> set_newkeys: mode 1 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_NEWKEYS sent [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> expecting SSH2_MSG_NEWKEYS [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug2: >> set_newkeys: mode 0 [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> SSH2_MSG_NEWKEYS received [preauth] >> Nov 27 17:46:45 intrat10 auth|security:debug sshd[11534544]: debug1: >> KEX done [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug1: >> userauth-request for user user1 service ssh-connection method none >> [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug1: >> attempt 0 failures 0 [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_getpwnamallow entering [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 6 [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive_expect entering: type 7 [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 6 >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_pwnamallow >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> Trying to reverse map address 10.144.33.20. >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: >> parse_server_config: config reprocess config len 387 >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> AIX/setauthdb set registry 'LDAP' >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> aix_restoreauthdb: restoring old registry '' >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> AIX/loginrestrictions returned 0 msg (none) >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 7 >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: >> monitor_read: 6 used once, disabling now >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: >> input_userauth_request: setting up authctxt for user1 [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_inform_authserv entering [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 3 [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: >> input_userauth_request: try method none [preauth] >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 3 >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_authserv: service=ssh-connection, style= >> Nov 27 17:46:46 intrat10 auth|security:debug sshd[11534544]: debug2: >> monitor_read: 3 used once, disabling now >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> userauth-request for user user1 service ssh-connection method >> publickey [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> attempt 1 failures 0 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: >> input_userauth_request: try method publickey [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> key_from_blob(..., 1268) [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_from_blob: We have 1268 bytes available in BIO [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509_to_key: X509_get_pubkey done! [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_key_allowed entering [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 20 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive_expect entering: type 21 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 20 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_keyallowed entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> key_from_blob(..., 1268) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_from_blob: We have 1268 bytes available in BIO >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509_to_key: X509_get_pubkey done! >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_keyallowed: key_from_blob: 2008b2d8 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> temporarily_use_uid: 417/230 (e=0/0) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> trying public key file /home/user1/.ssh/authorized_keys >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> fd 4 clearing O_NONBLOCK >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_from_subject(9, [subject= C = XX, O = XX, OU = XX, CN = >> user2\n]) called >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_from_subject: subject=[C = XX, O = XX, OU = XX, CN = user2\n] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=2 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=4 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=12 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_X509_NAME_add_entry_by_NID: type=ASCII, k=7 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_str2X509NAME: return 1 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_from_subject: return 2008b678 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> key_match:found matching certificate >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> matching key found: file /home/user1/.ssh/authorized_keys, line 1 >> Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: Found >> matching RSA+cert key: 47:d7:9f:7c:e4:a6:df:67:be:bb:82:8f:91:99:12:f2 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509cert_check: for 'C=XX,O=XX,OU=XX,CN=user2' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=user2 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_ocsp_validate: for 'C=XX,O=XX,OU=XX,CN=user2' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_ocsp_validate: none >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_key_verify entering [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 22 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive_expect entering: type 23 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 22 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> key_from_blob(..., 1268) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509key_from_blob: We have 1268 bytes available in BIO >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> x509_to_key: X509_get_pubkey done! >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509_verify: signature format = x509v3-sign-rsa >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509_verify: md=rsa-sha1, loc=0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509cert_check: for 'C=XX,O=XX,OU=XX,CN=user2' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Issuer: C=XX,O=XX,OU=XX,CN=XX >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509revoked_cb: Subject: C=XX,O=XX,OU=XX,CN=user2 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_ocsp_validate: for 'C=XX,O=XX,OU=XX,CN=user2' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_ocsp_validate: none >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509cert_check: return 1(trusted) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> ssh_x509_verify: return 1 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_keyverify: key 2008ca68 signature verified >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 23 >> Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: Accepted >> publickey for user1 from XX.XX.XX.XX. port 58271 ssh2 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> AIX/setauthdb set registry 'LDAP' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> AIX/loginsuccess: msg Last unsuccessful login: \310et 22 Stu 2012 >> 13:02:41 on ssh from user1.host.com\nLast login: Uto 27 Stu 2012 >> 17:29:40 on /dev/pts/5 from intrat10.zbo\n >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> aix_restoreauthdb: restoring old registry '' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: >> userauth_pubkey: authenticated 1 pkalg x509v3-sign-rsa [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_send_keystate: Sending new keys: 20046118 20045e78 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_newkeys_to_blob: converting 20046118 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_newkeys_to_blob: converting 20045e78 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_send_keystate: New keys have been sent [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_send_keystate: Sending compression state [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 24 [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_send_keystate: Finished sending state [preauth] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> monitor_read_log: child log fd closed >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> monitor_child_preauth: user1 has been authenticated by privileged >> process >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_get_keystate: Waiting for new keys >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive_expect entering: type 24 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_newkeys_from_blob: 2006cfa8(118) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: >> mac_setup: found hmac-md5 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_get_keystate: Waiting for second key >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_newkeys_from_blob: 2006cfa8(118) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: >> mac_setup: found hmac-md5 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_get_keystate: Getting compression state >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_get_keystate: Getting Network I/O buffers >> Nov 27 17:46:55 intrat10 auth|security:info sshd[11534544]: User child >> is on pid 13041862 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> AIX/UsrInfo: set len 29 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> permanently_set_uid: 417/230 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> set_newkeys: mode 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> set_newkeys: mode 1 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> Entering interactive session for SSH2. >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> fd 8 setting O_NONBLOCK >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> fd 9 setting O_NONBLOCK >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> server_init_dispatch_20 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> input_session_request >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> channel 0: new [server-session] >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> session_new: allocate (allocated 0 max 10) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> session_unused: session id 0 unused >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_new: session 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_open: channel 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_open: session 0: link with channel 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> server_input_channel_open: confirm session >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> server_input_global_request: rtype no-more-sessions at openssh.com >> want_reply 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> server_input_channel_req: channel 0 request pty-req reply 1 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_by_channel: session 0 channel 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_input_channel_req: session 0 req pty-req >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> Allocating pty. >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> mm_request_send entering: type 25 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> mm_pty_allocate: waiting for MONITOR_ANS_PTY >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> mm_request_receive_expect entering: type 26 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> mm_request_receive entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_receive entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> monitor_read: checking request 25 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_pty entering >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug2: >> session_new: allocate (allocated 0 max 10) >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> session_unused: session id 0 unused >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> session_new: session 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> AIX/setauthdb set registry 'LDAP' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug1: >> AIX/loginsuccess: msg Last unsuccessful login: \310et 22 Stu 2012 >> 13:02:41 on ssh from user1.host.com\nLast login: Uto 27 Stu 2012 >> 17:46:55 on ssh from intrat10.zbo\n >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> aix_restoreauthdb: restoring old registry '' >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_request_send entering: type 26 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[11534544]: debug3: >> mm_answer_pty: tty /dev/pts/5 ptyfd 6 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_pty_req: session 0 alloc /dev/pts/5 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> server_input_channel_req: channel 0 request shell reply 1 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_by_channel: session 0 channel 0 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug1: >> session_input_channel_req: session 0 req shell >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> fd 5 setting TCP_NODELAY >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> packet_set_tos: set IP_TOS 0x10 >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> channel 0: rfd 12 isatty >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug2: >> fd 12 setting O_NONBLOCK >> Nov 27 17:46:55 intrat10 auth|security:debug sshd[13041862]: debug3: >> fd 10 is O_NONBLOCK >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From keisial at gmail.com Wed Nov 28 08:12:44 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 27 Nov 2012 22:12:44 +0100 Subject: OpenSSH banner doesnot display multibyte characters like korean In-Reply-To: References: Message-ID: <50B52CCC.5000309@gmail.com> Bob Rasmussen wrote >> Also, doesn't the SSH specification state that UTF-8 is the only allowable >> encoding for the banner? It does: > string message in ISO-10646 UTF-8 encoding [RFC3629 ] http://tools.ietf.org/html/rfc4252#section-5.4 Irek Szczesniak wrote: > In that case the PRC government will not allow openssh deployment for > government usage. GB18030 violations are NOT tolerated. The rules for > commercial software products in PRC are quite simple: you support > GB18030 or their government will shut your China branch down. > Permanently. There's no leeway for 'why?', 'if?' or 'can be have more > time?' (than the usual two months you get when they find out that you > violate their law). If you *must* show the characters in GB18030, then the ssh client should translate the banner from UTF-8 to GB18030. The protocol bytes are in UTF-8, but that is an implementation detail, just as windows workstations using UTF-16 on its filesystem. From djm at mindrot.org Wed Nov 28 17:03:27 2012 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Nov 2012 17:03:27 +1100 (EST) Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> Message-ID: On Fri, 23 Nov 2012, Damien Miller wrote: > Here's a (lightly tested) patch for PKCS#11 host keys. At the moment, the > keys are loaded using a fixed PIN of 0000, but there's probably a better > way to do it. I don't really want sshd to block at startup time while looking > for a password, but my PKCS#15-fu isn't good enough to know how to create > keys that don't require a PIN at all. Thinking about it some more, I've come to the conclusion that this patch is insufficient because it offers no way to select which keys from the token will end up as SSH hostkeys. An administrator who has gone to the trouble of setting up some sort of token for the storage of SSH keys may well want to use it with independent keys for other purposes (e.g. TLS keys). So we need some way of selecting keys from the token for use. I don't like doing it via reader ID / slot, as readers on USB busses can move around - IMO it's safer to explicitly specify the public key. Perhaps like: HostKeyPKCS11 /path/to/pkcs11.so /path/to/hostkey.pub Which would load only the key specified by hostkey.pub from the token. What do you think? -d From amesh at juniper.net Wed Nov 28 17:49:15 2012 From: amesh at juniper.net (Arthur Mesh) Date: Tue, 27 Nov 2012 22:49:15 -0800 Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> Message-ID: <20121128064915.GF74977@juniper.net> On Wed, Nov 28, 2012 at 05:03:27PM +1100, Damien Miller wrote: > HostKeyPKCS11 /path/to/pkcs11.so /path/to/hostkey.pub > > Which would load only the key specified by hostkey.pub from the token. > > What do you think? That should work, but may not be the most optimal way. One may argue that a better approach is to query for a specific Key Identifier, or CKA_ID in pkcs11 speak. One may use C_FindObjects() to query for key objects with particular CKA_ID. -- Arthur Mesh Juniper Networks +1 408 936-4968 From a.holway at syseleven.de Wed Nov 28 19:31:33 2012 From: a.holway at syseleven.de (Andrew Holway) Date: Wed, 28 Nov 2012 09:31:33 +0100 Subject: Strange ssh thing - Keys suddenly decide to stop working. Message-ID: <22026611-F416-413B-BB70-468A21329501@syseleven.de> ## Hi, ## I have a script that spawns a process on a remote virtuozzo(container based vm thing) machine then waits for it to complete. Its a bit hacked about but you should be able to get the idea. function spawntpcc { while ! ssh -v $vmhostnameprefix$1 < /cm/shared/tpcc/"$runname"/"$3"/"$vmhostnameprefix""$1"-result-"$2" EOF do sleep 60 done } for ((iteration=1; iteration < 13; iteration++)); do for warehouses in {10..100..10} do for ((subiteration=1; subiteration <= $iteration; subiteration++)); do #we have to do some arithmetic to spawn tpcc within the VM on the right physical node ode001=$(($subiteration)) #two significant digits for the hostname node001=$(printf %02d%s ${a%.*} ${a##*.} $ode001) ssh -v $vmhostnameprefix$node001 "mkdir -p $tpccrootdir/$runname/$drive/$warehouses" spawntpcc $node001 $iteration $drive $warehouses & done sleep 1 wait sleep 5 done done ## The script runs fine, the keys are working perfectly util a seemingly random time when it cant read the keys any more and is asking for a passphrase (with a gnome util). The first time it fails after 6 iterations and this time after 4 iterations. debug1: read_passphrase: can't open /dev/tty: No such device or address debug1: permanently_drop_suid: 0 (gnome-ssh-askpass:26625): Gtk-WARNING **: cannot open display: localhost:11.0 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Permission denied, please try again. debug1: read_passphrase: can' t open /dev/tty: No such device or address ## This is the output of the script at the point where it fails: http://pastie.org/5446639. ## Any ideas? ## Thanks, ## Andrew From a.holway at syseleven.de Wed Nov 28 21:22:46 2012 From: a.holway at syseleven.de (Andrew Holway) Date: Wed, 28 Nov 2012 11:22:46 +0100 Subject: Strange ssh thing - Keys suddenly decide to stop working. In-Reply-To: <22026611-F416-413B-BB70-468A21329501@syseleven.de> References: <22026611-F416-413B-BB70-468A21329501@syseleven.de> Message-ID: Hi, I was having agent hell. please ignore :) Thanks, Andrew On Nov 28, 2012, at 10:18 AM, Andrew Holway wrote: > ## Hi, > > ## I have a script that spawns a process on a remote virtuozzo(container based vm thing) machine then waits for it to complete. Its a bit hacked about but you should be able to get the idea. > > function spawntpcc { > while ! ssh -v $vmhostnameprefix$1 < "$tpccrootdir"/tpcc-mysql/tpcc_start -h localhost -d tpcc -u root -w "$3" -c 8 -r "$warmuptime" -l "$runtime" > /cm/shared/tpcc/"$runname"/"$3"/"$vmhostnameprefix""$1"-result-"$2" > EOF > do > sleep 60 > done > } > > > for ((iteration=1; iteration < 13; iteration++)); > do > for warehouses in {10..100..10} > do > for ((subiteration=1; subiteration <= $iteration; subiteration++)); > do > #we have to do some arithmetic to spawn tpcc within the VM on the right physical node > ode001=$(($subiteration)) > #two significant digits for the hostname > node001=$(printf %02d%s ${a%.*} ${a##*.} $ode001) > ssh -v $vmhostnameprefix$node001 "mkdir -p $tpccrootdir/$runname/$drive/$warehouses" > spawntpcc $node001 $iteration $drive $warehouses & > done > sleep 1 > wait > sleep 5 > done > done > > ## The script runs fine, the keys are working perfectly util a seemingly random time when it cant read the keys any more and is asking for a passphrase (with a gnome util). The first time it fails after 6 iterations and this time after 4 iterations. > > debug1: read_passphrase: > can't open /dev/tty: No such device or address > debug1: permanently_drop_suid: 0 > > (gnome-ssh-askpass:26625): Gtk-WARNING **: cannot open display: localhost:11.0 > debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password > Permission denied, please try again. > debug1: read_passphrase: can' > t open /dev/tty: No such device or address > > > ## This is the output of the script at the point where it fails: http://pastie.org/5446639. > > ## Any ideas? > > ## Thanks, > > ## Andrew