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

FreeBSD

[numbski]

Hasn't hit ports. :\

Re:FreeBSD

[Homology]

Hasn't hit ports. :\

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

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:FreeBSD

[ignorant_newbie]

> The new hacker/cracker challenge: zero day ports!

well, given where most of the good ports come from these days, the quickest route is to just install OpenBSD

Re:FreeBSD

[Anonymous Coward]

Using something the day it's released on a non native system? Yeah baby, let me roll this out on all my mission criticle production servers today!

Re:FreeBSD

[setagllib]

That's the point of the portable copies: and they do get tested. If there's one thing we can trust OpenBSD for it's releasing solid software, even if not always in the kernel (at least from what I've heard).

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.

Grrr....

[stevew]

I just updated to something like 3.95pl1 last weekend.

Now I get to do it again....

There sure is a lot to timing isn't there.

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*

Re:MD5 Incorrect

[Tuck]

The online release notes have the corrected md5sums.

FWIW I verified that the uploaded files are in fact correct.

Major/Minor oddity

[dpilot]

On Freshmeat, 3.6.1p2, 3.7.1, and 3.7.1p2 are all listed as Major Security Fixes, and 3.9p1 is listed as Major Feature Enhancements. They are all point level or even less, patch level releases.

Does anyone else find it a bit odd that 4.0p1 is listed as Minor Feature Enhancements, yet it gets a whole-digit version bump?

Re:Major/Minor oddity

[superpulpsicle]

To my understanding Openssh is still the same 2.0 protocol. Not like a new 4.0 protocol. Correct me if I am mistaken....

Re:Major/Minor oddity

[macdaddy]

Not mistaken, you're correct.

Re:Major/Minor oddity

[ArbitraryConstant]

"Does anyone else find it a bit odd that 4.0p1 is listed as Minor Feature Enhancements, yet it gets a whole-digit version bump?"

The last release was 3.9. They simply rolled over to a new major number. Also, I think it's justified. Connection multiplexing was introduced in 3.9, but now it's had the major bugs fixed and so might be considered "stable". It's a big feature.

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 :-).

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?

[Anonymous Coward]

There is a SourceForge project at http://chrootssh.sourceforge.net/index.php that provides chroot patches for all OpenSSH versions. I believe the official developer's opinion on this is that it doesn't belong in OpenSSH which is why, well, it still isn't there.

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?

[bluGill]

Sure, if you have a good punch. This is slashdot we are talking about though. Most of us are letting others on our machine because we will get punched outwise. Threats to punch someone who does something nasty will be met with laughs at best.

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.

Re:Any news on chroot support?

[RT Alec]

I am aware that there are difficulties in implementing this, although I must admit I do not fully understand what they are (I am not a system level programmer). I have several web servers, that host up to 100 web sites each. I insist that my clients use SFTP to maintain their site-- I do not support (or even have installed) FTP. While an unpopular choice a few years ago when I set this up, now that DreamWeaver, BBEdit, and many other WSIWYG editors support SFTP directly this is an easy rule to impose.

One of the nice features of most FTP servers is chroot-ing a login to a restricted directory. That way, one client cannot (by mistake or on purpose) wander "up" the directory tree. "What is the /etc directory?" is not a question I want to answer! As I mentioned in my earlier post, I have achieved some degree of satisfaction by clever directory permissions, that at least prevent innocent mistakes. However, if a seasoned Unix hack logs in (as they might if one is hired by a client to edit their site), they could probably poke around a little. All logins are in a common FreeBSD jail, in which the only server running is sshd. Nobody can see the apache directory, for example, or the main server partitions. Still, I don't even want my clients being able to guess who any other of my clients are, and somehow derive a directory path that at least lets them see other user's files, or anything else for that matter. They never, ever, need shell access. SSH is used only for file transfer, so chroot-ing should not need to replice /bin, /etc, /usr/local/bin, /lib, etc., other than whatever the sftp-server subsystem needs. I know greater minds than mine have looked into this, so I was just wondering if anyone else has studied this problem and has a (more) elegant solution.

Re:Any news on chroot support?

[GoRK]

I think you may be confusing an application presenting limited access to a user vs the application itself actually having limited access.

Chroot can be used to do either; however the implemetations are wildly different. The former can often be accomplished by an application forking a child process to handle a connection and calling a chroot before accepting the connection. The user will have a subset of the system files to access, but an exploit launched against the server process itself could give an attacker more widespread access.

