Re: OpenSSH update web page: typo
revision 1.147 date: 2023/12/20 17:30:01; author: millert; state: Exp; lines: +3 -3; commitid: nZ6tdVWYkmCCLb6k; Correct the links in the 9.6 section. Reported by Christos Zoulas. Are you guys kidding? :) On Tue, Dec 19, 2023 at 9:35 AM Alex Naumov wrote: > Hey, > > It seems there are two same update manuals for OpenSSH 9.5 and 9.6[1]. > Link to the tarball and the second shell command should be updated. > > Cheers, > Alex > > [1] https://www.openssh.com/openbsd.html >
OpenSSH update web page: typo
Hey, It seems there are two same update manuals for OpenSSH 9.5 and 9.6[1]. Link to the tarball and the second shell command should be updated. Cheers, Alex [1] https://www.openssh.com/openbsd.html
Re: non-hardware 2fa options for openssh
On 2023-08-29, myml...@gmx.com wrote: > My question is there any recent documentation / information on setting > up an openssh server with non-hardware based two factor authentication? > This does NOT have to be google authenticator, any similar service will > suffice. if an ssh key is good enough to be considered as one factor, and a password as the second, you can use AuthenticationMethods "publickey,password" PasswordAuthentication yes which requires both the ssh key and password
Re: non-hardware 2fa options for openssh
On 2023-08-29, Daniel Jakots wrote: > You can also want to look at sysutils/login_oath (which I've been using > for years), but maybe for new setups, the login_totp from base makes > more sense. you might be thinking of login_yubikey which is in base, but it has no way to sync the counter between machines, so it is a very bad idea to use the same key with this on more than one machine.
Re: non-hardware 2fa options for openssh
On Tue, 29 Aug 2023 13:18:53 -0400, Dave Voutila wrote: > > You can also want to look at sysutils/login_oath (which I've been > > using for years), but maybe for new setups, the login_totp from > > base makes more sense. > > > > login_totp is in base? Wow, I was sure https://github.com/reyk/login_otp was imported, and the man I was looking at actually comes from sysutilis/login_oauth lol thanks for catching my mistake!
Re: non-hardware 2fa options for openssh
Daniel Jakots writes: > On Tue, 29 Aug 2023 10:07:18 -0500, "myml...@gmx.com" > wrote: > >> Hi All, >> >> I want to secure an openssh server with two factor authentication and >> have seen the hardware token methods, most recently i've been seeing >> yubi/FIDO methods. >> >> Ideally I would like to avoid having to depend on a usb size device >> that could easily be lost. > > Using something based on TOTP (Cf. rfc6238) is probably your best bet > then. > >> I looked around and found mention of google authenticator as an >> option, phones aren't much bigger than usb sticks but people protect >> their phone as if it was their soul, but the newest mention I can >> find is many years old. > > AFAIK, google authenticator is simply an app doing the math for TOTP. > There are multiple basic opensource apps (on both Android and iphones) > which can provide you with the right TOTP based on the seed/secret. > > And if you don't want to use a phone, you can use oathtool(1) from > security/oath-toolkit. > I think some password managers also are able to generate the TOTP. > >> My question is there any recent documentation / information on setting >> up an openssh server with non-hardware based two factor >> authentication? This does NOT have to be google authenticator, any >> similar service will suffice. > > login_totp(8), login.conf(5), sshd_config(5), and maybe a couple of > others. > > You can also want to look at sysutils/login_oath (which I've been using > for years), but maybe for new setups, the login_totp from base makes > more sense. > login_totp is in base?
Re: non-hardware 2fa options for openssh
On Tue, 29 Aug 2023 10:07:18 -0500, "myml...@gmx.com" wrote: > Hi All, > > I want to secure an openssh server with two factor authentication and > have seen the hardware token methods, most recently i've been seeing > yubi/FIDO methods. > > Ideally I would like to avoid having to depend on a usb size device > that could easily be lost. Using something based on TOTP (Cf. rfc6238) is probably your best bet then. > I looked around and found mention of google authenticator as an > option, phones aren't much bigger than usb sticks but people protect > their phone as if it was their soul, but the newest mention I can > find is many years old. AFAIK, google authenticator is simply an app doing the math for TOTP. There are multiple basic opensource apps (on both Android and iphones) which can provide you with the right TOTP based on the seed/secret. And if you don't want to use a phone, you can use oathtool(1) from security/oath-toolkit. I think some password managers also are able to generate the TOTP. > My question is there any recent documentation / information on setting > up an openssh server with non-hardware based two factor > authentication? This does NOT have to be google authenticator, any > similar service will suffice. login_totp(8), login.conf(5), sshd_config(5), and maybe a couple of others. You can also want to look at sysutils/login_oath (which I've been using for years), but maybe for new setups, the login_totp from base makes more sense. Have fun, Daniel
non-hardware 2fa options for openssh
Hi All, I want to secure an openssh server with two factor authentication and have seen the hardware token methods, most recently i've been seeing yubi/FIDO methods. Ideally I would like to avoid having to depend on a usb size device that could easily be lost. I looked around and found mention of google authenticator as an option, phones aren't much bigger than usb sticks but people protect their phone as if it was their soul, but the newest mention I can find is many years old. My question is there any recent documentation / information on setting up an openssh server with non-hardware based two factor authentication? This does NOT have to be google authenticator, any similar service will suffice. Any advice greatly appreciated Thanks in advance.
Re: OpenSSH 8.8 ECCN REQUEST
Since the project is based in Canada I don't know if anyone on this list would have an ECCN. Unless there's someone on this list from one of the US companies that exports OpenSSH. On Fri, Mar 11, 2022 at 12:38 PM wrote: > Hello, > > Our company is exporting a computer with OpenSSH 8.8 software installed. > > We would like to confirm the ECCN of this software. Would you please > reply with US ECCN? > > > > Regards, > [Icon Description automatically generated] > Marella Abraham > Import/Export Compliance Analyst > Email: marella.x.abra...@us.tel.com<mailto:marella.x.abra...@us.tel.com> > >
OpenSSH 8.8 ECCN REQUEST
Hello, Our company is exporting a computer with OpenSSH 8.8 software installed. We would like to confirm the ECCN of this software. Would you please reply with US ECCN? Regards, [Icon Description automatically generated] Marella Abraham Import/Export Compliance Analyst Email: marella.x.abra...@us.tel.com<mailto:marella.x.abra...@us.tel.com>
Re: [www] openssh/openbsd.html typo
For sure I mean OpenSSH 8.7, so it should be # tar zxvf .../openssh-8.7.tar.gz Cheers, Alex On Tue, Aug 24, 2021 at 10:29 PM Alex Naumov wrote: > Hello, > update instructions for OpenSSH 6.7 has this line: > > # tar zxvf .../openssh-8.6.tar.gz > > It should be 6.7 > > Cheers, > Alex > >
[www] openssh/openbsd.html typo
Hello, update instructions for OpenSSH 6.7 has this line: # tar zxvf .../openssh-8.6.tar.gz It should be 6.7 Cheers, Alex
Re: OpenSSH and Key Pair Generation
Sounds like you have an operating system with a broken random number generator. Someone is going to say "but it is so hard in VMs". Yes it is hard if the vendors do a poor job of handling it. If they do a good job, it is easy. Anyways, Linux discussions are off-topic for OpenBSD mailing lists. Christopher Johns wrote: > Good Evening, > > Recently it has been brought to my attention that we may have several Linux > hosts that may have the same problem ssh-rsa key pairs. > > Is it possible if I use a server template to create Linux servers, for > OpenSSH to create the same host keys in /etc/ssh for the servers created by > my template? > > Also, how does OpenSSH create the key pairs, by some random process called > when OpenSSH is installed or when the new server is booted for the first > time? > > Thank you for your time and I look forward to hearing from you soon. > > Regards, > > Chris Johns > UNIX-Linux Systems Administrator
OpenSSH and Key Pair Generation
Good Evening, Recently it has been brought to my attention that we may have several Linux hosts that may have the same problem ssh-rsa key pairs. Is it possible if I use a server template to create Linux servers, for OpenSSH to create the same host keys in /etc/ssh for the servers created by my template? Also, how does OpenSSH create the key pairs, by some random process called when OpenSSH is installed or when the new server is booted for the first time? Thank you for your time and I look forward to hearing from you soon. Regards, Chris Johns UNIX-Linux Systems Administrator
OpenSSH and Key Pair Generation
Good Evening, Recently it has been brought to my attention that we may have several Linux hosts that may have the same problem ssh-rsa key pairs. Is it possible if I use a server template to create Linux servers, for OpenSSH to create the same host keys in /etc/ssh for the servers created by my template? Also, how does OpenSSH create the key pairs, by some random process called when OpenSSH is installed or when the new server is booted for the first time? Thank you for your time and I look forward to hearing from you soon. Regards, Chris Johns UNIX-Linux Systems Administrator
[www] typo year for OpenSSH 8.5 release
Hello, The date of OpenSSH 8.5 release on https://www.openssh.com/openbsd.html page is wrong. 2020 => 2021 Cheers, Alex
Re: OpenSSH FIDO (Nitrokey) support (Was: Re: OpenBSD insecurity rumors from isopenbsdsecu.re)
Btw, thanks for this site link, may be something like: https://web.archive.org/web/20200513115537/https://undeadly.org/cgi?action=article=20190302235509 could work. > On Wed, May 13, 2020 at 12:59:26PM +0200, i...@aulix.com wrote: > >> Thanks for your suggestion, >> >> but googling for keys: +openbsd +nitrokey >> >> does not indicate anything interesting except a few of my own questions on >> the Nitrokey support forum. > > I had to look up "Nitrokey" to verify that it was what I thought it was, but > that had me > do a quick search for "OpenSSH FIDO support", which turned up among other > things this > article: https://undeadly.org/cgi?action=article;sid=20191115064850 as well > as a number > of blog posts and HOWTO-ish pieces that seem to indicate that quite likely > the combination > would work. > > I haven't tried the thing myself, but you should be able to find the same > stuff I did > on the web. Then you could probably find a way to test with an OpenBSD setup > in a way > that does not break things too horribly in case anything fails. > > All the best, > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: OpenSSH FIDO (Nitrokey) support (Was: Re: OpenBSD insecurity rumors from isopenbsdsecu.re)
Thanks for suggestion, I already have seen it and even contacted SSH developer Damien Miller regarding FIDO key support a few weeks ago. What I am looking for right now is something different, it is if ssh-pkcs11-helper works with SSHD daemon on OpenBSD to store there its server private key in a general Nitrokey Pro 2 (not HSM). Btw, I am going to use several client side dongles at once for a single SSH session like Rutoken ECP2, FIDO2, and Nitrokey Pro 2 only on the server yet. > On Wed, May 13, 2020 at 12:59:26PM +0200, i...@aulix.com wrote: > >> Thanks for your suggestion, >> >> but googling for keys: +openbsd +nitrokey >> >> does not indicate anything interesting except a few of my own questions on >> the Nitrokey support forum. > > I had to look up "Nitrokey" to verify that it was what I thought it was, but > that had me > do a quick search for "OpenSSH FIDO support", which turned up among other > things this > article: https://undeadly.org/cgi?action=article;sid=20191115064850 as well > as a number > of blog posts and HOWTO-ish pieces that seem to indicate that quite likely > the combination > would work. > > I haven't tried the thing myself, but you should be able to find the same > stuff I did > on the web. Then you could probably find a way to test with an OpenBSD setup > in a way > that does not break things too horribly in case anything fails. > > All the best, > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
OpenSSH FIDO (Nitrokey) support (Was: Re: OpenBSD insecurity rumors from isopenbsdsecu.re)
On Wed, May 13, 2020 at 12:59:26PM +0200, i...@aulix.com wrote: > Thanks for your suggestion, > > but googling for keys: +openbsd +nitrokey > > does not indicate anything interesting except a few of my own questions on > the Nitrokey support forum. I had to look up "Nitrokey" to verify that it was what I thought it was, but that had me do a quick search for "OpenSSH FIDO support", which turned up among other things this article: https://undeadly.org/cgi?action=article;sid=20191115064850 as well as a number of blog posts and HOWTO-ish pieces that seem to indicate that quite likely the combination would work. I haven't tried the thing myself, but you should be able to find the same stuff I did on the web. Then you could probably find a way to test with an OpenBSD setup in a way that does not break things too horribly in case anything fails. All the best, -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
broken link on openssh/legacy.htnl
Hello, there is one broken link on the openssh/legacy.html page: OSSH -> ftp://ftp.pdc.kth.se/pub/krypto/ossh/ Cheers, Alex
OpenSSH ignoring login.conf and ypbind (LDAP) config.
I'm trying to log into my OpenBSD server with an LDAP user and it's not working: Jan 8 10:41:57 aagico-postgres-nextcloud sshd[15381]: Failed password for dcorbe from 73.57.99.182 port 45222 ssh2 Although login.conf is configured properly: # /usr/libexec/auth/login_-ldap -d -s login dcorbe ldap Password: ... authorize And so is ypbind: aagico-postgres-nextcloud# getent group | grep dcorbe _dcorbe:*:2001:dcorbe aagico-postgres-nextcloud# getent passwd | grep dcorbe dcorbe:*:2001:2001:Daniel Corbe:/home/dcorbe:/bin/sh What do I need to change about OpenSSH to get this working?
Re: Openssh over a mobile network
On 1/12/19 11:43 pm, putridsou...@gmail.com wrote: > I am not able to ssh into my home computer connected to > router, the client device (termux on android) is on a > mobile network. Is there something I am supposed to > know?. Because I can ssh into my computer easily when > when both devices are on the same router network. - Are you using the right address on your device? If you have a DNS hostname configured, check its A and/or record points to the correct IP address. (This must be a publicly routable IPv4/IPv6 address *NOT* be a RFC-1918 private IPv4 address or RFC-4193 ULA IPv6 address.) - Is your OpenSSH server behind a router? Is that configured correctly? - Is your ISP (for the phone or your home computer) perhaps blocking ports? Try editing /etc/ssh/sshd_config and change the port to something high, maybe 2? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Openssh over a mobile network
On Sun, Dec 01, 2019 at 07:13:18PM +0530, putridsou...@gmail.com wrote: > I am not able to ssh into my home computer connected to > router, the client device (termux on android) is on a > mobile network. Is there something I am supposed to > know?. Because I can ssh into my computer easily when > when both devices are on the same router network. I assume your router uses Network Address Translation (NAT). You must instruct it to *forward* the incoming SSH traffic. NAT is commonly used to separate a private network from the Internet, particularly with small business or home networks. See your router's documentation for port forwarding. The standard destination port number for SSH is 22.
Openssh over a mobile network
I am not able to ssh into my home computer connected to router, the client device (termux on android) is on a mobile network. Is there something I am supposed to know?. Because I can ssh into my computer easily when when both devices are on the same router network.
[www] patch for openssh/openbsd.html - looks like a typo
Hello, it seems like a typo in OpenSSH version number. Cheers, Alex Index: openbsd.html === RCS file: /cvs/www/openssh/openbsd.html,v retrieving revision 1.127 diff -u -p -r1.127 openbsd.html --- openbsd.html9 Oct 2019 02:11:34 - 1.127 +++ openbsd.html1 Nov 2019 20:44:14 - @@ -253,7 +253,7 @@ https://ftp.openbsd.org/pub/OpenBSD/Open -If you are installing OpenSSH 7.2 on 5.8, you will +If you are installing OpenSSH 7.3 on 5.8, you will need the the following patch: https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openbsd58_7.3.patch;> https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openbsd58_7.3.patch.
patch for www/openssh/openbsd.html (seems like a typo in version number)
Hi, it seems like a typo in OpenSSH version number: in 7.3 part info about patch for 7.2. Cheers, Alex Index: openbsd.html === RCS file: /cvs/www/openssh/openbsd.html,v retrieving revision 1.127 diff -u -p -r1.127 openbsd.html --- openbsd.html9 Oct 2019 02:11:34 - 1.127 +++ openbsd.html1 Nov 2019 20:44:14 - @@ -253,7 +253,7 @@ https://ftp.openbsd.org/pub/OpenBSD/Open -If you are installing OpenSSH 7.2 on 5.8, you will +If you are installing OpenSSH 7.3 on 5.8, you will need the the following patch: https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openbsd58_7.3.patch;> https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openbsd58_7.3.patch.
Re: The Dark Side of the ForSSHe - OpenSSH malwares
On Thu, Dec 13, 2018 at 09:25:25AM +0100, Kollar Arpad wrote: > https://www.welivesecurity.com/2018/12/05/dark-side-of-the-forsshe/ > > ESET researchers discovered a set of previously undocumented Linux malware > families based on OpenSSH. In the white paper, “The Dark Side of the > ForSSHe”, they release analysis of 21 malware families to improve the > prevention, detection and remediation of such threats Yes, researchers have found these things in the wild. The thing that irritates me no end is that the way this is written, one could be lead to believe that the malware just magically appears on your box. > Any creative hints to defend against these kind of threats? Creative hints? No. The best defence is as always, PATCH YOUR SHIT! (As in, install all relevant updates that come from trusted sources.) Keep your systems up to date, do not install new, improved versions of anything from sources other than the trusted repositories, do not muck around with config options you don't understand, and oh PATCH YOUR SHIT! (Again as in, install all relevant updates that come from trusted sources.) I could go on about not allowing root logins, going to keys-only logins, various other things, my meta-rant wrapped around several articles on the "Hail Mary Cloud" password guessing episodes is at https://bsdly.blogspot.com/2013/10/the-hail-mary-cloud-and-lessons-learned.html (TL;DR: it all started with a dodgy binary off a Debian system) has a few other points in the summary pieces. The other suggestions you have are mostly not relevant in an OpenBSD environment and to my mind at least just adds complexity for no real gain. If you for some reason want to stick to passwords, longer ones *are* better, but AFAIK code changes to passwd are not necessary just to accommodate that as long as you can live with a max length of 128 characters (which is the current limit if I read http://man.openbsd.org/passwd correctly). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: The Dark Side of the ForSSHe - OpenSSH malwares
On Thu, Dec 13, 2018 at 10:02:45AM +0100, Otto Moerbeek wrote: > On Thu, Dec 13, 2018 at 09:50:31AM +0100, Florian Obser wrote: > > > On Thu, Dec 13, 2018 at 09:25:25AM +0100, Kollar Arpad wrote: > > > Any creative hints to defend against these kind of threats? > > > > Your system has been compromised. The attacker is able to replace > > binaries, you have lost. If your package manager can still tell you > > that the sshd binary has been replaced that only means that you are > > dealing with an incompetent attacker. > > > > Throw the computer away. Get a new one. Install from scratch, restore > > data (and only data!) from backup. > > This assumes you can tell the difference between data and code. > > It's a rather fundamental thing that you cannot tell the difference > between data and code. > > Data read by a program is interpreted in some way. That's a form of execution. > True. Some people just pick up black smithing. I think they are on to something... > -Otto > > -- I'm not entirely sure you are real.
Re: The Dark Side of the ForSSHe - OpenSSH malwares
On Thu, Dec 13, 2018 at 09:50:31AM +0100, Florian Obser wrote: > On Thu, Dec 13, 2018 at 09:25:25AM +0100, Kollar Arpad wrote: > > Any creative hints to defend against these kind of threats? > > Your system has been compromised. The attacker is able to replace > binaries, you have lost. If your package manager can still tell you > that the sshd binary has been replaced that only means that you are > dealing with an incompetent attacker. > > Throw the computer away. Get a new one. Install from scratch, restore > data (and only data!) from backup. This assumes you can tell the difference between data and code. It's a rather fundamental thing that you cannot tell the difference between data and code. Data read by a program is interpreted in some way. That's a form of execution. -Otto
Re: The Dark Side of the ForSSHe - OpenSSH malwares
On Thu, Dec 13, 2018 at 09:25:25AM +0100, Kollar Arpad wrote: > Any creative hints to defend against these kind of threats? Your system has been compromised. The attacker is able to replace binaries, you have lost. If your package manager can still tell you that the sshd binary has been replaced that only means that you are dealing with an incompetent attacker. Throw the computer away. Get a new one. Install from scratch, restore data (and only data!) from backup. -- I'm not entirely sure you are real.
Re: The Dark Side of the ForSSHe - OpenSSH malwares
"Kollar Arpad" wrote: > Hello, > > How about blacklisting some often used passwords? ex.: > https://github.com/eset/malware-ioc/tree/master/sshdoor (either used by > humans often or by backdoors) > > When will "passwd" have option to give/generate passwords from 4 random > english words from a 65k wordlist? > > Thanks, just loud thinking. use keys
The Dark Side of the ForSSHe - OpenSSH malwares
Hello, just a FYI, maybe you havent seent the study: https://www.welivesecurity.com/2018/12/05/dark-side-of-the-forsshe/ ESET researchers discovered a set of previously undocumented Linux malware families based on OpenSSH. In the white paper, “The Dark Side of the ForSSHe”, they release analysis of 21 malware families to improve the prevention, detection and remediation of such threats PDF: https://www.welivesecurity.com/wp-content/uploads/2018/12/ESET-The_Dark_Side_of_the_ForSSHe.pdf Any creative hints to defend against these kind of threats? Thinking of ex.: a new default option in the PermitRootLogin to only allow someone to log in for the first x times (where x = ex.: 3) with password for root, from that point, root is only allowed to log in with ssh key, until next sshd restart? Maybe that way more people would use key based auth and there would be less credential stealing? Or ex.: if an "rpm -V openssh-server" says that the original binaries were modified, sshd would show a warning before asking for credentials? Or how to ensure to not to run unsigned ELF/binaries/code? In OpenBSD or on Linux.. Or how to ensure that nothing can be installed with the same package name? How about blacklisting some often used passwords? ex.: https://github.com/eset/malware-ioc/tree/master/sshdoor (either used by humans often or by backdoors) When will "passwd" have option to give/generate passwords from 4 random english words from a 65k wordlist? Thanks, just loud thinking.
Re: OpenSSH 7.7 default ciphers
Thanks - I just committed a fix (having missed that Otto already included a patch beyond the bottom of my xterm -- sorry) On Thu, 5 Apr 2018, Otto Moerbeek wrote: > On Thu, Apr 05, 2018 at 01:51:51PM +0200, Renaud Allard wrote: > > > Hello, > > > > The man page for openssh 7.7 for Ciphers specifications mentions: > > > > The default is: > > chacha20-poly1...@openssh.com, > > aes128-ctr,aes192-ctr,aes256-ctr, > > aes128-...@openssh.com,aes256-...@openssh.com, > > aes128-cbc,aes192-cbc,aes256-cbc > > > > > > However, ssh doesn't use the last line in that list: > > $ ssh -G 127.0.0.1 |grep ciphers > > ciphers > > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com > > > > The changelog doesn't mention any change in the ciphers either. > > > > > > > > Regards > > > > The man ssh_config page is wrong (sshd_config is right). > > -Otto > > Index: ssh_config.5 > === > RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v > retrieving revision 1.268 > diff -u -p -r1.268 ssh_config.5 > --- ssh_config.5 23 Feb 2018 07:38:09 - 1.268 > +++ ssh_config.5 5 Apr 2018 12:08:36 - > @@ -425,8 +425,7 @@ The default is: > .Bd -literal -offset indent > chacha20-poly1...@openssh.com, > aes128-ctr,aes192-ctr,aes256-ctr, > -aes128-...@openssh.com,aes256-...@openssh.com, > -aes128-cbc,aes192-cbc,aes256-cbc > +aes128-...@openssh.com,aes256-...@openssh.com > .Ed > .Pp > The list of available ciphers may also be obtained using >
Re: OpenSSH 7.7 default ciphers
On Thu, Apr 05, 2018 at 01:51:51PM +0200, Renaud Allard wrote: > Hello, > > The man page for openssh 7.7 for Ciphers specifications mentions: > > The default is: > chacha20-poly1...@openssh.com, > aes128-ctr,aes192-ctr,aes256-ctr, > aes128-...@openssh.com,aes256-...@openssh.com, > aes128-cbc,aes192-cbc,aes256-cbc > > > However, ssh doesn't use the last line in that list: > $ ssh -G 127.0.0.1 |grep ciphers > ciphers > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com > > The changelog doesn't mention any change in the ciphers either. > > > > Regards > The man ssh_config page is wrong (sshd_config is right). -Otto Index: ssh_config.5 === RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.268 diff -u -p -r1.268 ssh_config.5 --- ssh_config.523 Feb 2018 07:38:09 - 1.268 +++ ssh_config.55 Apr 2018 12:08:36 - @@ -425,8 +425,7 @@ The default is: .Bd -literal -offset indent chacha20-poly1...@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, -aes128-...@openssh.com,aes256-...@openssh.com, -aes128-cbc,aes192-cbc,aes256-cbc +aes128-...@openssh.com,aes256-...@openssh.com .Ed .Pp The list of available ciphers may also be obtained using
OpenSSH 7.7 default ciphers
Hello, The man page for openssh 7.7 for Ciphers specifications mentions: The default is: chacha20-poly1...@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, aes128-...@openssh.com,aes256-...@openssh.com, aes128-cbc,aes192-cbc,aes256-cbc However, ssh doesn't use the last line in that list: $ ssh -G 127.0.0.1 |grep ciphers ciphers chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com The changelog doesn't mention any change in the ciphers either. Regards smime.p7s Description: S/MIME Cryptographic Signature
Re: Portable OpenSSH 7.5p1 with LibreSSL 2.6.1 fails
On 7 September 2017 at 16:35, Heiko <bd09c6fmxoq2...@intermezzo.net> wrote: > Hello, > > ./config for Portable OpenSSH 7.5p1 with LibreSSL 2.6.1 fails on Debian > Linux: As per https://www.openssh.com/report.html this query would be better directed to the portable list openssh-unix-...@mindrot.org. Please send any followups there. > checking OpenSSL header version... not found > configure: error: OpenSSL version header not found. This means the little test program in configure either failed to build and run or did not produce the expected output. The exact reason will be in config.log (although you may have to scroll back a way to find it). A common cause of this is not having added the new lib directory to the runtime linker config via ldconfig(8). -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Portable OpenSSH 7.5p1 with LibreSSL 2.6.1 fails
Hello, ./config for Portable OpenSSH 7.5p1 with LibreSSL 2.6.1 fails on Debian Linux: checking OpenSSL header version... not found configure: error: OpenSSL version header not found. $ openssl version LibreSSL 2.6.1 I did it with this options: ./configure --without-openssl-header-check --sysconfdir=/etc/ssh \ --with-ssl-dir=/usr/local --without-pie --without-xauth \ --with-zlib How can I fix this? Thank you in advance. /Heiko
openssh nistp521 advertised as supported but no host key available by default
If a client (openssh, putty) insists on nistp521 as openssh offers in the debug dialogue then the connection fails or falls back to nistp256. If you create a nistp521 host key and add it to sshd_config then nistp521 is used successfully. Not sure if nistp256 could use a nistp521 key or if this is intended or not? I assume it tries to use the default 256bit ecdsa key that is too short for nistp521.
6.1 OpenSSH/LibreSSL version discrepancy
Hi, there seems to be a version info discrepancy in the OpenBSD 6.1 ANNOUNCEMENT. It states OpenSSH 7.4 and LibreSSL 2.5.3. However, in 6.1(/amd64) release fresh install, i have OpenSSH 7.5 and LibreSSL 2.5.2: $ ssh -V; openssl version OpenSSH_7.5, LibreSSL 2.5.2 LibreSSL 2.5.2 If it is just a mistake, and there is no deeper meaning of this apparent misinfo, i guess it is not too late to fix it where it still can be fixed, e.g. at https://openbsd.org/61.html . Regards, outis
Re: OpenSSH logging and MaxAuthTries
On 3/20/17, Darren Tucker : > On Sun, Mar 19, 2017 at 11:47 PM, Lars Noodén wrote: >> Looking at a recent snapshot, see dmesg at the bottom, I have two >> questions about OpenSSH logging. >> >> 1) The entry in sshd_config(5) for MaxAuthTries states the following >> about log entries: >> >> ... Once the number of failures reaches half this >> value, additional failures are logged. The default is 6. >> >> Yet the logging of failures seems to occur these days from the very first >> try. >> Has this behavior changed? > > No, but it's always logged password attempts regardless of whether or > not you've got to MaxAuthTries/2: > > $ cvs annotate auth.c | grep -C2 max_auth > Annotations for auth.c > *** > 1.13 (markus 18-Jan-01): if (authenticated == 1 || > 1.13 (markus 18-Jan-01): !authctxt->valid || > 1.54 (dtucker 23-May-04): authctxt->failures >= > options.max_authtries / 2 || > 1.13 (markus 18-Jan-01): strcmp(method, "password") == > 0) > 1.47 (itojun 08-Apr-03): authlog = logit; Would the following change help? Regards, Lars Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.237 diff -u -p -u -p -r1.237 sshd_config.5 --- sshd_config.5 7 Oct 2016 14:41:52 - 1.237 +++ sshd_config.5 20 Mar 2017 06:10:07 - @@ -1080,8 +1080,7 @@ and .It Cm MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. -Once the number of failures reaches half this value, -additional failures are logged. +All failures are logged. The default is 6. .It Cm MaxSessions Specifies the maximum number of open shell, login or subsystem (e.g. sftp) cvs server: Diffing lib cvs server: Diffing moduli-gen cvs server: Diffing scp cvs server: Diffing sftp cvs server: Diffing sftp-server cvs server: Diffing ssh cvs server: Diffing ssh-add cvs server: Diffing ssh-agent cvs server: Diffing ssh-keygen cvs server: Diffing ssh-keyscan cvs server: Diffing ssh-keysign cvs server: Diffing ssh-pkcs11-helper cvs server: Diffing sshd
Re: OpenSSH logging and MaxAuthTries
Sorry. That previous message got mangled. > $ ssh-add -l > The agent has no identities. On the server it looks like it says the client is asking for 'keyboard-interactive' first of all things: > debug1: userauth-request for user fred service ssh-connection method > none [preauth] > debug1: attempt 0 failures 0 [preauth] > debug1: userauth-request for user fred service ssh-connection method > keyboard-interactive [preauth] > debug1: attempt 1 failures 0 [preauth] > debug1: keyboard-interactive devs [preauth] > debug1: auth2_challenge: user=fred devs= [preauth] > debug1: kbdint_alloc: devices 'bsdauth' [preauth] > debug1: auth2_challenge_start: trying authentication method 'bsdauth' > [preauth] > debug1: userauth-request for user fred service ssh-connection method > password [preauth] > debug1: attempt 2 failures 1 [preauth] > Failed password for fred from 192.0.2.246 port 57386 ssh2 > debug1: userauth-request for user fred service ssh-connection method > password [preauth] > > >> [...] >>> Is there any way to get the full number of MaxAuthTries log in attempts? >> >> Assuming my guess above is correct, PreferredAuthentications=password Yes, thanks, PreferredAuthentications=password does answer the question. Looking at the -vvv output from the SSH client, it also looks like it was because of the keyboard-interactive: ... debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/fred/.ssh/id_rsa debug3: no such identity: /home/fred/.ssh/id_rsa: No such file or directory debug1: Trying private key: /home/fred/.ssh/id_dsa debug3: no such identity: /home/fred/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/fred/.ssh/id_ecdsa debug3: no such identity: /home/fred/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/fred/.ssh/id_ed25519 debug3: no such identity: /home/fred/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password ... So, yes, that does allow the maximum number of log-ins. Thanks. Regards, Lars
Re: OpenSSH logging and MaxAuthTries
>> 2) The client gets disconnected before MaxAuthTries is reached. If I >> have it set to 6, I get 5 only tries: > > Your log level isn't high enough to see it, but I suspect you have a > failed pubkey attempt before the password attempts. You should be > able to see it if you add "-vvv" to the command line. $ ssh-add -l The agent has no identities. debug1: userauth-request for user fred service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: userauth-request for user fred service ssh-connection method keyboard-interactive [preauth] debug1: attempt 1 failures 0 [preauth] debug1: keyboard-interactive devs [preauth] debug1: auth2_challenge: user=fred devs= [preauth] debug1: kbdint_alloc: devices 'bsdauth' [preauth] debug1: auth2_challenge_start: trying authentication method 'bsdauth' [preauth] debug1: userauth-request for user fred service ssh-connection method password [preauth] debug1: attempt 2 failures 1 [preauth] Failed password for fred from 192.0.2.246 port 57386 ssh2 debug1: userauth-request for user fred service ssh-connection method password [preauth] > [...] >> Is there any way to get the full number of MaxAuthTries log in attempts? > > Assuming my guess above is correct, PreferredAuthentications=password > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement.
Re: OpenSSH logging and MaxAuthTries
On Sun, Mar 19, 2017 at 11:47 PM, Lars Noodén <lars.noo...@gmail.com> wrote: > Looking at a recent snapshot, see dmesg at the bottom, I have two > questions about OpenSSH logging. > > 1) The entry in sshd_config(5) for MaxAuthTries states the following > about log entries: > > ... Once the number of failures reaches half this > value, additional failures are logged. The default is 6. > > Yet the logging of failures seems to occur these days from the very first try. > Has this behavior changed? No, but it's always logged password attempts regardless of whether or not you've got to MaxAuthTries/2: $ cvs annotate auth.c | grep -C2 max_auth Annotations for auth.c *** 1.13 (markus 18-Jan-01): if (authenticated == 1 || 1.13 (markus 18-Jan-01): !authctxt->valid || 1.54 (dtucker 23-May-04): authctxt->failures >= options.max_authtries / 2 || 1.13 (markus 18-Jan-01): strcmp(method, "password") == 0) 1.47 (itojun 08-Apr-03): authlog = logit; > 2) The client gets disconnected before MaxAuthTries is reached. If I > have it set to 6, I get 5 only tries: Your log level isn't high enough to see it, but I suspect you have a failed pubkey attempt before the password attempts. You should be able to see it if you add "-vvv" to the command line. [...] > Is there any way to get the full number of MaxAuthTries log in attempts? Assuming my guess above is correct, PreferredAuthentications=password -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
OpenSSH logging and MaxAuthTries
Looking at a recent snapshot, see dmesg at the bottom, I have two questions about OpenSSH logging. 1) The entry in sshd_config(5) for MaxAuthTries states the following about log entries: ... Once the number of failures reaches half this value, additional failures are logged. The default is 6. Yet the logging of failures seems to occur these days from the very first try. Has this behavior changed? 2) The client gets disconnected before MaxAuthTries is reached. If I have it set to 6, I get 5 only tries: $ ssh -o "NumberOfPasswordPrompts=7" fred@192.0.2.105 fred@192.0.2.105's password: Permission denied, please try again. fred@192.0.2.105's password: Permission denied, please try again. fred@192.0.2.105's password: Permission denied, please try again. fred@192.0.2.105's password: Permission denied, please try again. fred@192.0.2.105's password: Received disconnect from 192.0.2.105: 2: Too many authentication failures >From the server: # /usr/sbin/sshd -T | grep maxauthtries maxauthtries 6 # grep 4704 /var/log/authlog Mar 19 14:24:26 server sshd[4704]: Failed password for fred from 192.0.2.206 port 55295 ssh2 Mar 19 14:24:36 server sshd[4704]: Failed password for fred from 192.0.2.206 port 55295 ssh2 Mar 19 14:24:40 server sshd[4704]: Failed password for fred from 192.0.2.206 port 55295 ssh2 Mar 19 14:24:43 server sshd[4704]: Failed password for fred from 192.0.2.206 port 55295 ssh2 Mar 19 14:24:49 server sshd[4704]: Failed password for fred from 192.0.2.206 port 55295 ssh2 Mar 19 14:24:49 server sshd[4704]: error: maximum authentication attempts exceeded for fred from 192.0.2.206 port 55295 ssh2 [preauth] Mar 19 14:24:49 server sshd[4704]: Disconnecting authenticating user fred 192.0.2.206 port 55295: Too many authentication failures [preauth] If I set the client's NumberOfPasswordPrompts to a lower number than sshd(8)'s MaxAuthTries, that works as expected and I get the number of tries specified by the client. If set the client's NumberOfPasswordPrompts to number greater than or equal to sshd(8)'s MaxAuthTries, I get only one less than what was set in MaxAuthTries instead of the full sequence. Is there any way to get the full number of MaxAuthTries log in attempts? Regards, Lars [ using 595272 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.1-beta (GENERIC) #83: Sat Mar 18 01:48:53 MDT 2017 dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1057243136 (1008MB) mainbus0 at root: Lemote Yeeloong cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way bonito0 at mainbus0: memory and PCI-X controller, rev 1 pci0 at bonito0 bus 0 rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address 00:23:8b:59:df:48 rlphy0 at rl0 phy 0: RTL internal PHY smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0: 1024x600, 16bpp wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation) glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c isa0 at glxpcib0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 mcclock0 at isa0 port 0x70/2: mc146818 or compatible ykbec0 at isa0 port 0x381/3 gpio1 at glxpcib0: 32 pins iic at glxpcib0 not configured glxclk0 at glxpcib0: clock, prof pciide0 at pci0 dev 14 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 1-sector PIO, LBA, 7641MB, 15649200 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9, CS5536 AC97 ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0) audio0 at auglx0 ohci0 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11, version 1.0, legacy support ehci0 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00 addr 1 apm0 at mainbus0 umass0 at uhub0 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" rev 2.00/58.87 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: <Generic-, Multi-Card, 1.00> SCSI0 0/direct removable serial.0bda015811417340 urtw0 at uhub0 port 4 configuration 1 inter
Re: Maybe OT: OpenSSH connection failure unless verbose
Exactly. Probably ps -l (or maybe install and use pstree). Do you get new processes with sshd as a parent? I never get that. When ssh-ing into another machine I just get a single ssh process that's a direct child of the bash for that tty, there's never an sshd anywhere. When you use ps -l you will only see processes with a controlling terminal. This assumes I'm running ps without any command line arguments. But the PPID column relates each process to its parent process. If you start at any arbitrary process and trace back to its parent, and then to that process's parent, you will eventually find a PPID for a process that did not show up in ps -l. That will probably be the process id of sshd. I know how ps works :) On OSX, an outbound ssh connection spawns a single 'ssh' process, which is a child of bash. bash is a child of login. login is a child of Terminal. Terminal is a child of the launchd process for my account. That launchd process is a child of the master launchd process, PID 1. The (abbreviated) output of ps looks like this: TTY USER RUSER PPID PID COMMAND ?? root root 01 launchd ?? Quartz Quartz1 208 launchd ?? Quartz Quartz 208 241 Terminal s000 root Quartz 241 246 login s000 Quartz Quartz 246 249 -bash s000 Quartz Quartz 249 3212 ssh On OSX, sshd is the receiving server side of the ssh connection. It only runs when I have an ssh connection INTO my machine, not when I'm connecting to someone else. The only other ssh related process is ssh-agent, but that's always running no matter what. Or: ps -lx | grep 'ssh[d]' Not sure what OS / version of grep you're using. On OSX this yields no output even when ssh processes are running. If I shorten the regex to just 'ssh' I see the ssh process and ssh-agent which I mentioned above.
Re: Maybe OT: OpenSSH connection failure unless verbose
On Sun, Aug 2, 2015 at 7:02 AM, Quartz qua...@sneakertech.com wrote: I know how ps works :) Ok, good, then the problem lies elsewhere... On OSX, an outbound ssh connection spawns a single 'ssh' process, which is a child of bash. bash is a child of login. login is a child of Terminal. Perhaps here. The point was to use ps on the *server* not on the client. If you were not seeing sshd and you know how to use ps, that must mean you were using ps on your local machine rather than on the remote machine. But the question I was asking was: if you can establish one connection to the remote machine can you still duplicate the problem. And, unfortunately, it looks like I assumed you understood my thought process when I was not being clear about that. I was guessing that the problem might be a problem on the server. This would account for why you only see the problem there, rather than at other sites. So I was thinking you should use ps *on that server* to see if you could see signs of another connection attempt reaching it and then for some reason failing to give you an interactive shell. In other words, it might be that there's some race condition on the server that you sometimes fail to reach, such that ssh -v slows things down just enough to avoid the race. If that is the case, since you said the connection hangs, it's possible that the problem exists in a subprocess of sshd rather than in sshd itself. And that is what I was suggesting you test. Of course, it's also possible that you're seeing network problems, in which case something like tcpdump would be a better source of clues (assuming that you can trace all the way to the server on a good day). And, it's also possible that the problem is a race within the remote sshd (or maybe even the remote kernel) and that that would prevent spawning any subprocesses. In either of those cases, my suggestion would not result in any new information - but it would still be the case that a negative result from testing for new processes would tell you not to concern yourself with my guess. Or: ps -lx | grep 'ssh[d]' Not sure what OS / version of grep you're using. On OSX this yields no output even when ssh processes are running. If I shorten the regex to just 'ssh' I see the ssh process and ssh-agent which I mentioned above. If you are on an openbsd machine which is running sshd (either because it's running in daemon mode, or because you have an ssh connection into it), this will show you some information about the sshd process(es). I put the [] around the d so that the grep itself will not show up, and I put the '' around the regexp to eliminate the tiny chance that you would have a file named sshd in your current directory. The point of this exercise would be to help isolate where your connection attempts stall. Thanks, -- Raul
Re: Maybe OT: OpenSSH connection failure unless verbose
The point was to use ps on the *server* not on the client. So I was thinking you should use ps *on that server* to see if you could see signs of another connection attempt reaching it and then for some reason failing to give you an interactive shell. Ah ok. Yes I totally misunderstood you- I thought you meant check ps on the client to see if it was actually spawning an ssh process. In other words, it might be that there's some race condition on the server that you sometimes fail to reach, such that ssh -v slows things down just enough to avoid the race. That's possible. I'm not convinced it's on their end though, you'd think they'd have noticed by now ssh connections hanging all the time. Of course, it's also possible that you're seeing network problems, They do some weird stuff with their systems sometimes. Half their stuff is in house and the other half is cloud, and it's not always coherent. Additionally, there's always the possibility that I've somehow configured my firewalls in a weird way. in which case something like tcpdump would be a better source of clues (assuming that you can trace all the way to the server on a good day). Traceroute specifically doesn't yield much: outside of my ISP it bounces off over a dozen boxes with no host names before disappearing into a black hole (magic cloud issues I'm sure). Filtering with tcpdump can be annoying since what I filter for isn't always what comes back due to all the dns redirection. I do seem to be able to see at least most of the packets though I think. If you are on an openbsd machine which is running sshd OK. This works on their linux server.
Re: Maybe OT: OpenSSH connection failure unless verbose
ktrace and tcpdump. I should have mentioned that the laptop is using OpenSSH but it's OSX not OpenBSD. ktrace was replaced with I think dtrace on OSX a while ago, so I'll have to look into how to get that set up. As for tcpdump, I'm not sure what I'd be looking for there. Most of the connection meat would be encrypted anyway though, wouldn't it?
Re: Maybe OT: OpenSSH connection failure unless verbose
If you have one connection established to that server which is functioning (perhaps with -v on the client ssh) can you get the problem to occur with a second connection to that server? That's a good question, I'm not actually sure if I've ever opened two connections to it at once. For better or worse today is a good day so I'll have to wait to test this. If so, can you take a look at whether you are getting any fresh processes from your second connection attempts when they stall? (The question is: how far does a stalled attempt reach before it runs into this problem?) Not sure what you mean here about fresh processes, do you want me to look at the output of ps or something else?
Re: Maybe OT: OpenSSH connection failure unless verbose
If you have one connection established to that server which is functioning (perhaps with -v on the client ssh) can you get the problem to occur with a second connection to that server? If so, can you take a look at whether you are getting any fresh processes from your second connection attempts when they stall? (The question is: how far does a stalled attempt reach before it runs into this problem?) Thanks, -- Raul On Sat, Aug 1, 2015 at 5:09 AM, Quartz qua...@sneakertech.com wrote: I'm not sure if this is the right place to ask about this, but I can't seem to find an ssh-specific mailing list or web forum anywhere. I have a bog standard setup between a laptop and a local university that uses a bog standard id_rsa key for password-less access; to the best of my knowledge there's nothing remotely unusual about the ssh configuration on the laptop (I'm less sure about the university server since I don't have access to its config). About maybe 1/3 of the days I try to log into the server, the ssh connection hangs forever with no output UNLESS -v is specified on the command line, in which case it works totally fine. This is completely repeatable: no verbose, no worky (but only on bad days; on good days it works fine regardless). I've only ever experienced this problem with the connection to this one university, ssh otherwise works as expected connecting to every other machine. Searching the web for info is worthless because the first thing everybody tells you to do when debugging a connection issue is enable verbose, which obviously doesn't help me here. Likewise, I can't even confirm if anyone else has even experienced this sort of failure before since searching for connection/failure/verbose related keywords yields nothing but self-help related noise. I have limited access to their server too- I don't have and can't get a password (it's key only), so I don't know where to even start figuring this out. Any ideas?
Re: Maybe OT: OpenSSH connection failure unless verbose
That's a good question, I'm not actually sure if I've ever opened two connections to it at once. For better or worse today is a good day so I'll have to wait to test this. If you are only creating one ssh connection, does good day mean you have succeeded just once? No, I mean that I can ssh in without having to pass -v on the command line. In other words, it works the way it normally should. Not sure what you mean here about fresh processes, do you want me to look at the output of ps or something else? Exactly. Probably ps -l (or maybe install and use pstree). Do you get new processes with sshd as a parent? I never get that. When ssh-ing into another machine I just get a single ssh process that's a direct child of the bash for that tty, there's never an sshd anywhere.
Re: Maybe OT: OpenSSH connection failure unless verbose
On Sat, Aug 1, 2015 at 6:53 PM, Quartz qua...@sneakertech.com wrote: Exactly. Probably ps -l (or maybe install and use pstree). Do you get new processes with sshd as a parent? I never get that. When ssh-ing into another machine I just get a single ssh process that's a direct child of the bash for that tty, there's never an sshd anywhere. When you use ps -l you will only see processes with a controlling terminal. But the PPID column relates each process to its parent process. If you start at any arbitrary process and trace back to its parent, and then to that process's parent, you will eventually find a PPID for a process that did not show up in ps -l. That will probably be the process id of sshd. To verify this hypothesis, you can use ps -x. Or: ps -lx | grep 'ssh[d]' -- Raul
Re: Maybe OT: OpenSSH connection failure unless verbose
Quartz wrote: Searching the web for info is worthless because the first thing everybody tells you to do when debugging a connection issue is enable verbose, which obviously doesn't help me here. Likewise, I can't even confirm if anyone else has even experienced this sort of failure before since searching for connection/failure/verbose related keywords yields nothing but self-help related noise. I have limited access to their server too- I don't have and can't get a password (it's key only), so I don't know where to even start figuring this out. ktrace and tcpdump.
Re: Maybe OT: OpenSSH connection failure unless verbose
On Sat, Aug 1, 2015 at 10:58 AM, Quartz qua...@sneakertech.com wrote: That's a good question, I'm not actually sure if I've ever opened two connections to it at once. For better or worse today is a good day so I'll have to wait to test this. If you are only creating one ssh connection, does good day mean you have succeeded just once? If so, can you take a look at whether you are getting any fresh processes from your second connection attempts when they stall? (The question is: how far does a stalled attempt reach before it runs into this problem?) Not sure what you mean here about fresh processes, do you want me to look at the output of ps or something else? Exactly. Probably ps -l (or maybe install and use pstree). Do you get new processes with sshd as a parent? -- Raul
Re: Maybe OT: OpenSSH connection failure unless verbose
good day: ssh user@server = works just like it should What about ssh -v user@server on a good day? That works exactly as expected. ssh-ing in right now And more specifically, if you run ssh -v on both a good day and a bad day, what does diff between the two outputs show? IIRC, not much... I think I did that before once or twice. It's been OK today so I'll have to wait to confirm.
Re: Maybe OT: OpenSSH connection failure unless verbose
If you are only creating one ssh connection, does good day mean you have succeeded just once? No, I mean that I can ssh in without having to pass -v on the command line. In other words, it works the way it normally should. More specifically: good day: ssh user@server = works just like it should bad day: ssh user@server = no connection, no output... just hangs. ssh -v user@server = prints the expected debug info and connects as it should (...usually. Sometimes I have to specify -vv)
Re: Maybe OT: OpenSSH connection failure unless verbose
Thus said Quartz on Sat, 01 Aug 2015 19:00:56 -0400: good day: ssh user@server = works just like it should What about ssh -v user@server on a good day? And more specifically, if you run ssh -v on both a good day and a bad day, what does diff between the two outputs show? Andy -- TAI64 timestamp: 400055bd5813
Re: Maybe OT: OpenSSH connection failure unless verbose
Quartz wrote: ktrace and tcpdump. I should have mentioned that the laptop is using OpenSSH but it's OSX not OpenBSD. ktrace was replaced with I think dtrace on OSX a while ago, so I'll have to look into how to get that set up. As for tcpdump, I'm not sure what I'd be looking for there. Most of the connection meat would be encrypted anyway though, wouldn't it? more generally, see where it's stopping. the pattern of traffic should be roughly the same. two packets that way, one packet this way, etc. perhaps you can determine if the client is waiting for the server, or the server for the client, or if only packets of 1337 bytes cause trouble, etc. you have a scenario where sometimes it works and sometimes not, based on whether the normal introspection capabilities are used. so use a different set of inspection capabilities to find the difference.
Re: Maybe OT: OpenSSH connection failure unless verbose
ktrace and tcpdump. I should have mentioned that the laptop is using OpenSSH but it's OSX not OpenBSD. ktrace was replaced with I think dtrace on OSX a while ago, so I'll have to look into how to get that set up. As for tcpdump, I'm not sure what I'd be looking for there. Most of the connection meat would be encrypted anyway though, wouldn't it? more generally, see where it's stopping. the pattern of traffic should be roughly the same. two packets that way, one packet this way, etc. perhaps you can determine if the client is waiting for the server, or the server for the client, or if only packets of 1337 bytes cause trouble, etc. OK fair enough I guess. I'll have to record several sessions to different machines along with a broken session to the server, then compare the whole lot side by side. Knowing my luck it'll be fine for the next few days until I've forgotten and then go bad again.
Maybe OT: OpenSSH connection failure unless verbose
I'm not sure if this is the right place to ask about this, but I can't seem to find an ssh-specific mailing list or web forum anywhere. I have a bog standard setup between a laptop and a local university that uses a bog standard id_rsa key for password-less access; to the best of my knowledge there's nothing remotely unusual about the ssh configuration on the laptop (I'm less sure about the university server since I don't have access to its config). About maybe 1/3 of the days I try to log into the server, the ssh connection hangs forever with no output UNLESS -v is specified on the command line, in which case it works totally fine. This is completely repeatable: no verbose, no worky (but only on bad days; on good days it works fine regardless). I've only ever experienced this problem with the connection to this one university, ssh otherwise works as expected connecting to every other machine. Searching the web for info is worthless because the first thing everybody tells you to do when debugging a connection issue is enable verbose, which obviously doesn't help me here. Likewise, I can't even confirm if anyone else has even experienced this sort of failure before since searching for connection/failure/verbose related keywords yields nothing but self-help related noise. I have limited access to their server too- I don't have and can't get a password (it's key only), so I don't know where to even start figuring this out. Any ideas?
Re: Alleged OpenSSH bug
On Thu, Jul 23, 2015 at 11:38:27PM +0200, Marc Espie wrote: On Thu, Jul 23, 2015 at 12:29:37PM -0400, Garance A Drosehn wrote: On 23 Jul 2015, at 10:06, Emilio Perea wrote: To me it looks like a mistimed April Fools' joke, but hope somebody more knowledgeable will respond: https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authe ntication-brute-force-vulnerability-maxauthtries-bypass/ It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. I'm told that another way to avoid the problem is to set 'KbdInteractiveAuthentication no'. I'm also told that there is a patch for the oversight in OpenSSH's code, and that can be seen at: https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab Not surprisingly, as the patch clearly shows, the problem is right smack in the middle of USE_PAM code. I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM. As usual. LOTS of security holes in authentication systems stem from PAM. Why ? Because that stuff is over designed. Difficult to configure. Gives you MORE than you need to hang yourself several times over. It's been that way for as long as I can remember. I recall discussing things with one of the authors of PAM, about ten years ago (forgive me for not remembering names at this point). What struck me is that it looks as if PAM wasn't designed to be secure. It's an authentication system, yet it's surprisingly easy to get it to fail open. Yet it's complex enough that there are bad interactions all over the place. Heck, you have to write software defensively if you want PAM to not fuck you over. I really don't see why it's still used. Why the systems that think they must have PAM haven't scraped that pile of goo and tried to put something sensible in its stead. (I have some hypothesis about that. That some kids love complexity, and think that more complex is more shiny, hence better) Okay, let's admit that the *portable* version of openssh wasn't programmed in a way that's paranoid enough about the failure modes of pam. Hi Marc et al. The flaw is orthogonal to PAM. In a nutshell, the OpenSSH server queries a specific keyboard-interactive device as many times as it's listed in the submethod field of a given userauth request (likely never the intent). The portable version can support three such devices: pam, bsdauth, and skey. OpenBSD supports bsdauth. So, a client could trigger three queries to the foo device per userauth request with: -oKbdInteractiveDevices=foo,foo,foo MaxAuthTries is a constraint on userauth requests (not device queries) so assuming the default value of 6, the above client-supplied device list results in 18 queries to foo (not 6). A brute-force attack can leverage this to be more economical in terms of the number of connections used and that might prove to be of some benefit. For example, against an ips/ids that uses connection-based heuristics. In any event, contrary to what's being reported regarding this flaw in technical news sites and blogs, the sky's not falling. No need to stock up on canned tuna and bottled water just yet. Below's an example of the flaw on OpenBSD 5.6. --mancha === mancha@fugu:~$ uname -a OpenBSD fugu 5.6 GENERIC.MP#333 amd64 mancha@fugu:~$ ssh -oNumberOfPasswordPrompts=6 mancha:skey@localhost otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for mancha from 127.0.0.1 port 34310 ssh2 mancha@fugu:~$ ssh -oNumberOfPasswordPrompts=6 -oKbdInteractiveDevices=bsdauth,bsdauth mancha:skey@localhost otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for mancha from 127.0.0.1 port 24472 ssh2 [demime 1.01d removed an attachment of type application/pgp
Re: Alleged OpenSSH bug
There's one obvious thing I totally forgot to mention, but the initial spin put on this issue is *all wrong*. Calling that an OpenSSH bug is, pure and simple, slander. If anything, it is a PAM bug. Or you can say it's a system integration bug on FreeBSD. Calling that an OpenSSH bug just because OpenSSH does not take all the necessary paranoid measures required by an insane auth system is an over-simplification that goes in one specific direction. To throw mud in openssh direction. But yeah, it's SO SIMPLE to try to blame the openssh team (because you know, they're full of ubris) instead of putting the blame where the blame is. - treat passwords hashing as something mundane (FreeBSD). For sure it's not your task to make it hard to brute force password. - treat authentication as a maze (PAM). For sure, it's not your task to make things clear and simple so that configuration mistakes HAPPEN ALL THE TIME. - put all the blame on openssh, because you know, they're the only guys who have a clue about what's going on. - forget to mention this specific issue happens on ONE particular system due to ONE specific set of conditions. Do not EVERY try it everywhere. Publish first. Leaving it to the OpenBSD developers to reassert that this ONLY affects one *specific* deployment of OpenSSH. Here, I'll give you my root password. You can now exploit my machine.
Re: Alleged OpenSSH bug
On Thu, 23 Jul 2015 18:12:28 -0400 Garance A Drosehn wrote: to write software defensively if you want PAM to not fuck you over. It happens that I'm setting up some new (to me) RHEL 7 systems right now, and way too much time has been spent fighting with PAM (and I'm not done yet). So I'll energetically agree with everything Marc says here. Just a few days ago I was talking with one of other systems-programmers here at RPI saying how all of PAM should be ripped out and done over. We happened to be talking about a different failure scenario, but it (PAM) has always been a headache for me, almost every time I've dealt with it. Actually it is perfectly well engineered to bring in support revenues to RedHat. Forgive my cynicism but I wouldn't be surprised, I also wouldn't be surprised if banks probably changed the contactless cards design in the UK *after* the security audit and refused to fix it for over two years before apple paid news agencies to make a fuss upon release of apple pay because banks want large fraud numbers to give them somewhere to hide their own financial engineering and may have to invent some new fraud causing systems if forced to fix the blatant idiocy. p.s. The guidance is to use pubkey or long passwords in which case you should either have no problem or notice the cpu cycles if your an admin worth any salt.
Re: Alleged OpenSSH bug
Em 24-07-2015 14:27, Kevin Chadwick escreveu: The guidance is to use pubkey or long passwords in which case you should either have no problem or notice the cpu cycles if your an admin worth any salt. There are tons of info regarding OpenSSH best practices. The link bellow [1] is one of them. I personally let my servers with only the state of the art, which currently is ed25519 for both PubKeys and HostKeys, chacha for cipher, curve25519 for kex and hmac-etm for mac. [1] https://wiki.mozilla.org/Security/Guidelines/OpenSSH
Re: Alleged OpenSSH bug
Em 23-07-2015 18:10, Ted Unangst escreveu: Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive. Yep. Others also told me this off list. I already sorted things out with the OP. But, truth is, that this bug is being sold by others, including news sites, as The BUG. It's hard to stay over the fence when things like this happen. Perhaps I need to drink less coffee and see what that thing called meditation is all about. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
On 23 Jul 2015, at 17:38, Marc Espie wrote: Not surprisingly, as the patch clearly shows, the problem is right smack in the middle of USE_PAM code. I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM. As usual. LOTS of security holes in authentication systems stem from PAM. Why ? Because that stuff is over designed. Difficult to configure. Gives you MORE than you need to hang yourself several times over. It's been that way for as long as I can remember. I recall discussing things with one of the authors of PAM, about ten years ago (forgive me for not remembering names at this point). What struck me is that it looks as if PAM wasn't designed to be secure. It's an authentication system, yet it's surprisingly easy to get it to fail open. Yet it's complex enough that there are bad interactions all over the place. Heck, you have to write software defensively if you want PAM to not fuck you over. It happens that I'm setting up some new (to me) RHEL 7 systems right now, and way too much time has been spent fighting with PAM (and I'm not done yet). So I'll energetically agree with everything Marc says here. Just a few days ago I was talking with one of other systems-programmers here at RPI saying how all of PAM should be ripped out and done over. We happened to be talking about a different failure scenario, but it (PAM) has always been a headache for me, almost every time I've dealt with it. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: Alleged OpenSSH bug
On Thu, Jul 23, 2015 at 5:10 PM, Ted Unangst t...@tedunangst.com wrote: Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive. Given that the last (and first) remote exploit against openssh *was* in the last century, IIRC, he could still be correct to call it the hole of the century... :) Heh. (apologies for the previous blank email :( )
Re: Alleged OpenSSH bug
Em 23-07-2015 16:43, Garance A Drosehn escreveu: As noted in my message, I did actually test it on a variety of systems. You mentioned FreeBSD boxes and a Mac. That ain't a variety of systems. I happened to avoid it on my systems, but that was more by luck than any cleverness on my part. This says a lot about you. The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. You were condescending, admit it. Quoting you: I'm also told that there is a patch for the oversight in OpenSSH's code There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should stop being lazy and use OpenSSH as close as upstream as possible and even better, with no portable glue code. You don't need PAM, specially if you're using PubKeyAuthentication. If you must use OpenSSH portable, at least bother enough to secure it. The patch wasn't provided because of a bug in OpenSSH code, it was provided because people are lazy, and wouldn't fix their own PAM configuration. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
On Thu, Jul 23, 2015 at 5:10 PM, Ted Unangst t...@tedunangst.com wrote: Giancarlo Razzolini wrote: The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. You were condescending, admit it. Quoting you: I'm also told that there is a patch for the oversight in OpenSSH's code There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive.
Re: Alleged OpenSSH bug
On Thu, Jul 23, 2015 at 12:29:37PM -0400, Garance A Drosehn wrote: On 23 Jul 2015, at 10:06, Emilio Perea wrote: To me it looks like a mistimed April Fools' joke, but hope somebody more knowledgeable will respond: https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/ It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. I'm told that another way to avoid the problem is to set 'KbdInteractiveAuthentication no'. I'm also told that there is a patch for the oversight in OpenSSH's code, and that can be seen at: https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab Not surprisingly, as the patch clearly shows, the problem is right smack in the middle of USE_PAM code. I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM. As usual. LOTS of security holes in authentication systems stem from PAM. Why ? Because that stuff is over designed. Difficult to configure. Gives you MORE than you need to hang yourself several times over. It's been that way for as long as I can remember. I recall discussing things with one of the authors of PAM, about ten years ago (forgive me for not remembering names at this point). What struck me is that it looks as if PAM wasn't designed to be secure. It's an authentication system, yet it's surprisingly easy to get it to fail open. Yet it's complex enough that there are bad interactions all over the place. Heck, you have to write software defensively if you want PAM to not fuck you over. I really don't see why it's still used. Why the systems that think they must have PAM haven't scraped that pile of goo and tried to put something sensible in its stead. (I have some hypothesis about that. That some kids love complexity, and think that more complex is more shiny, hence better) Okay, let's admit that the *portable* version of openssh wasn't programmed in a way that's paranoid enough about the failure modes of pam.
Re: Alleged OpenSSH bug
On 23 Jul 2015, at 13:33, Theo de Raadt wrote: My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. So try it on some other system without that setting. We'll wait. Then come come back and report whether your observations are identical or subtly different. As noted in my message, I did actually test it on a variety of systems. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. That has effectively the same authentication system as FreeBSD, same fast password check, etc. I'm also told that there is a patch for the oversight in OpenSSH's code, and that can be seen at: https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab It was an oversight, and on most systems it has limited impact, because repeated session connects can still be used by people to run the passwd check ciphers at full speed. It affects some operating systems to a much larger degree. Your statements sound like advocacy. No, it was not meant as advocacy. I'm just reporting what I found out from my own tests, and tests that others have done. And even by my own reports, the default FreeBSD config does exhibit this problem. I happened to avoid it on my systems, but that was more by luck than any cleverness on my part. The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: Alleged OpenSSH bug
Giancarlo Razzolini wrote: The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. You were condescending, admit it. Quoting you: I'm also told that there is a patch for the oversight in OpenSSH's code There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive.
Re: Alleged OpenSSH bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/15 16:06, Emilio Perea wrote: To me it looks like a mistimed April Fools' joke, but hope somebody more knowledgeable will respond: https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/ I'll bite. In my *very* limited testing, using variations of the first ssh command in that blog post, none of my OpenBSD boxes with fairly pristine out of the box /etc/ssh/sshd_config permitted more than three tries before closing the connection. I also tested some Linux boxes (CentOS 6.something) with the same result. However, running that command pinting at a FreeBSD 10.1 box in my care gave more than three tries. I aborted well before reaching 1 for obvious reasons. I'm sure developers with more intimate knowledge of the code in question can fill in some gaps. - -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. iQIcBAEBAgAGBQJVsPcvAAoJELJiGF9h4Dye0PUP+gNAIEKaZuLxN3wtpGF2+cbk pgeU2ktuEXHHSm3Zo0OEoUGOQcyb01oAR4jtBn8ofHqy5pl1nkFz44bbttjfwKoQ tuCjtt4SKTe9rth1rfNQnUXKZeMCJfoUuupi+tShj61zlfq3xlYfa33wotx2FOy9 XKaX6Nq9k6pFsHJJeDuka/jsiFcMq4nxT6kgZACW4owolDuzIRhLbLRDwPOi+do6 JyBrOitPVBO52uhH1LFDQIYuut7oLMqA7FHvFOUVap2YsQfsqV1KqQrETrT8dwSE rzuV0ZKd8wO7DsvpJX3X4p1Ww3Y+XviGdBx30tbuG/99evhiWhH26zf4D05tzzJu TegsLgwcPvg1HjE8CjFnPx3XkYvRlD7oVWpG66QixdW2mW7dNKA2qnm/saaA9q3s zMtFk3e+I98iDR03lLzYaASFPKEwIw1o/nvr2WYq9RZtyzKSR2NT9yYsdbfdcHJu Vb3qtrsX1lZFfNQT8ojcREbK8s2w+Zptt/poWe8E+u43VtgtvcQUsML0KZQPCObk ZMJexU3+YSdIRKbpM5D2tvdgvhgHXGwt+HAJKhEt8clf/X1s+cv13ktU9iim/O3V brTXZWM/SAM49Hg/9i2p8zHQQft/bvDWlu6hyvrViMAjIDqhrUYd7m2gTzuAgQaL BKIu5nNh58RfIPeUDDax =Xum/ -END PGP SIGNATURE-
Alleged OpenSSH bug
To me it looks like a mistimed April Fools' joke, but hope somebody more knowledgeable will respond: https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/
Re: Alleged OpenSSH bug
Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: In my *very* limited testing, using variations of the first ssh command in that blog post, none of my OpenBSD boxes with fairly pristine out of the box /etc/ssh/sshd_config permitted more than three tries before closing the connection. I also tested some Linux boxes (CentOS 6.something) with the same result. I have tested the command with various linux (CentOS 6, Ubuntu 12.04, 14.04, 15.04, Archlinux, plus some others) and OpenBSD (5.4, 5.5, 5.6 and 5.7) machines, and none of them were vulnerable. I don't have any FreeBSD machine available to test it. But it seems to be the only OS affected. I'm betting that they have some bad interaction between the openssh configuration and their PAM configuration. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. That's why Dr. House doesn't allow exotic things to be ported to OpenBSD. You Can't Always Get What You Want. Seriously, dlopen of kerberos-grade software never hurt anyone (yet).
Re: Alleged OpenSSH bug
On 23 Jul 2015, at 10:06, Emilio Perea wrote: To me it looks like a mistimed April Fools' joke, but hope somebody more knowledgeable will respond: https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/ It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. I'm told that another way to avoid the problem is to set 'KbdInteractiveAuthentication no'. I'm also told that there is a patch for the oversight in OpenSSH's code, and that can be seen at: https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: Alleged OpenSSH bug
Em 23-07-2015 13:29, Garance A Drosehn escreveu: It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. Yes, it seems so. Going through the source code and the openssh-unix-dev mail list, I see that it's indeed an issue that could affect a lot of machines. But it depends on the right (wrong) combination of factors which, unfortunately, FreeBSD has. Using the default ssh configuration you need to append the Konsole output -o NumberOfPasswordPrompts=1 option for being able to test this bug. My first attempts didn't had this. But I still can't replicate it on linux hosts. I can reproduce it on Mac's too. And it's as nasty as on FreeBSD. The problem is with the KbdInteractiveAuthentication option, which defaults to the same value of ChallengeResponseAuthentication which in turn has the yes default. If there are any forms of PAM authentication delays, they still apply. But that could perhaps be overcome with some kind of distributed attack, with many connections opened. Cheers, Giancarlo Razzolini Konsole output
Re: Alleged OpenSSH bug
It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. Some operating systems have extremely fast passwd checks, others have slow ones. FreeBSD seems to be the worst affected because their PAM integration does not terminate the loop itself; it think it has no limit. Pay close attention and you will see you are replying to others who actually tested it on other systems. The issue is being overplayed by a fair bit. Yes, on some systems with careless authentication systems, many passwd checks can happen in one pre-auth session. However, even with this fixed, someone can do many, many sequential pre-auth sessions with less setup, and approach the same speeds. Only downside is they may be exposed by the extra logging. The issue comes to the fore *because* each passwd check is so cheap. In 1999, OpenBSD made moves to improve things, you may have heard of something called bcrypt... 16 years later, FreeBSD is now on their second successive generation of passwd crypt algorithm, having ignored the lessons. These layers fit together. One specific system had zero mitigations. My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. So try it on some other system without that setting. We'll wait. Then come come back and report whether your observations are identical or subtly different. This issue does not have the same scale of impact on all operating systems. One operating system is affected far more than the others. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. That has effectively the same authentication system as FreeBSD, same fast password check, etc. I'm also told that there is a patch for the oversight in OpenSSH's code, and that can be seen at: https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab It was an oversight, and on most systems it has limited impact, because repeated session connects can still be used by people to run the passwd check ciphers at full speed. It affects some operating systems to a much larger degree. Your statements sound like advocacy. I'll throw some back at you for fun. It seems too easy for FreeBSD folk to throw accusations at OpenSSH and the greater OpenBSD dev community, when the rich commercial sphere surrounding FreeBSD has never given a penny and gets all this for free. Why does FreeBSD PAM not have a counter in it to prevent this by itself? Why does it have super-fast passwd checks? Are those not oversights as well?
Re: Alleged OpenSSH bug
But it depends on the right (wrong) combination of factors which, unfortunately, FreeBSD has. Exactly.
Re: Alleged OpenSSH bug
On 7/23/2015 12:29 PM, Garance A Drosehn wrote: On 23 Jul 2015, at 10:06, Emilio Perea wrote: [snip] It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. My freebsd boxes do *not* have the problem, but that's because I have set 'ChallengeResponseAuthentication no'. I don't even remember why I set that on my freebsd boxes. I change very few settings, but for some reason I decided to change that one. [snip] When you set ChallengeResponseAuthentication to no, the pop-up Enter your Authentication Response that appears after you enter your password is suppressed.
Re: Alleged OpenSSH bug
On 23 July 2015 at 09:15, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: However, running that command pinting at a FreeBSD 10.1 box in my care gave more than three tries. I aborted well before reaching 1 for obvious reasons. Digging some more, I've found this: http://seclists.org/oss-sec/2015/q3/156 It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. And there's this: https://lists.freebsd.org/pipermail/freebsd-security/2015-July/008527.html Hopes to have it corrected before the next freebsd release. Cheers, Giancarlo Razzolini -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: Alleged OpenSSH bug
Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: However, running that command pinting at a FreeBSD 10.1 box in my care gave more than three tries. I aborted well before reaching 1 for obvious reasons. Digging some more, I've found this: http://seclists.org/oss-sec/2015/q3/156 It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. That's why Dr. House doesn't allow exotic things to be ported to OpenBSD. You Can't Always Get What You Want.
Re: openssh client alive not default
On Sat, Jun 27, 2015 at 05:10:54PM -0700, jungle Boogie wrote: Hello All, I know fewer defaults the better for all, but if there a reason TCPKeepAlive in openssh is disabled along with the clientalive option? Is it just too risky and/or unneeded? Well, Mr. Boogie, TCPKeepAlive is enabled and ClientAliveInterval is 0, which is disabled, in both 5.7 and -current, if I'm reading the source file correctly. And, according to sshd_config(5), It is important to note that the use of client alive messages is very different from TCPKeepAliveThe client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. How do you folks manage ssh sessions not dying? Do you enable these options every time you install openssh on a new machine? Is there a better option? The man page continues with, The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. I don't adjust the defaults for these. I use some terrible WiFi connections and occaisionally have to reconnect. If I need to keep a shell running in the event of an unintentional disconnect --- or an intentional one -- I use tmux(1). I can reconnect and continue operating one or more shells without any operational impact.
openssh client alive not default
Hello All, I know fewer defaults the better for all, but if there a reason TCPKeepAlive in openssh is disabled along with the clientalive option? Is it just too risky and/or unneeded? How do you folks manage ssh sessions not dying? Do you enable these options every time you install openssh on a new machine? Is there a better option? -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: openssh client alive not default
On 2015-06-28 02:59, Josh Grosse wrote: How do you folks manage ssh sessions not dying? Do you enable these options every time you install openssh on a new machine? Is there a better option? The man page continues with, The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. I don't adjust the defaults for these. I use some terrible WiFi connections and occaisionally have to reconnect. If I need to keep a shell running in the event of an unintentional disconnect --- or an intentional one -- I use tmux(1). I can reconnect and continue operating one or more shells without any operational impact. Also keep in mind that keepalives are both a blessing and a curse... On the one hand, they can save you from those horrible home routers (mostly) that timeout your TCP sessions after a while (often a non-configurable, but invariably too short, while at that), whether they actually need to conserve their state-keeping space or not. But on the other hand, if you have a stable connection through a REAL (OpenBSD :-) ) firewall, that *doesn't* snip your TCP sessions just for the fun of it, they may actually *cause* a disconnect. Let's say you have an open, but idle, ssh session to your remote server and there's a short outage in the network somewhere between the two endpoints. If there are no keep-alive packets trying to get through and the actual session remains idle, then you'll never notice that there was an outage. But if there are keep-alive packets being sent that never reaches the destination the endpoints will terminate the connection and you will lose your terminal session no matter what. (Moral of the story: +1 for using tmux/screen/nohup/batch/at/whatever to keep long-running jobs safe. And when interactive, save your work often. :-) ) Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: openssh client alive not default
Hi Josh, On 27 June 2015 at 17:59, Josh Grosse j...@jggimi.homeip.net wrote: On Sat, Jun 27, 2015 at 05:10:54PM -0700, jungle Boogie wrote: Hello All, I know fewer defaults the better for all, but if there a reason TCPKeepAlive in openssh is disabled along with the clientalive option? Is it just too risky and/or unneeded? Well, Mr. Boogie, TCPKeepAlive is enabled and ClientAliveInterval is 0, which is disabled, in both 5.7 and -current, if I'm reading the source file correctly. I'm sure you're reading it correctly. Maybe in the portable its disabled, I'll have to check closely. And, according to sshd_config(5), It is important to note that the use of client alive messages is very different from TCPKeepAliveThe client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. quite interesting, thanks! How do you folks manage ssh sessions not dying? Do you enable these options every time you install openssh on a new machine? Is there a better option? The man page continues with, The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. I don't adjust the defaults for these. I use some terrible WiFi connections and occaisionally have to reconnect. If I need to keep a shell running in the event of an unintentional disconnect --- or an intentional one -- I use tmux(1). I can reconnect and continue operating one or more shells without any operational impact. Yes, tmux is wonderful and I'm thankful for Nicholas' work on it! The problem is if you're doing reverse tunnelling, the tmux connection doesn't really solve that problem, though. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: openssh client alive not default
On 27 June 2015 at 18:17, Benny Lofgren bl-li...@lofgren.biz wrote: Let's say you have an open, but idle, ssh session to your remote server and there's a short outage in the network somewhere between the two endpoints. If there are no keep-alive packets trying to get through and the actual session remains idle, then you'll never notice that there was an outage. But if there are keep-alive packets being sent that never reaches the destination the endpoints will terminate the connection and you will lose your terminal session no matter what. Ah, that's a very interesting and likely to happen example. ssh sessions can die when you don't have these two enabled but it seems to take much longer. (Moral of the story: +1 for using tmux/screen/nohup/batch/at/whatever to keep long-running jobs safe. And when interactive, save your work often. :-) ) my favorite is definitely tmux! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Microsoft will support and contribute to OpenSSH (and they're excited! :)
http://blogs.msdn.com/b/looking_forward_microsoft__support_for_secure_shell_ssh1/archive/2015/06/02/managing-looking-forward-microsoft-support-for-secure-shell-ssh.aspx I’m pleased to announce that the PowerShell team will support and contribute to the OpenSSH community - Very excited to work with the OpenSSH community to deliver the PowerShell and Windows SSH solution! \o/
Re: Microsoft will support and contribute to OpenSSH (and they're excited! :)
On Tue, June 2, 2015 22:40, Артур Истомин wrote: http://blogs.msdn.com/b/looking_forward_microsoft__support_for_secure_shell_ssh1/archive/2015/06/02/managing-looking-forward-microsoft-support-for-secure-shell-ssh.aspx I?m pleased to announce that the PowerShell team will support and contribute to the OpenSSH community - Very excited to work with the OpenSSH community to deliver the PowerShell and Windows SSH solution! \o/ unix ssh windoze.domain.loc Администратор@windoze.domain.loc's password: PowerShell Profit?
Re: OpenSSH and Android
On Fri, 8 May 2015 11:02:25 +1000
Darren Tucker wrote:
What gcc version was that? Anyway...
Using built-in specs.
COLLECT_GCC=/home/kc/lib/andtool/bin/arm-linux-androideabi-gcc
COLLECT_LTO_WRAPPER=/home/kc/lib/andtool/bin/../libexec/gcc/arm-linux-androideabi/4.8/lto-wrapper
Target: arm-linux-androideabi
Configured with: /s/ndk-toolchain/src/build/../gcc/gcc-4.8/configure
--prefix=/tmp/ndk-andrewhsieh/build/toolchain/prefix
--target=arm-linux-androideabi --host=x86_64-linux-gnu
--build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld
--enable-languages=c,c++
--with-gmp=/tmp/ndk-andrewhsieh/build/toolchain/temp-install
--with-mpfr=/tmp/ndk-andrewhsieh/build/toolchain/temp-install
--with-mpc=/tmp/ndk-andrewhsieh/build/toolchain/temp-install
--with-cloog=/tmp/ndk-andrewhsieh/build/toolchain/temp-install
--with-isl=/tmp/ndk-andrewhsieh/build/toolchain/temp-install
--with-ppl=/tmp/ndk-andrewhsieh/build/toolchain/temp-install
--disable-ppl-version-check --disable-cloog-version-check
--disable-isl-version-check --enable-cloog-backend=isl
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm' --disable-libssp --enable-threads --disable-nls
--disable-libmudflap --disable-libgomp --disable-libstdc__-v3
--disable-sjlj-exceptions --disable-shared --disable-tls
--disable-libitm --with-float=soft --with-fpu=vfp --with-arch=armv5te
--enable-target-optspace --enable-initfini-array --disable-nls
--prefix=/tmp/ndk-andrewhsieh/build/toolchain/prefix
--with-sysroot=/tmp/ndk-andrewhsieh/build/toolchain/prefix/sysroot
--with-binutils-version=2.24 --with-mpfr-version=3.1.1
--with-mpc-version=1.0.1 --with-gmp-version=5.0.5
--with-gcc-version=4.8 --with-gdb-version=7.6
--with-python=/usr/local/google/home/andrewhsieh/mydroid/ndk/prebuilt/linux-x86_64/bin/python-config.sh
--with-gxx-include-dir=/tmp/ndk-andrewhsieh/build/toolchain/prefix/include/c++/4.8
--with-bugurl=http://source.android.com/source/report-bugs.html
--enable-languages=c,c++ --disable-bootstrap --enable-plugins
--enable-libgomp --disable-libsanitizer --enable-gold
--enable-graphite=yes --with-cloog-version=0.18.0
--with-isl-version=0.11.1 --enable-eh-frame-hdr-for-static
--with-arch=armv5te
--program-transform-name='s^arm-linux-androideabi-'
--enable-gold=default Thread model: posix gcc version 4.8 (GCC)
openbsd-compat/openbsd-compat.h:217:22:
error: expected identifier or '(' before numeric constant
# define mblen(x, y) 1
The obvious thing to try would be to change that to:
# define mblen(x, y) (1)
Didn't change the output at all
In case your interested, I've attached the config.logs for the openssh
compile fail with openssl and openssh configure fail with libressl.
(BTW openssh-unix-...@mindrot.org is the best place to get help with
portable OpenSSH. See http://www.openssh.com/report.html for details.)
Ok
[demime 1.01d removed an attachment of type text/x-log]
[demime 1.01d removed an attachment of type text/x-log]
OpenSSH AESNI support
Hi, I've a smallish system which does a lot of SFTP work, and CPU seems to be the bottleneck constantly (this was discussed on a previous thread over a year ago). I've finally decided to replace that CPU, but I'm wondering: Does OpenSSH support/use the AESNI instruction set if available? The documentation indicates that access to crypto(9) is disabled for userland by default, but I'm not sure if AESNI access is done via crypto(9) or some other means. Also, if it does support it, should a patch for the man page to indicate this (for other in my scenario) be acceptable? Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenSSH AESNI support
On 2015-05-07 10:57, Christian Weisgerber wrote: On 2015-05-07, Hugo Osvaldo Barrera h...@barrera.io wrote: I've finally decided to replace that CPU, but I'm wondering: Does OpenSSH support/use the AESNI instruction set if available? Yes, by way of OpenSSL/LibreSSL, which make use of AESNI if available. if AESNI access is done via crypto(9) or some other means. The crypto(9) interface was designed for crypto accelerators that appear as devices separate from the CPU and require a kernel driver. By contrast, AESNI instructions can be directly used in userland code. -- Christian naddy Weisgerber na...@mips.inka.de Couldn't have been clearer. Thanks. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenSSH and Android
On Thu, May 7, 2015 at 11:19 PM, Kevin Chadwick m8il1i...@gmail.com wrote:
So nevermind, connectbot will have to do for now unless someone has a
cluestick to hand.
What gcc version was that? Anyway...
openbsd-compat/openbsd-compat.h:217:22:
error: expected identifier or '(' before numeric constant
# define mblen(x, y) 1
The obvious thing to try would be to change that to:
# define mblen(x, y) (1)
(BTW openssh-unix-...@mindrot.org is the best place to get help with
portable OpenSSH. See http://www.openssh.com/report.html for details.)
--
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.
OpenSSH and Android
So I found this https://github.com/nathan-osman/AndroX/blob/master/README.md but after updating it to use the latest sources and building LibreSSL and OpenSSL: I got a configure error for LibreSSL. OpenSSL headers missing Adding --with-cppflags=-I/home/kc/AndroX/install/include to the below I got Can't find recent OpenSSL libcrypto /usr/bin/env PATH=$PATH:/home/kc/lib/andtool/bin ./configure --prefix=/home/kc/AndroX/install --host=arm-linux-androideabi --with-ssl-dir=/home/kc/AndroX/install I got the same issue as here for trying to cross build OpenSSH with OpenSSL http://w3facility.org/question/error-compiling-openssh-with-android-ndk/ So nevermind, connectbot will have to do for now unless someone has a cluestick to hand.
Re: OpenSSH AESNI support
On 2015-05-07, Hugo Osvaldo Barrera h...@barrera.io wrote: I've finally decided to replace that CPU, but I'm wondering: Does OpenSSH support/use the AESNI instruction set if available? Yes, by way of OpenSSL/LibreSSL, which make use of AESNI if available. if AESNI access is done via crypto(9) or some other means. The crypto(9) interface was designed for crypto accelerators that appear as devices separate from the CPU and require a kernel driver. By contrast, AESNI instructions can be directly used in userland code. -- Christian naddy Weisgerber na...@mips.inka.de
Re: OpenSSH for Android
On 2015-05-05, Bertrand Caplet bertrand.cap...@chunkz.net wrote: Hey, I'm using JuiceSSH it's pretty good and free, but I don't know about ciphers... JuiceSSH uses http://www.jcraft.com/jsch/ for its SSH implementation, which itself relies on JCE for crypto, so there are a couple of layers below JuiceSSH itself where ed25519/poly1305 would need adding.
Re: OpenSSH for Android
I always just use connectbot --- âLanie, Iâm going to print more printers. Lots more printers. One for everyone. Thatâs worth going to jail for. Thatâs worth anything.â - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html On Tue, May 5, 2015 at 8:26 PM, Bertrand Caplet bertrand.cap...@chunkz.net wrote: Hey, I'm using JuiceSSH it's pretty good and free, but I don't know about ciphers... I'm after an openssh client with all it's goodies such as poly cipher (I don't need sshd) for Android rather than dropbear. So I'm looking at the following with Androids NDK. http://kevinboone.net/kbox3.html http://kevinboone.net/android_native.html Anyone have a simpler/other option. I don't want an entire debian install just for ssh though. -- CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: 37F70C30 GPG FP: 134A 4027 518B 5F4D D409 558D BA9B 7BF0 37F7 0C30 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenSSH for Android
Hey, I'm using JuiceSSH it's pretty good and free, but I don't know about ciphers... I'm after an openssh client with all it's goodies such as poly cipher (I don't need sshd) for Android rather than dropbear. So I'm looking at the following with Androids NDK. http://kevinboone.net/kbox3.html http://kevinboone.net/android_native.html Anyone have a simpler/other option. I don't want an entire debian install just for ssh though. -- CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: 37F70C30 GPG FP: 134A 4027 518B 5F4D D409 558D BA9B 7BF0 37F7 0C30 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
