Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Upgrades Announcements Security News

OpenSSH 4.2 released 183

Posted by Hemos from the becoming-more-secure dept.
BSDForums writes "OpenSSH 4.2 has been released. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Changes since OpenSSH 4.1 include security bug fixes relating to GatewayPorts, and GSSAPI, which eliminates the risk of credentials being inadvertently exposed to an untrusted user/host. A new compression method, proactive changes for signed vs. unsigned integer bugs, and many additional bugfixes and improvements highlight this release."
This discussion has been archived. No new comments can be posted.

OpenSSH 4.2 released More

OpenSSH 4.2 released

Comments Filter:

  • The new compression method is pretty fantastic. (Score:4, Informative)

    by CyricZ ( 887944 ) on Monday September 05, 2005 @12:04PM (#13483532)
    I've found that it offers a good 10% to 15% decrease in data size compared to the previous method.

  • Increased default key size. (Score:5, Interesting)

    by CyricZ ( 887944 ) on Monday September 05, 2005 @12:07PM (#13483546)
    From the changelog:
    "- Increase the default size of new RSA/DSA keys generated by ssh-keygen from 1024 to 2048 bits."

    It's good to see that the default size of the keys had been increased. It's only a matter of time before modern systems (or clusters of modern systems) are capable of defeating even 1024 bit keys routinely. This proactive doubling of the default keysize is sure to increase the overall security for OpenSSH users for some time.

    • Re:Increased default key size. (Score:1, Interesting)

      by Anonymous Coward
      The increase of the key size might not be as useful as you think. The best way to get through these encryptions has been, and will continue to be non-brute force methods including social engineering or other methods of obtaining the key. The increase in computing systems does not actually get us much closer to cracking it considering by best methods availible it would still take my computer more then 10^50 years (if memory servers me right) to crack a 1024 bit key. There would have to be a very significa
      • Changes are your computer is hardly the bastion of computing systems. But it's naive to believe that there will not be major increases in computing capabilities, even within the next few years. What today seems impossible with regards to computing will be sitting on your desk. And a couple of years later it will be in your closet collecting dust, replaced by the next computing innovation. Soon enough, a child will have a toy portable gaming system that is powerful enough to crack 1024-bit keys within second

    • Re:Increased default key size. (Score:5, Informative)

      by Kjella ( 173770 ) on Monday September 05, 2005 @01:43PM (#13484093) Homepage
      1024 bit asymmetric is roughly as hard to crack as 128 bit symmetric = ~10^40. It's *still* on the order of "If we take all the power of the sun to power PIVs we can do it" level. Noting that I'm talking about instructions/watt here (energy efficiency), not instructions/second (speed). Obviously you get a lot better dedicated chips than that, but even so... unless you're Osama, you needn't worry.

      Moving to 2048 bits is the kind of "Even if you take the power of the sun and the whole galaxy too, and run it on hyperefficient nanowatt CPUs that can do one key/clock cycle, you're still going to run out of energy" move. Unless you happen to know a better algorithm than brute force, in which case 2048 bits may be just as screwed as 1024 bits...

      Kjella

      • Mod this nonsense down, its all wrong. (Score:5, Informative)

        by Some Random Username ( 873177 ) on Monday September 05, 2005 @06:55PM (#13485819) Journal
        1024 bit asymmetric keys for ciphers that rely on the assumed difficulty of factorization are about as difficult to break as 80 bit symmetric keys. And there is no reason to think it will stay that way, people continue to work on finding newer, more effectient methods of factorization.

        Everyone knows a better algorithm than brute force: General Number Field Sieve, Number Field Sieve, Quadratic Sieve, and its likely new methods will be found. You don't brute force assymetric keys, brute forcing 1024 bit keys asymmetric keys would take just as long as brute forcing 1024 bit symmetric keys, that is to say it is not possible. Brute force means simply trying every possibility, the algorithm doesn't matter in that case. Trying 2^1024 possibilities is trying 2^1024 possibilities, regardless of how the key was generated or what its used for.

        And finally, 1024 bit keys could certainly be broken without all the power of the sun, you are talking out of your ass, plain and simple. In fact, Bruce Schneier always says its likely that a billion dollars would be enough to put together the hardware required to break a 1024 bit key.
    • As far as I know, the computational overhead of the higher-bit keys isn't that significant, so it's probably not doing any actual harm. It'll slow down initial key negotiation and session setup, but it shouldn't affect traffic overhead, because that's encrypted with a symmetric cipher that was negotiated with the (very slow) public-key protocol. You'd probably only notice the overhead if you were running a server with many, many session setups. If it impacted you, generating a smaller key would be trivia
      • As far as I know, the computational overhead of the higher-bit keys isn't that significant, so it's probably not doing any actual harm. It'll slow down initial key negotiation and session setup, but it shouldn't affect traffic overhead, because that's encrypted with a symmetric cipher that was negotiated with the (very slow) public-key protocol.

        The generation of server keys will take _much_ longer time on some architectures, and this was actually one of the arguments of not increasing the key length ea

  • Longer passwords on UnixWare? (Score:4, Interesting)

    by CyricZ ( 887944 ) on Monday September 05, 2005 @12:11PM (#13483562)
    From the changelog:
    - Portable OpenSSH: Added support for long passwords (> 8-char) on UnixWare 7.

    I'm surprised that it has taken them this long to add support for long passwords to UnixWare 7. UnixWare 7 is a modern UNIX by all means, considering it is still being updated frequently. Can anybody shed some light as to why it took so long for this fairly rudimentary support to be added to the portable version of OpenSSH?

  • A new version of my favorite Linux tool! How great! I could not live a second without being able to scp file.tar.bz2 user@hostname:/path, or without being able to open files remotely using KDEs fish: fish://username:passord@host.box/some/path works in all the KDE file dialog boxes thanks to SSH. Nor would I be able to login to the box where I have my irssi IRC client running, connected to numerous IRC servers and a BitlBee gateway for MSN/ICQ/AIM/Google Talk. And then there is sftp.. SSH is something comple

    • Re:Please excuse my obvious ass-kissing (Score:5, Informative)

      by ScriptedReplay ( 908196 ) on Monday September 05, 2005 @12:30PM (#13483657)
      Hint: use aliases in .ssh/config to make your life easier. Something like:

      Host alias1
            Hostname hostname
            User username
            [add extra options like authentication method, X11 forwarding, agent forwarding, private key to use and so on]

      then you do scp file.tar.bz2 alias1/path or fish://alias1/some/path (and get a password prompt). Less typing - and works with bash completion too.

      • Re:Please excuse my obvious ass-kissing (Score:5, Insightful)

        by Kynde ( 324134 ) <kynde@[ ].fi ['iki' in gap]> on Monday September 05, 2005 @01:06PM (#13483861)
        Bloody hell. I've been using openssh ever since it came out and quite a while the old Tatu Ylönen's ssh before that and type all those lengthy user@hostname.domainname.whatever: prefixes day in day out without knowing about those aliases.

        The fact is that in OSS world one should, atleast once a month raise fingers from the keyboard and stop to think "What am I missing from my daily environment? Are stupid, repetetive or borings things that I do all too frequently?". The odds are that I could easily fix most of them swiftly and the ones that might require moderate amounts of work to happen it's quite likely that someone hast stumbled on those very same issues before me and fixed them. (and experience in *nix world teaches me that frequently the fix is quite brilliant)
        • Funnily enough, in the responses to the upcoming BSD certifiction, some of the respondents said that skilled/expert administrators should not have to look in the man pages. But if this is the attitude, my guess is that they don't read man pages very often, and thus miss all the new fun stuff :-)
    • The coolest thing about ssh is the versatility you get out of one open port. You can login, cp, and ftp securely, with only one port open; additionally, you can tunnel any other port you want. ssh is great for securing vnc.

      It's not even hard to find a client. Modern Linux and BSD systems mostly have it, and if you're using Windows, you can download PuTTY and use it without even having to install it and make a mess. Great if you're a guest on somebody else's system.

      I use ssh, sftp, scp, and vnc over ssh dail
    • A new version of my favorite Linux tool!

      Hey the SSH server and client can work on Windows too! Install Cygwin to find out. I've been using Cygwin/SSH for about 6 months now and I love it. SSH into the machine, remote (secure) VNC, scp/sftp it's all there and was pretty simple to setup.

      I love Cygwin more, because it gives me SSH, but without each other I wouldn't use either.

  • From Bill Gates... (Score:3, Funny)

    by Anonymous Coward on Monday September 05, 2005 @12:21PM (#13483618)
    I'll take that, thanks!

    Keep up the good work guys.
    • No problem, Bill. After all, open source software (especially that under the BSD license) is meant to be shared and used by all, basically however they see fit. That's the name of the game, Mr. Gates.

      • Re:It's our pleasure, Mr. Gates. (Score:5, Insightful)

        by ArbitraryConstant ( 763964 ) on Monday September 05, 2005 @12:43PM (#13483724) Homepage
        The BSD licensing has made it possible for commercial OSes to have an SSH implementation by default. That ubiquity is what killed telnet. By helping companies like Microsoft, Sun, and Apple, the OpenSSH project has helped everyone.
        • The BSD licensing has made it possible for commercial OSes to have an SSH implementation by default. That ubiquity is what killed telnet. By helping companies like Microsoft, Sun, and Apple, the OpenSSH project has helped everyone.

          Except that BSD liscensing allows compaines like Microsoft the pervert a standard protocol, so that it is no longer interoperable, nor "ubiquitous" ...perhaps not even secure.

          There is nothing the prevents Microsoft from distributing a GPL'ed product except their own internal
          • " Except that BSD liscensing allows compaines like Microsoft the pervert a standard protocol, so that it is no longer interoperable, nor "ubiquitous" ...perhaps not even secure. "

            I was aware of that argument before, but putting it in bold convinced me.

            "The biggest difference is, of course, that they would have to publish any changes. To me, it seems obvious the you should WANT them publish any changes to SSH."

            That's why these arguments never go anywhere. You don't just think I have different priorities, you
            • To replace telnet, they had to throw something out there that anyone could use and customize in any capacity (including extensions).

              GPL allows all of the above :)

              Whether or not you agree, and whether or not they are right, some of the companies out there want the freedom to customize code without releasing the changes.

              And I want a Ferrari... doesn't mean you have to give it to me, especially for free.

              Microsoft's breaking of Kerberos is just a minimal example of what can go wrong here.

              It's not
              • "GPL allows all of the above :)"

                Not necessarily. For example, they might recieve bug reports under NDA (not hard to imagine for security issues), and a source patch would violate that. They might also wish to license commercial code. Even if they don't want to do that, it makes people nervous when they have to rule out the ability to do that from the get-go.

                "And I want a Ferrari... doesn't mean you have to give it to me, especially for free."

                That doesn't make any sense. The maintainers give it away under th
  • Sigh. Back to my commercial (vandyke vshelld) implementation....

  • Slowing down dictionary attacks (Score:5, Informative)

    by RAMMS+EIN ( 578166 ) on Monday September 05, 2005 @12:58PM (#13483804) Homepage Journal
    I had an instance of an attacker running a dictionary attack on my sshd the other day, and I was surprised by how many logins he could test per second (he was using multiple connections). I asked on #openbsd about ways of slowing down such attacks. This is the advice I got:

    1. Run sshd on a different port. The scripts won't find you there. I don't like this option, because it requires me to specify the alternative port every time i ssh, scp, rsync, or svn. It's still about the easiest and most effective method.

    2. Limit the connection rate to the port you're running sshd on. In many scenarios, it won't hurt you if you can't connect to it more than once in 5 seconds, but this will make a dictionary attack from a single machine very tedious. In OpenBSD 3.7, you can use pf with max-src-conn-rate.

    3. Use a script like DenyHosts [sourceforge.net] to monitor your authentication log, and add suspicious hosts to a block list (either temporarily or permanently). This looks like a very nice solution to me.

    4. I got this one from my girlfriend: disable password authentication and use key-based authentication instead. This is my prefered solution, except that I have to solve some problems with public key authentication not working from some of the machines I use.

    I hope this post is helpful to some of you. If you have any other methods that you would like to mention, I'd be glad to hear.
    • I got this one from my girlfriend: disable password authentication and use key-based authentication instead. This is my prefered solution, except that I have to solve some problems with public key authentication not working from some of the machines I use.

      Your girlfriend rocks. I always disable password authentication on a new server before I enable sshd for the first time. I'm pretty certain I could safely give my root password out on IRC without much risk, although prudence says I'm not completely int

      • ``Your girlfriend rocks.''

        Yes, totally. I feel the luckiest guy in the world for having a girlfriend who's a hacker, too.

        ``What sort of problems do you have with public key authentication?''

        From some machines, it just doesn't seem to use it. If I run ssh with -vv, it gives some messages about "we did not send a packet", then tries password auth instead. I don't have access to such a machine at the moment, otherwise I would be more specific.
        • I've ran into that atleast once before, but even additionally I'd never want to entirely disable password auth because then what if something happens to your privkey? Think katrina-sized destruction taking out your computer/entire house + the bank that housed your backup usb thumbdrive.
          Or even a more realistic scenario, sometimes you just want someone else to be able to log into your machine, be it a friend helping you or even an admin at a datacenter that doesnt want to have to dig out a keyboard+monitor t
    • ..on any given day.

      Box #1:
      grep "authentication failure"
      /var/log/messages|wc -l
      1362

      Box #2:
      grep "authentication failure" /var/log/messages|wc -l
      1520

      Thank you very much for more great SSH tips, I hope you do not mind I recycled them at http://en.linuxreviews.org/Ssh [linuxreviews.org] (it is a wiki, so I can easily remove your work if you mind, or you can do it..) :-)
      • ``I hope you do not mind I recycled them at http://en.linuxreviews.org/Ssh [linuxreviews.org]''

        I most certainly don't mind, otherwise I wouldn't have posted them here. You might want to change the wording, though. It sounds a bit strange the way it stands. If you do that, could you also change the link to my site to read "inglorion" instead of "Bob"; I prefer to use my handle rather than my name when it's not about personal communication.

        Anyway, thanks for putting it there!

    • Didn't know about DenyHosts, wrote something similar in sshd_failed_ips.pl [gazonk.org]. I didn't want a deamon or cron job when it's completely unnecessary, though me script does depend on TCP wrappers (any dist. not running that by default?)

    • Re:Slowing down dictionary attacks (Score:5, Informative)

      by jsveiga ( 465473 ) on Monday September 05, 2005 @01:47PM (#13484118)
      For your item "2", on Linux, you can use iptables "recent" module to limit the time between new connections from the same IP. That cut the dictionary attacks on my server on the first attempt:

      iptables -A INPUT -j ACCEPT -p tcp ! --syn -s 0/0 -d (outer ip/net)
      (you probably have this on your firewall already, allowing previously established connections)

      iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
      iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

      These two will only allow new connections from the same IP with 15s intervals between them. Add them to your iptables setup scripts (or replace them where you ACCEPT ssh, if that's the case).

      BR,

      Joao S Veiga

      • Re:Slowing down dictionary attacks (Score:4, Informative)

        by crawly ( 890914 ) on Monday September 05, 2005 @07:14PM (#13485905)

        I personally use the following to limit the number of connection attempts on my SSH server. The limit is set for only 3-connections in a minute, the first 2 exhaust the limit-burst, which then takes a minute to refill, effectively limiting the connection attempt rate to 1/minute.

        iptables -A INPUT -p tcp --dport ssh -m limit --limit 3/minute --limit-burst 2 -j ACCEPT

      • no no no no...

        If you want replies for previously accepted requests, do NOT use ! --syn
        Instead you should use the state table (which is what iptables was designed for).

        iptables -A INPUT -j ACCEPT -s 0/0 -d (outer ip/net) -m state --state ESTABLISHED,RELATED

        This is light years more efficient and secure. Also check out the iptstate [phildev.net] package so you can actually see what is in the magic state table.

        • Re:Slowing down dictionary attacks (Score:4, Informative)

          by accessdeniednsp ( 536678 ) <detoler AT gmail DOT com> on Monday September 05, 2005 @09:55PM (#13486673)
          Bah, I should clarify (sorry for not doing this first and sounding like an ass):

          By accepting only non-syn packets, you are opening yourself up to "ACK" attacks and old-school router-penetrating scans. Also, things like 'ippacket' can forge packets by setting arbitrary bits. If the 'ack' flag is set (or in the case of your rule, anything including RST, PSH, URG, and even the two reserved bits), then the packet will zing right through your rule.

          In this instance, the packet will pass thru the firewall, on to the destination host, which will then reply accordingly:

          * If the port is not open, it will reply with ICMP Port Unreach (Type 3, Code 3) signifying a host is alive.

          * If the port is open and these flags don't make sense to the host (invalid ACK window, or a FIN/ACK received without a FIN, or an ACK without a SYN, etc) then the host will reply with RST for that port. Implying the host is alive and that port is open.

          These responses will only lead to further probes, etc.

          For those who preach NAT until the cows come home, this will still happen because your firewall is still gonna un-NAT it and send it onward.

          NAT will offer no protection in this situation. (and please do remember that the entire intar-web-net doesn't run on NAT. NAT is not a magical security tool and offers very little advantage with a magnatude of disadvantages, especially for high-load servers)

          The state table checks, first, to see if the packet parameters match what has already transpired, session-wise. You can adjust the state timeouts to decrease or increase the time a session will remain 'open'. Now if the sessions are closed, it's removed from the state table period. No reply attacks, etc. The classic "Mitnick" attack will be avoided, too.

          The state has expectations of how the packets flowing through should be handled. If you put the "-m state" checks very early in your ruleset, watch it with "watch iptables -L INPUT -nv" and then watch with 'iptstate' in another window. You'll see the first packet of a session (the initial SYN) will go thru the ruleset and be placed in the state table (upon being accepted of course)

          EVERY packet from now until the final FIN/FIN-ACK will be matched against the state table in memory. The rule you are watching will only have ONE hit (for that session) even if you're transferring billions of bytes. The remainder is checked against the state table. It's very very cool and very very efficient and quite fast.

          Anyhoo.. just wanted to clarify *why* you shouldn't use the ! --syn parameter.
    • You can always use two SSH demons - one on port 22 that allows only connections with certificates, and one on port rand# that is limited to few retries per second, then a short ban after a few bad attempts, but otherwise normal logins.
    • 1. Run sshd on a different port. The scripts won't find you there. I don't like this option, because it requires me to specify the alternative port every time i ssh, scp, rsync, or svn. It's still about the easiest and most effective method.

      No need to specify the port every time on the comand line. Edit one of /etc/ssh_config, /etc/ssh/ssh_config or ~/.ssh/config, and add the configuration:
      Host *
      Port new_port

      That changes the default for every host, so you'll probably decide to define only for your ho

    • Simple hack: sleep(10) (Score:4, Interesting)

      by HermanAB ( 661181 ) on Monday September 05, 2005 @06:24PM (#13485673)
      I simply added a sleep(10); to the file auth-passwd.c and recompiled.

      int
      auth_password(Authctxt *authctxt, const char *password)
      {
              struct passwd * pw = authctxt->pw;
              int result, ok = authctxt->valid;
      #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
              static int expire_checked = 0;
      #endif /* Password authentication delay */
                      sleep(10);

      That slows all password authentication attempts down enormously. ./configure --prefix=/usr --sysconfdir=/etc/ssh
      make
      make install
      service sshd restart

      La Voila!

    • disable password authentication and use key-based authentication instead.

      That's one thing I do. Get it working and Just Do It(tm). It will let you sleep better at night.

      You may need to learn about ssh-agent. *sigh* ssh-agent rocks but it's another one of those things that's really easy to use once you know what's going on but before then you could be banging your head against it. The commands you need:

      ssh-add
      ssh -A

      I always chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys2. Make sure you have that right
  • I'd really like to see a -d option added to scp for copying symbolic links as symbolic links rather than the files to which the sym.links point. The cp command has it (see man cp for details).

    As a workaround you can wrap all the remote files in a temporary tar file to protect any sym.links etc, then scp the tar file and untar the tar file after the transfer but it would be much quicker and simpler if you could use scp to do this.

    • Re:-d option for scp? (Score:5, Informative)

      by Jerf ( 17166 ) on Monday September 05, 2005 @01:25PM (#13483987) Journal
      Leaning on tar is probably a better solution anyhow.

      I don't know your exact needs, but you can make this easy on yourself with a very short shell script, or even just an alias. Instead of using "scp", use "ssh" directly, something like:
      ssh [your login here] -C 'tar c $*' | tar x
      This runs "tar" on the remote server, $* is trying to convey the idea of passing all the params of the script/alias to the remote tar, and outputs to stdout. ssh redirects stdout across the network to its own stdout, which is then piped to local tar for extraction. -C compresses the stream, which is probably Good Enough, but under certain circumstances (CPU time vastly outweighs transfer time, think modem transfer here) it can be worthwhile to add bzip2 into the mix:
      ssh [your login] 'tar c $* | bzip2' | bunzip2 | tar x
      Tune the script to your needs, and the reverse script is pretty easy too; ssh will redirect its stdin across the network just as easily if you use it in a pipe.

      Note there is never a temporary file.

      I belabor how this works because it took me a while to fully grasp how cool it is that ssh makes the Unix pipe idea fully work across the network. Note you can set up pipes on the remote side in the ssh command if you escape it correctly (apostrophes will usually do, but shell escaping can get evil). scp is more "convenience script" than "fundamental tool".
      • Thanks, that's a good method for certain situations. However, having a -d option in scp, thus avoiding the need to use any external helper programs like tar and rsync, would be even more convenient in general. It would also have the benefit of making scp more similar to cp.

        The current workarounds for not having a -d option in scp tend to be problematic in various ways. For example, using tar becomes quite tedious when you want to copy only files in a particular directory, without recursively copying any su

    • Just set RSYNC_RSH=ssh (which you should have done anyway), and use 'rsync -a'. Copies not just symlinks but other attributes (rather like scp -p).

      Then add '-H' to preserve hard links. (Why isn't -H part of -a? Oh well.)

      • Then add '-H' to preserve hard links. (Why isn't -H part of -a? Oh well.)

        FYI (from the rsync man page):

        Note that -a does not preserve hardlinks, because finding multiply-linked files is expensive. You must separately specify -H.

  • GSSAPI (Score:5, Informative)

    by Craig Ringer ( 302899 ) on Monday September 05, 2005 @01:07PM (#13483869) Homepage Journal
    GSSAPI, in case anyone here is unfamiliar with the term, is pretty much Kerberos 5. It's a key-based network authentication and security scheme used on many UNIX networks, and in a bastardised form by Windows AD domains.

    It's also been on my "I really must implement that" list for waaaay too long. I find that more basic TLS-and-client-cert schemes do the job well enough most of the time.

    • Re:GSSAPI (Score:3, Interesting)

      by Just Some Guy ( 3352 )
      It's also been on my "I really must implement that" list for waaaay too long.

      I finally got around to setting up a KDC for my domains. It's nice to run "kinit" once, and then have full access to every machine I'm supposed to have full access to. Implementing Kerberos for one service is massive overkill. Implementing it for IMAP, SMTP, LDAP, etc. at the same time is bliss.

      The FreeBSD Handbook has a nice chapter [freebsd.org] on the subject. O'Reilly's "Kerberos: The Definitive Guide" is an excellent reference as we

    • I was on some conference (Samba eXPerience) and there was talk about AD Kerberos modification - I just remember one thing ("executive summary") - Microsoft's modifications to Kerberos are very very usefull and they are done in quite "clean" and "kerberos"-way and are necessary for using Kerberos in large scale networks (you could use Kerberos without them but you'll lack some functionality). Please no flame - of course that MS fucked up the way of implementing this (they should made the changes more open wa
    • Kerberos uses symmetric encryption. While unlike regular logins it doesn't sent password hashes across the network (just tokens encrypted with those hashes, that people who entered the right password can decrypt), it's still not secure in that it keeps credentials on the KDC. A compromise of the KDC therefore allows an attackers to pretend to be anyone they want.

      No modern authentication system should store secrets on the server, This is the reason we have PKI - we store the certificates on the server, and e

  • Proactive? (Score:2, Informative)

    by non-poster ( 529123 )
    proactive changes for signed vs. unsigned integer bugs
    Proactive changes for existing bugs? If the bugs are already there, then "proactive" is not the right word to use. See webster.com for "reactive".
    • Your lame sarcasm aside, these were changes to internal APIs to make signed vs unsigned errors more difficult for developers to make. E.g. we changed several internal functions to not accept or return signed values, thus eliminating the need for signed integers in many contexts. So yeah, it is proactive.
    • Tsk, you added an "existing" where there shouldn't have been one.

      There are various levels of paranoia you can aim for when performing a code sweep, depending on your gcc compiler options (-Wall -Wsign-compare -Wshadow). So we tend to do it in stages so that we can look at chunks of code rather than huge unparsable diffs that will let bugs sneak through (there were a number of integer warnings slowly fixed in earlier releases, but Damien went through and cleaned up all the remaining ones for this release).

      T
  • Is it recommended that I upgrade OpenSSH to 4.2 on my OpenBSD 3.7 system?

  • HPN-SSH, faster network performance (Score:2, Informative)

    by Anonymous Coward
    http://www.psc.edu/networking/projects/hpn-ssh/ [psc.edu]

    there is a patch called HPN-SSH that addresses some issues in ssh that users encounter if they have access to faster networks. SSH has some static flow control buffer values that limit network performance. The work at PSC by Chris Rapier and Michael Stevens is really nice, is proven to work and is gaining (some) broader acceptance.

    take it for a test run and if you like it, please encourage the OpenSSH folks to add it into the main trunk.
  • For end users, perhaps the best feature in this release is

    - Added ControlMaster=auto/autoask options to support opportunistic
    multiplexing (see the ssh_config(5) manpage for details).

    'Multiplexing' means running more than one session across the same ssh connection. So if you use CVS over ssh, or rsync over ssh or even just lots of remote commands, you don't have to start up a new connection for each one. The first ssh connection stays

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close