The second involves running the server process itslef inside of a chroot jail such that the actual application (say an ftp server) cannot access anything but files necessary to do its job, even running as superuser, even if attacked with an exploit.

It sounds to me like you actually want to do the former (or both), but are actually doing only the latter.

You should create a chroot jail containing the sshd, sftp, and rssh binaries, everything necessary to run those binaries, and everything necessary to authenticate your users (and only your users -- leave out root and all those funky system accounts!). This jail should also contain the users data directories.

Secondly, you want to set up sftp (when called by sshd and restricted to sftp-only by rssh) to do a chroot onto a users home directory whenever a connection by that user comes in. Alternatively, you can set up sshd to run the called command in a chroot. Patches for openssh or sftp are both available.

Re:Any news on chroot support?

[Anonymous Coward]

Chech out http://monkey.org/~jose/software/stsh/

Re:Any news on chroot support?

[Anonymous Coward]

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

And if somebody trojans the binaries in the jail, they've also trojaned the parent host. Is that really a good idea?

Re:Any news on chroot support?

[GoRK]

It's not the best idea, but it's common practice. It probably helps more than it hurts. When you've got thousands of chroot jails set up maintaining them without hardlinks is not only tedious, it takes a non-trivial amount of disk space -- especially if you need users to have access to a decent set of commands and libraries.

If you can gain access to trojan the binaries in a jail, hardlinks or not, you will more than likely have enough access to break out of the jail anyway using many other methods (ptrace, kernel memory attack, mknod, etc.)

Of course there are various techniques and security patches and whatnot that can limit even what a superuser can do in a chroot jail that can eliminate both problems described, but if you are getting into this level of security, either you don't need to discuss it because you already know how to do it, or the discussion probably belongs somewhere other than slashdot.

Re:Any news on chroot support?

[Lord Kano]

Have you ever thought about stunnel?

Sure it's not as widely available as SSH, but you could wrap FTP in a SSL tunnel. I've been using stunnel for my VNC connection.

You then get the ability to trap the user session in a chroot jail.

LK

Re:Any news on chroot support?

[llin]

An application I've used which does what you want is called scponly.

Features include chrooting to home directory, and full sftp, unison, and optional rsync compatibility.

Re:Any news on chroot support?

[temponaut]

What's wrong with using FTPS (ftp over ssl) for encrypted FTP sessions?

Re:Any news on chroot support?

[Internet_Communist]

I believe if you use SSH with pam you might be able to use pam to do chrooting, but I've never actually tried it.

Re:Any news on chroot support?

[Anonymous Coward]

For scp/sftp file transfers, I use scponly; it's a restricted shell with optional chroot.

Re:Any news on chroot support?

[TheCabal]

