OpenSSH 4.0 & Portable OpenSSH 4.0p1 Released

UnderScan writes "As seen on openssh-unix-announce: '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.' See the changelog or the freshmeat.net changes summary for more details."

Comments

Donations

[Noksagt]

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.

You can also do what I plan to do: donate surplus hardware to OpenBSD, which runs the project. OpenBSD accepts other donations too:checks, credit cards, paypal.

Re:FreeBSD

[robbkidd]

What makes you think that there should be a port available on Freshports.org at the same time as the release of OpenSSH?

The new hacker/cracker challenge: zero day ports!

Re:Grrr....

[pizza_milkshake]

you're right, the developers should slow down to a rate that's comfortable for you... when would you like v5?

MD5 Incorrect

[Nimrangul]

Damien Miller: I botched the MD5 sum for the portable tarball in the release announcement. The correct one is:

MD5 (openssh-4.0p1.tar.gz) = 7b36f28fc16e1b7f4ba3c1dca191ac92

Source: http://www.undeadly.org/cgi?action=article&sid=200 50309172736

Re:MD5 Incorrect

[CableModemSniper]

Arrrrg! No! How do I trust this MD5 now? OpenSSH 4 has been compromised! Arrrrg! *Runs around in tin foil hat banging into walls*

Any news on chroot support?

[RT Alec]

One feature I have been waiting for is the ability to chroot my users when they log in, even if just for file transfers. This would ensure that users would not be able to wander the entire directory tree of the server. I have had some success (on FreeBSD) with creating single jail for all client logins, and then applying some clever directory permissions for the higher directories (usualy o-x for directories). There was a commercial version of SSH that had a chroot feature, but I would prefer to stick with openssh. IMHO, this is the one area that FTP outdoes SFTP (but not enough for me to dumb my security down and allow FTP!!).

Any other ideas?

Re:Any news on chroot support?

[agent dero]

my personal policy is not to let anybody on my machines that I don't know personally.

that way, when somebody messes something up or does something nasty, i'll know about them and promptly punch them in the face

%cat /etc/motd
FreeBSD 5.3-STABLE (BRIDGING) #3: Thu Feb 10 11:13:42 UTC 2005

Welcome to FreeBSD!

FreeBSD interactive server, do something nasty, and I will punch you in the face.

Re:Any news on chroot support?

[GoRK]

As I'm sure you know, chroot is not necessarily a simple feature due to the fact that if you need a full environment to use commands (which aside from forwarding ports is the only thing ssh actually lets you do -- even sftp has a "server" command that gets run by the sftp client), so you can't just automatically have sshd know what library files and binaries are necessary for a user to have certain access.

What you ought to do instead is set up your users with ssh using rssh as a shell. rssh can give you a restricted environment without necessarily having to chroot (if you trust rssh, anyway), but if you really want to deal with the setup and maintenance overhead of a real chroot environment for a shell, rssh can do that too -- every user can have their own jail or they can share a jail and you can use permissions to restrict them.

I can't understand if this is your intent or you'd like sshd to run in a jail -- if that is the case, it's definately not a simple 'switch it on' feature either. The same rules apply except that your user accounts will be futher restricted to the root that sshd is running in. For the ultra paranoid you could jail sshd in /home, say, and then jail each user account in /home/user/ with only access to sash, busybox or some similar staticlly compiled multi-command utility.

Remember, use hardlinks on all your bins and libs in your chroot jails otherwise you'll forget to update the files!

Re:Any news on chroot support?

[archen]

I use rssh on all of my servers, and it works quite well. Now days with rsync support I am one happy camper. BUT:

No support for FreeBSD 4x (no wordexp() function)
FreeBSD 5.2.x Functional, but due to a typo in wordexp.h you have to correct a line in the system header file to get it to compile - works fine after that.

Also the guy who came up with rssh has pretty much abandoned the project for his own reasons. One of the gentoo people discovered a vulerability which was fixed and eventually made its way back to the ports tree, but I'm not sure how well maintained such a port will be concerning security - although it's supposed to be pretty good code and considered feature complete.

I think I speak for everyone when I request:

[mscnln]

Tab completion in sftp!

I don't use sftp nearly as much as I would if I could actually navigate and download files with any efficiency instead of copying and pasting...

This is 2005, come on.

Not front page material?

[MetalliQaZ]

A new release of Gnome got the front page, but a new release of OpenSSH doesn't? Someone's priorities are out of wack.

-d

Re:Not front page material?

[Anonymous Coward]

I was thinking the same thing. OpenSSH is one of the most widely used open source applications but on Slashdot its a minor footnote when a major release is annouced. Hmm...could it be because its a BSD related project and not Linux? It wouldnt be the first and im sure it wont be the last time.

Re:Major/Minor oddity

[Tuck]

It got a whole-digit bump because we ran out of minor digits and don't want double-digit minor version numbers (or hex :-).

configure and cross-compile

[statemachine]

Does ./configure handle cross-compile situations correctly yet?

For example, I want to build OpenSSH on an i386 Linux for an embedded MIPS Linux. Configure will detect that it is cross-compiling, but will still insist on performing its compile-and-run tests, either by erroring when it tries to run the MIPS binary on i386, or by saying it won't proceed any further because I'm cross-compiling which means it can't do its ... test.

I had to tediously hand-edit the configure script to shut off those errors (I lost count of how many instances) -- after which everything worked fine. But with each new release, I will need to edit that script again, which I don't enjoy.