Contributed by grey on from the be sure to buy one of the newT-shirts to support the project! dept.
List: openssh-unix-dev Subject: OpenSSH 4.0 released From: Damien MillerDate: 2005-03-09 9:54:13 Message-ID: <200503090954.j299sDng029163 () cvs ! openbsd ! org> OpenSSH 4.0 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters. We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18 For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 3.9: ============================ * ssh(1) now allows the optional specification of an address to bind to in port forwarding connections (local, remote and dynamic). Please refer to the documentation for the -L and -R options in the ssh(1) manual page and the LocalForward and RemoteForward options in the ssh_config(5) manpage. (Bugzilla #413) * To control remote bindings while retaining backwards compatibility, sshd(8)'s GatewayPorts option has been extended. To allow client specified bind addresses for remote (-R) port forwardings, the server must be configured with "GatewayPorts clientspecified". * ssh(1) and ssh-keyscan(1) now support hashing of host names and addresses added to known_hosts files, controlled by the ssh(1) HashKnownHosts configuration directive. This option improves user privacy by hiding which hosts have been visited. At present this option is off by default, but may be turned on once it receives sufficient testing. * Added options for managing keys in known_hosts files to ssh-keygen(1), including the ability to search for hosts by name, delete hosts by name and convert an unhashed known_hosts file into one with hashed names. These are particularly useful for managing known_hosts files with hashed hostnames. * Improve account and password expiry support in sshd(8). Ther server will now warn in advance for both account and password expiry. * sshd(8) will now log the source of connections denied by AllowUsers, DenyUsers, AllowGroups and DenyGroups (Bugzilla #909) * Added AddressFamily option to sshd(8) to allow global control over IPv4/IPv6 usage. (Bugzilla #989) * Improved sftp(1) client, including bugfixes and optimisations for the ``ls'' command and command history and editing support using libedit. * Improved the handling of bad data in authorized_keys files, eliminating fatal errors on corrupt or very large keys. (Bugzilla #884) * Improved connection multiplexing support in ssh(1). Several bugs have been fixed and a new "command mode" has been added to allow the control of a running multiplexing master connection, including checking that it is up, determining its PID and asking it to exit. * Have scp(1) and sftp(1) wait for the spawned ssh to exit before they exit themselves. This prevents ssh from being unable to restore terminal modes (not normally a problem on OpenBSD but common with -Portable on POSIX platforms). (Bugzilla #950) * Portable OpenSSH: - Add *EXPERIMENTAL* BSM audit support for Solaris systems (Bugzilla #125) - Enable IPv6 on AIX where possible (see README.platform for details), working around a misfeature of AIX's getnameinfo. (Bugzilla #835) - Teach sshd(8) to write failed login records to btmp for unsuccessful auth attempts. Currently this is only for password, keyboard-interactive and challenge/response authentication methods and only on Linux and HP-UX. - sshd(8) now sends output from failing PAM session modules to the user before exiting, similar to the way /etc/nologin is handled - Store credentials from gssapi-with-mic authentication early enough to be available to PAM session modules when privsep=yes. Checksums: ========== - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Ben Lindstrom, Darren Tucker and Tim Rice. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
(Comments are closed)
By Nate (65.95.240.35) on
By djm@ (203.217.30.86) on
MD5 (openssh-4.0p1.tar.gz) = 7b36f28fc16e1b7f4ba3c1dca191ac92
...or just the the PGP signature, it is correct.
Comments
By grey (207.215.223.2) on
http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf is worth taking a look at. I realize it's recent (March 5th), but gives an example of finding a full md5 collision in 8 hours on a notebook, and they're predicting that time will go down once Wang et al release their actual speed up method (perhaps the prediction of 2 minutes is overstating it, but you never know). That said, getting a collision on meaningful substitutes (e.g. a backdoored OpenSSH) might be another challenge, but I doubt it's going to be too much harder if speed keeps increasing.
At any rate, I was wondering - why have just one CRC in the release notes? Why not also provide a sha-1 CRC, or even several different CRC types? As we witness more hashes fall victim to improved collision attacks (there will _always_ be collisions anyways because it's a frigging hash), it's understandable that any individual (md5, sha-1, crc32, whatever) hash will have possible meaningful collisions. However, finding a meaningful collision for -several- different CRC's simultaneously, I would posit is probably very unlikely.
Maybe I'm wrong about that in some cases, as I know sha-1 is based off of previous work from md5. But regardless, it wouldn't be hard to check, just take an example of a two different files wherein they both have the same md5, and then see if they both have the same sha-1 (or crc32, or ripe-md or whatever-the-hell-CRC you want to have as well). Does anyone have two files that have an md5 collision I could test against?
Also, it should be noted (and Jose thankfully reminded me of this at RSAConf when we were discussing hashes briefly) that the OpenBSD ports system already checks several different hashes on distfiles. Just check a /usr/ports/blah/blah/distinfo yourself and you'll see something like this:
So, since we do it in the ports system already, maybe we should look to add it in our release notes as well?
Comments
By grey (207.215.223.2) on
Oh, and if anyone wants to improve the ports system to check all the hashes provided in distinfo, keep in mind that generally reading from disk is the biggest bottleneck in computing hashes, so if the disk could be read once, but several hashes computed simultaneously, that would be bitchin'.
Comments
By mirabile (213.196.227.95) on http://mirbsd.org/
checksums (though I don't know if they check all), and
MirPorts check all available checksums for quite some time
now, shortly after the SHA-1 break announcement.
They both run on OpenBSD as a replacement (possibly also in
parallel) to the OpenBSD Ports Tree.
Oh, and I'm sure you can pull out the diff and apply it
to OpenBSD's bsd.port.mk as well.
By Nikademus (212.88.244.240) on http://www.octools.com
I already have it for quite a while.. :)
Comments
By Anonymous Coward (195.217.242.33) on
By Anthony (68.145.112.234) on
Comments
By Brad (204.101.180.70) brad at comstyle dot com on
By Anonymous Coward (65.198.20.164) on
* Improved sftp(1) client, including bugfixes and optimisations for the ``ls'' command and command history and editing support using libedit
Out of everything, those are two of the features I'd been hoping for. I also wish there was tab completion in sftp.
Comments
By Ben (208.27.203.127) mouring@nospam.eviladmin.org on
Maybe if no one gets to it by next year I'll step up and rewrite my stuff to use libedit.
But not this year... Too much stuff I'm trying to work on. *SIGH*
- Ben
Comments
By Anonymous Coward (24.127.0.74) on
Comments
By Ben (208.27.203.127) mouring@nospam.eviladmin.org on
and the only thing left is finding the glue to let el_gets() know to call it (which escapes me at this moment in history).
No real magic here. =-) Just detective work and playing.. ermm.. I mean coding.
I'd point you to the readline example, but it has ran off along with all the rest of my OpenSSH development since I'm not active anymore.
- Ben
Comments
By Ben (208.27.203.127) mouring@nospam.eviladmin.org on
In function "void controlediting(void)"
So it is cake.=-) Any two bit code monkey can do it.
- Ben
By xhrl (24.80.50.50) on
By oksala (66.130.12.114) ok@ok.com on
By Anonymous Coward (24.34.57.27) on
debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-PZhTm22307/xauthfile generate unix:10.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
(pause 5+ seconds here)
debug2: x11_get_proto: /usr/X11R6/bin/xauth list unix:10.0 . 2>/dev/null
Every other client flies through these lines with no delay on any number of servers. The problem child is Mandrake 10.1, whereas the working clients are Mandrake 9.2, FreeBSD 4.9, and FreeBSD 4.10. Any ideas?
Comments
By Anonymous Coward (24.34.57.27) on
By benjamin s. (212.236.10.2) on
Is it possible, that openssh is simply trying to do a dns-lookup on the ip-address and failing to do so at least implies a certain timeout while doing the dnslookup?
Comments
By Anonymous Coward (24.34.57.27) on
By Anonymous Coward (81.220.245.98) on
Comments
By RC (4.8.16.53) on
> implemented in openssh
It wouldn't make much sense, would it? To use SFTP, you have to have SSH support, so you can always read/transfer those files without using scp/sftp.
> I personally think jailing sftp users as an important security
> thing, because I do not like to see people going in /etc for example.
No, it's really because you don't particularly understand security.
Comments
By Anonymous Coward (84.96.24.154) on
> No, it's really because you don't particularly understand security.
Thank you for your reply. Maybe I should have precised that my point of view is to use sftp as a complete replacement solution for the old traditional ftp (jailing ssh sessions in usual situations really has no sense, you're right). So, what I mean about jailing is just to avoid people going where they do not need to in order to transfer files.
So do you mean that openssh is not particularly designed for file transfer which is just a useful extension, and that a better solution for encrypted file transfer would be ftp over ssl for example?
Comments
By RC (4.8.16.53) on
> transfer which is just a useful extension, and that a better solution
> for encrypted file transfer would be ftp over ssl for example?
No, SSH does a pretty good job with file-transfers. It sounds to me that you haven't progressed very far in your efforts to set-up an ssh server as a file-transfer-only service. This a complicated issue, that I can't just explain to you in a few sentences.
Comments
By Anonymous Coward (81.220.245.98) on
> No, SSH does a pretty good job with file-transfers. It sounds to me that
> you haven't progressed very far in your efforts to set-up an ssh server
> as a file-transfer-only service. This a complicated issue, that I can't
> just explain to you in a few sentences.
Okay, thanks, after having read various stuff on the openssh-dev mailing list and newsgroups about this subject, I understand you have good reasons not to integrate chrooting in the ssh daemon.
Maybe you think about tunneling ftp into ssh. I wonder anyway if there are click'n'play solutions for windows users on the other side.
What would you think about making rssh compilable on bsd (it seems that it is only running on linux for now) and including it as a port, so that complaining people can get satisfied?
Comments
By RC (4.8.16.53) on
> are click'n'play solutions for windows users on the other side.
One of FTP's stupid limitations, is that it uses 2 different ports (read up on active/passive modes). It is technically possible to forward the control connection over SSH, which would protect your password, but not the file data itself. Even doing the former is a VERY complicated process, that won't work in many cases, due to nat/firewalls.
> What would you think about making rssh compilable on bsd
rssh is no longer being developed, and has some obvious and gaping security holes. You could at least go with 'scponly'. However, even with that, you should never consider it secure.
SSH is designed for interactive use, not file transfers, and hacks to get it to work that way have been worked-around many times, and more work-arounds are sure to appear in the future. If you generally trust your users in the first place, scponly may be good enough (with proper permissions on directories). If you're providing file-transfer service to untrusted or anonymous users, you really should find something made with that purpose in-mind, as it is sure to keep your system more secure.
Comments
By Anonymous Coward (216.27.182.22) on
http://www.pizzashack.org/rssh/index.shtml
Last update was Dec. 30, 2004.
By 9 (209.73.236.253) on
If you generally trust your users in the first place, scponly may be good enough (with proper permissions on directories). If you're providing file-transfer service to untrusted or anonymous users, you really should find something made with that purpose in-mind, as it is sure to keep your system more secure.
This comment, however true it may be, isn't very helpful. Someone is clearly looking for a secure alternative to FTP which wouldn't allow users to browse the entire file system. Why bother responding just to say, "You're obviously ignorant as to how this should work. I would tell you what to do, but don't feel like it."?
Comments
By 9 (66.237.197.226) on
By Anonymous Coward (82.69.212.38) on
Comments
By Anonymous Coward? (68.94.11.184) simongales@hotmail.com on