I've heard that the OpenSSH guys don't want to do this for various reasons. Nonetheless, there is a chroot patch you can apply (http://chrootssh.sourceforge.net) that works pretty well. There are also pointers on how to set up the jail so it will actually work- finding library dependencies and all that.

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.

Re:I think I speak for everyone when I request:

[Anonymous Coward]

tab completion? how about recursive get and put?

Re:I think I speak for everyone when I request:

[Anonymous Coward]

Tab completion in an FTP client? Why don't you do something else retarded, like make your file system drivers resolve globs?

UNIX is about having lots of small programs that band together to do a job right. Mixing a shell into an ftp client is a nono.

Re:I think I speak for everyone when I request:

[mscnln]

Used 'ftp' lately?

Comes with tab completion and all, and was only released 07/31/00, so I guess the authors of netkit must be retarted too.

Re:I think I speak for everyone when I request:

[Anonymous Coward]

You're 100% certain that ftpd doesn't use the user's shell to do all that? Look again, that's what goes on (at least, that's what goes on with the ftpd that comes with FreeBSD. It's entirely possible that someone went through all the trouble of writing an ftp server, and then wrote a shell, just because they wanted to).

Division of labor, especially on UNIX style systems, is very easy to do and very powerful, which is the whole point.

Re:I think I speak for everyone when I request:

[setagllib]

Does the FTP server even do it? I always thought (but I haven't read the source so take it with a grain of salt) it just silently fetched an 'ls' and then used that. It can often take a second or two if you're on a slow server. And if it's the part of the command that would be local (yeah, it's intelligent - which is NOT possible in the shell's method) it just checks the local list. Neither of these need much code at all: it already has the code to get an ls from the server (and this is within the protocol standard) and the code to fetch a list of local files is a few lines at most, including error checking if your working directory disappears magically.

Re:I think I speak for everyone when I request:

[Snaapy]

Tab completion in sftp!
This is 2005, come on.

Indeed it's the millennium of flying cars and laser pistols! And I have also heard rumours about this GUI thing... they don't use keyboards anymore to communicate with machines!

Re:I think I speak for everyone when I request:

[DashEvil]

An extra key binding is available to ftp to provide context sensitive
command and filename completion (including remote file completion). To
use this, bind a key to the editline(3) command ftp-complete. By
default, this is bound to the TAB key.


This is FROM THE MAN PAGE!

Re:I think I speak for everyone when I request:

[setagllib]

And... what's your point? Relevant to what I said, that is.

Re:I think I speak for everyone when I request:

[DashEvil]

The point is that this behavior is clearly documented in the man page. A simple man ftp, /TAB cleared it up.

Not that this was directly for you, per say, but this whole discussion is retarded so I was hoping to curb further misconceptions by posting where I thought dumbass would reply. Just flowing with the conversation.

Re:I think I speak for everyone when I request:

[setagllib]

Oh. Sensible. Yeah, I guess I should have read the manpage instead of speculating on observation, but admittedly it's more fun this way.

Keep up the good work!

Re:I think I speak for everyone when I request:

[Anonymous Coward]

What's your problem with -r?

Works in scp (which I think should be deprecated) as well as rsync (same thing but better).

Re:I think I speak for everyone when I request:

[Anonymous Coward]

Try lftp then. Example# lftp sftp://foo@bar.com

Has tab completion and command history!

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:Not front page material?

[rs79]

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

Gnome doesn't make the internet work, SSH does.

That is it's a significant tool for operations. Gnome is the moral equivalent of windows (for unix).

If there was no gnome, life would move on. If there was no SSH the net would break very quickly.

gname is a wonderfull thing, don't get me wrong. But ssh is important.

Re:Not front page material?

[duffbeer703]

At least the release of a new iPod iSock protective film isn't on the front page.

Fixed sized buffers?

[Anonymous Coward]

ISTR a project to make ssh work better on high-speed links by making certain statically-sized buffers larger / dynamically-sized Right now, my ssh is way slower than netcat. Any hope of 4.0 incorporating this project?

Re:Fixed sized buffers?

[Tuck]

That would be hpn-ssh. No, it's not in 4.0. Will it be included in future releases? Maybe, it needs to be looked at more closely.

Any idea on these login pauses?

[bconway]

I have OpenSSH 4.0p1 running on a variety of OSes, all built against OpenSSL 0.9.7e. They're all built with a standard ./configure and no other options, and just X11 forwarding in the ssh_config file. Whenever I connect to a system followed by another system, regardless of the SSH server version running, after I put in a password, it pauses for a full 5 seconds every time with the following (from ssh -vv):

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

This doesn't happen on any system that I'm logged in to locally and initiate a connection, but if I jump from one machine to another with X11 forwarding turned on, the second machine is always doing this 5-second pause. This is most easily reproducible if I SSH to localhost twice in a row (one connection within another).

Re:Any idea on these login pauses?

[lachlan76]

It probably pauses on non-localhost connections to make it harder to try to brute-force.

Re:Any idea on these login pauses?

[setagllib]

Is UseDNS Off? It might be trying to find a reverse-DNS for its client and be running in to trouble. I think there's some other option related to this but I haven't had that problem in too long.

Does turning off X11 forwarding 'fix' the problem or does it still happen? I couldn't work that out just from your post.

Re:Any idea on these login pauses?

[bconway]

UseDNS is on (default), and all forward and reverse entries are resolving correctly on the DNS server. Sorry, I meant to mention the problem "disappears" when turning off X11 forwarding in the 4.0p1 client, as well as when reverting to 3.9p1 with X11 forwarding turned on. Thanks guys.

Re:Any idea on these login pauses?

[Anonymous Coward]

Ugh.. UseDNS... I wish they had that commented out in the default config file. It took me forever to figure out why ssh would take about a minute or more to connect.

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.

Re:configure and cross-compile

[Tuck]

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

It handles the ones that we know about (ie the ones that have been reported, see bug #321)

Re:configure and cross-compile

[statemachine]

Sorry, it still errors out. However, it does get farther this time.

checking if openpty correctly handles controlling tty... configure: error: cannot run test program while cross compiling

Re:configure and cross-compile

[Tuck]

Well, if you want it fixed then please open a bug at http://bugzilla.mindrot.org, and better yet, attach your patch.

Re:configure and cross-compile

[statemachine]

Well, if you want it fixed then please open a bug at http://bugzilla.mindrot.org, and better yet, attach your patch.

Someone already did reference this issue in the bug you referenced #321 yet the bug was labelled as "Resolved and Fixed" anyway. A simple test would have caught this issue.

As for submitting a patch: patches took 4 years to be accepted, and then 6 months for a release after that. What makes you think I have the time to deal with that?

Re:configure and cross-compile

[Tuck]

Someone already did reference this issue in the bug you referenced #321 [mindrot.org] yet the bug was labelled as "Resolved and Fixed" anyway. A simple test would have caught this issue.

What makes you think we have a cross-compile environment to test it on?

The reporters reported it worked for them (or that they had tested the wrong patch), so as far as I knew it worked ok.

As for submitting a patch: patches took 4 years to be accepted, and then 6 months for a release after that. What makes you think I have the time to deal with that?

So you have time to "to tediously hand-edit the configure script" every release and whine about it on /. but not submit a patch of your work so that you won't have to do it again?

Re:configure and cross-compile

[statemachine]

What makes you think we have a cross-compile environment to test it on?

Simple. Just tell it to cross-compile. It's nothing more than an option. If it wants to perform those checks, then you've failed.

As for submitting a patch: patches took 4 years to be accepted, and then 6 months for a release after that. What makes you think I have the time to deal with that?

So you have time to "to tediously hand-edit the configure script" every release and whine about it on /. but not submit a patch of your work so that you won't have to do it again?

No. I don't have time to wait 4 years and 6 months for you to get your act together, stop complaining on slashdot, apply patches, and for once, show that your parents didn't throw away their money on your CS degree by using some common sense and performing a simple test to make sure a bug has gone away before closing it.

Was that harsh? Oh I'm sorry. Maybe it was your smart-assed remark about whining. Pot. Kettle. Black.

Re:configure and cross-compile

[statemachine]

And to follow up on my earlier comment, your revisionist history is easily disproven:

The reporters reported it worked for them (or that they had tested the wrong patch), so as far as I knew it worked ok.

Wrong! If you had thoroughly read through the comments you would have seen that the same person who reported the openpty failure replied to you to say that the patches didn't work.

------- Additional Comment #12 From *** 2004-09-07 21:21 [reply] ------- Daren: I ran autoconf after modifying configure.ac, of course. But I only applied the latest patch from here (...which handles the zlib test) ...

It's a huge leap from that comment to Resolved and Fixed. I will continue to knock you down until you cut your attitude. I don't know where it came from, as I started out polite, but you will not go very far with that.

Re:configure and cross-compile

[Tuck]

Simple. Just tell it to cross-compile.

How? "./configure --target=foo" and "./configure --host=foo --target=bar" do not seem to enable cross compiling (at least without a cross compiler and build environment for the target?)

apply patches

What patches? None of the patches addressed the issue you brought up. I asked you to provide one and you refused.

If you had thoroughly read through the comments you would have seen that the same person who reported the openpty failure replied to you to say that the patches didn't work.

OK, fair enough. It looks like I misinterpretted what the poster said.

No. I don't have time to wait 4 years and 6 months for you

It wasn't that long, but yes, it would have been better to get to it sooner. Non-critical things that we can't test, or can't test easily tend to get delayed (in part, because of the reason above: a misunderstanding about whether or not it was actually fixed).

If you're genuinely interested in getting it fixed, how about a truce? If you provide a tested patch to configure.ac that fixes the openpty thing then I'll apply it. After that we can go back to flaming each other :-)

Your wish has been granted...

[Anonymous Coward]

It exists: http://www.caliban.org/bash/#completion

Completion for sftp is standard in recent bash packages in Debian. Can't speak for other distros.

Or, you can browse over sftp graphically using Nautilus.

Cygwin!

[ManyLostPackets]

I expect it will compile O.K. Hope it works on 2003 server. Never gould get 3.8.1p1-1 to work right on 2003 server :-/

I know I speak for the developers when I ask:

[dmiller]

where is your patch?

Re:I know I speak for the developers when I ask:

[Nimrangul]

The funny thing is, Damien Miller is one of the guys that do OpenSSH, infact, he's the one that wrote the sftp client.

So, I guess rather than being a Troll it was Insightful. One of these days someone needs to set up a replacement for Slashdot, with a real moderation system.