OpenSSH 5.4 Released

← Back to Stories (view on slashdot.org)

Posted by timothy on Wednesday March 10, 2010 @08:40AM from the but-it's-secret dept.

HipToday writes "As posted on the OpenBSD Journal, OpenSSH 5.4 has been released: 'Some highlights of this release are the disabling of protocol 1 by default, certificate authentication, a new "netcat mode," many changes on the sftp front (both client and server) and a collection of assorted bugfixes. The new release can already be found on a large number of mirrors and of course on www.openssh.com.'"

127 comments

open anus by Anonymous Coward · 2010-03-10 08:42 · Score: -1

First post
SFTP improvements by Ponga · 2010-03-10 08:51 · Score: 3, Informative

FTFA:

* Many improvements to the sftp(1) client, many of which were implemented by Carlos Silva through the Google Summer of Code program:...

... - Add recursive transfer support for get/put and on the commandline
(Alas!!)

Whole host of other improvements and bugfixes; give it read if SSH is pertinent to your environment....
1. Re:SFTP improvements by ig88b · 2010-03-10 08:59 · Score: 3, Funny
  
  I'm confused. You're excitedly sad about the sftp improvements?
2. Re:SFTP improvements by Anonymous Coward · 2010-03-10 09:11 · Score: 0
  
  Hell yeah - tab completion and recursive get/put are long overdue!
3. Re:SFTP improvements by moonbender · 2010-03-10 09:12 · Score: 1
  
  No, no, he meant to write "Atlas!!"
  Weirdo.
  
  --
  Switch back to Slashdot's D1 system.
4. Re:SFTP improvements by Torrance · 2010-03-10 09:35 · Score: 2, Funny
  
  - Implement tab-completion of commands, local and remote filenames
  Well thank frak.
5. Re:SFTP improvements by Hatta · 2010-03-10 09:53 · Score: 1
  
  Why sftp when you can scp? scp -r has worked fine for recursive transfers, and Bash has been tab completing remote filenames for a while now.
  
  --
  Give me Classic Slashdot or give me death!
6. Re:SFTP improvements by Sancho · 2010-03-10 09:57 · Score: 2, Interesting
  
  Doesn't that tab completion only work if your key is either not protected by a passphrase or cached by ssh-agent? Unfortunately, the policy where I work is that you cannot cache credentials like that, and they must be protected by a passphrase. The new features are actually good for me!
7. Re:SFTP improvements by Hatta · 2010-03-10 10:06 · Score: 1
  
  I usually have my credentials in ssh-agent, but I think I've been prompted for a password after hitting tab before.
  
  --
  Give me Classic Slashdot or give me death!
8. Re:SFTP improvements by Anonymous Coward · 2010-03-10 10:33 · Score: 0
  
  Why scp -r when rsync over ssh is vastly superior?
  I wish people would stop working on yet another file transfer mechanism, when they aren't aware of the strengths and weaknesses of the existing best practices. The next solution really ought to combine these features instead of continuing to polish one half while ignoring the other.
  (And by vastly superior, I mean all of rsync's many features: exclude/include patterns, conditional transfer by many different comparison methods, differential-based transfer optimization, extremely good performance even on trees of tiny files over high-latency networks, and many options for link trees and other incremental backup scenarios.)
9. Re:SFTP improvements by beav007 · 2010-03-10 13:17 · Score: 1
  
  Sounds great, but I think I'll wait for the Debian-approved version.
10. Re:SFTP improvements by Anonymous Coward · 2010-03-10 16:24 · Score: 0
  
  No, no, he meant to write "Atlas!!"
  Weirdo.
  I dunno, I think a book of maps is more bizarre than excitedly sad.
11. Re:SFTP improvements by klui · 2010-03-10 16:50 · Score: 1
  
  Tab-completion is not enabled if libedit is not installed. Cygwin's distribution doesn't enable it.
12. Re:SFTP improvements by mzs · 2010-03-10 18:26 · Score: 1
  
  This scripts has served me well over the years. There hasn't been a unix-alike where it has failed me in a very long time now. It also makes the target directory hierarchy for you automatically if needed.
  $ cat bin/stjput
  #!/bin/sh
  # e.g. copy all non-hidden files and dirs from your home dir using protocol 2
  # $ cd && stjput '-24 remuser@host' . *
  IFS='
  '
  case $# in
  [012])
  echo 'Usage: stjput sshopts remdir file|dir [file|dir ...]' >&2
  exit 2 ;;
  esac
  # some defaults, may not work with very old versions of ssh
  #sshopts='-24 -o PermitLocalCommand=no -qaxT '"$1"; shift
  sshopts='-qaxT '"$1"; shift
  remdir="$1"; shift
  # protect sh from stripping trailing whitespace, eg newline(s)
  case "$remdir" in
  '')
  # someone used '' instead of . for CWD!
  remdir=. ;;
  */) ;;
  *)
  # It does not matter to have the trailing / for a dir
  remdir="$remdir"/ ;;
  esac
  # need to prevent cd and mkdir thinking it is some option
  case "$remdir" in /* | .*) ;;
  *)
  remdir=./"$remdir" ;;
  esac
  foo() {
  n=$2
  }
  # lots of testing shows that this works on many shells,
  # don't use $() or "``" and make sure that closing tick is all by itsewlf on the
  # last line
  n=`cksum /dev/null`" && mkdir -p "$n" && cd "$n" && bunzip2 -c - | tar xvf -'\'''
13. Re:SFTP improvements by mzs · 2010-03-10 18:29 · Score: 1
  
  Hmm that's not all of it, I continue:
  `
  # learn how many octets are in remdir
  # wc is annoying since it was buggy on BSD and sometimes returns number of 'characters'
  foo $n
  # tar does not support --, so need to make sure all file/dir args start with /
  # or . (not starting with - is not good enough, some versions of tar treat @
  # as special for example.
  m=''
  for i in "$@"
  do
  m="$m"x
  done
  foo() {
  case "$c" in
  "$m")
  return 1 ;;
  esac
  c="$c"x
  return 0
  }
  c=''
  while foo
  do
  i="$1"; shift
  case "$i" in /* | .*) ;;
  *)
  i=./"$i" ;;
  esac
  set -- "$@" "$i"
  done
  # these next functions are so that remdir is sent followed by the tarball
  # this is what worked, various other methods ran into bugs in some versions of
  # bash!
  bar() {
  cat /dev/null`" && mkdir -p "$n" && cd "$n" && bunzip2 -c - | tar xvf -'\'''
14. Re:SFTP improvements by mzs · 2010-03-10 18:32 · Score: 1
  
  There's just a little bit more:
  cat /dev/null`" && mkdir -p "$n" && cd "$n" && bunzip2 -c - | tar xvf -'\'''
15. Re:SFTP improvements by mzs · 2010-03-10 18:37 · Score: 1
  
  I have NO idea how to get this to post on slashdot, here is the guts of the last line (in some heavy quoting):
  IFS=""; n="`dd bs='$n' count=1 2>/dev/null`" && mkdir -p "$n" && cd "$n" && bunzip2 -c - | tar xvf -
  The idea is that the name of the destination dir is sent over stdin to the target host. This way I do not need to deal with all the arcane quoting. The command line itself is fixed save for the integer of the length of the dir name, so no complicated quoting is needed there.
  Recently I have been using pax (I used to be a fan of cpio) mainly since it has the -s regex option and I can do some clever restructuring of the directories and files in this way all in one shot. But pax is not available on enough machines yet for me to use it so generically.
16. Re:SFTP improvements by mzs · 2010-03-10 20:02 · Score: 1
  
  I can't believe how badly slash code munged the script. Here is a link:
  http://home.fnal.gov/~mzs/tips/unix/ssh/stjput
17. Re:SFTP improvements by OttoM · 2010-03-10 21:08 · Score: 1
  
  Tab completion only applies to interactive sftp session, of course.
18. Re:SFTP improvements by Anonymous Coward · 2010-03-10 21:16 · Score: 0
  
  iirc, you can run ssh-agent as a shell (ssh-agent /bin/bash). That would not be "caching credentials" any more than credentials are cached when making an sftp connection. Once your task is done, you exit.
19. Re:SFTP improvements by ifrag · 2010-03-11 00:49 · Score: 1
  
  What does that mean exactly? Oh right, the Debian-approved one should have guessable private keys.
  
  --
  Fear is the mind killer.
20. Re:SFTP improvements by Anonymous Coward · 2010-03-11 00:52 · Score: 0
  
  No, he meant to write "At last!"
  Nut-job.
21. Re:SFTP improvements by Sancho · 2010-03-11 03:48 · Score: 1
  
  of course
  I don't think that's obvious. Remote file completion using scp has been working (with the correct packages) for a while now. Here's a bug report for a regression where it used to work, but then something changed and broke the behavior going from Jaunty to Karmic (Major Ubuntu releases.)
  https://bugs.launchpad.net/ubuntu/karmic/+source/bash-completion/+bug/449349
22. Re:SFTP improvements by Sancho · 2010-03-11 03:54 · Score: 1
  
  Something like pastebin would have been useful.
  http://pastebin.com/
23. Re:SFTP improvements by OttoM · 2010-03-11 04:22 · Score: 1
  
  We're talking about the base openssh code here, not what some distro added to it.
24. Re:SFTP improvements by Sancho · 2010-03-11 04:25 · Score: 1
  
  Maybe YOU were. Hatta (the person to whom I first replied) was talking about Bash/scp.
  http://tech.slashdot.org/comments.pl?sid=1578336&cid=31431572
25. Re:SFTP improvements by OttoM · 2010-03-11 04:41 · Score: 1
  
  Oops. You're right. Still tab completion in te FA is about tab completion in interactive sftp sessions.
26. Re:SFTP improvements by klui · 2010-03-11 04:47 · Score: 1
  
  # e.g. copy all non-hidden files and dirs from your home dir using protocol 2
  Couldn't you use tar (ask it to filter non-hidden files/directories) then pipe to ssh? I'm actually curious if there is an obscure reason why a script is necessary.
27. Re:SFTP improvements by Sancho · 2010-03-11 04:53 · Score: 1
  
  True. I guess maybe Hatta's question was "What's the point?" And maybe the answer is "For people who don't use Bash."
28. Re:SFTP improvements by OttoM · 2010-03-11 05:04 · Score: 1
  
  One typical use would be where you want people to use sftp, but do not want to give them shell access, any shell for that matter.
29. Re:SFTP improvements by Anonymous Coward · 2010-03-11 17:25 · Score: 0
  
  Why use sftp when you can use rsync?
30. Re:SFTP improvements by mzs · 2010-03-12 01:54 · Score: 1
  
  That's exactly what the script does but over the years it got more useful. It used to use cpio at first, so I would pipe find output into it. But then I ran into a machine that did not have cpio, so I changed it to tar. Then I ran into trouble once where a file started with -, so the checks for that. At some point I started using more OSX machines and then I routinely ran into paths with spaces and got tired double escaping that for ssh, so the work around. Then then the switch to chsum instead of wc because of some OSX version where wc counted characters wrong when there was a colon or backslash in the filename or something ridicuolous like that.
  And so that's how something so simple becomes so complicated over time. Oh and I could not use any too fancy options of tar since it's not always gnu tar that's installed. Also that's why I used cat instead of echo, I don't know what sh is.
31. Re:SFTP improvements by mzs · 2010-03-12 01:57 · Score: 1
  
  I ended-up just putting it here:
  http://home.fnal.gov/~mzs/tips/unix/ssh/stjput
  Yeah I should have used pastebin, it was late.
New, Problematic Protocol Introduced by jfjfjdk · 2010-03-10 08:52 · Score: -1, Troll
Available here. What's missing from this PROTOCOL.agent document?
- Any sign it's been reviewed by competent cryptographers.
- Any discussion of weaknesses, implementation errors to avoid, etc.
- Any plausible arguments that the extra lines of code needed for X.509 really outweigh the benefits of 22 years of review and practice.
Use at your own risk.
1. Re:New, Problematic Protocol Introduced by Kjella · 2010-03-10 09:06 · Score: 2, Insightful
  
  Please do tell what are the vital differences from version 1.4 made in 2008, because I think you're trolling. It looks like all RFCs normally look, either you haven't read many and don't have a clue what you're talking about or you are just trying to spread FUD.
  
  --
  Live today, because you never know what tomorrow brings
2. Re:New, Problematic Protocol Introduced by OttoM · 2010-03-10 09:11 · Score: 3, Informative
  
  No X.509 certificates are used. Please study the changes before you comment based on false assumptions. Also, the agent protocol exists for quite a while now, it is not new.
3. Re:New, Problematic Protocol Introduced by Anonymous Coward · 2010-03-10 18:13 · Score: 0
  
  I'm pretty sure he meant that he wants OpenSSH to justify *not* using X.509, given that it is so well tested and used just about everywhere else.
4. Re:New, Problematic Protocol Introduced by mccaffer · 2010-03-10 21:26 · Score: 1
  
  why does SSH continue this 'not invented here' crap with certs?? I don't care if the new certs are better. I don't have any new certs but I've got loads of x509 certs and I'm not going to throw them out.....
5. Re:New, Problematic Protocol Introduced by OttoM · 2010-03-10 21:38 · Score: 2, Interesting
  
  The OpenSSH developers do not trust any X.509 code. The actual X.509 validation and trust decision mechanisms are pretty horiffic, and I'm glad they stayed away from that. You don't have to throw away your X.509 certs, you can keep using them for other purposes.
Some interesting features... by Anonymous Coward · 2010-03-10 08:53 · Score: 1, Informative

I'm interested to see how the certificates and netcat features get used in the real world with SSH. I regenerated all of my SSH keys because they are defaulted to AES-128 bit encrypted and the public exponent is changed to 65537.
johnny stoops.
1. Re:Some interesting features... by Morth · 2010-03-10 10:13 · Score: 1
  
  ssh proxy nc host port
  has been working fine for quite a while, but I guess getting rid of the netcat dependency is a good thing.
2. Re:Some interesting features... by mzs · 2010-03-10 19:06 · Score: 1
  
  I've been using this in my ssh_config for a while:
  ProxyCommand /usr/bin/ssh -24 -o PermitLocalCommand=no -qaxT gateway exec /usr/bin/nc %h %p
  I find that -qaxT are really key to getting everything to work right and that's not documented well. You can of course forward X11 and what not, the trick is to not get the gateway involved, it just passes it on to the host and that sshd handles it. You don't need the pty on the gateway either, etc for the other options. That with ControlMaster and screen has really been a fantastic swiss army knife for dealing with lots of hosts.
  In case you run into a gateway that does not have netcat installed or you can't get putty to work right with netcat, a coworker of mine came-up with a trick where you use a socks proxy. It pretty ingenious but socks can proxy any tcp since the v4 or so not just http. If you are concerned about eavesdroppers inside that will not do, also if you have shared accounts on the machine you are sshing from it's not ideal unless your firewall allows you to restrict a port to UID.
  If you are using Windows and Kerberos then I have some builds of openssh here that are useful:
  http://home.fnal.gov/~mzs/tips/windows/ssh/
  This way you can use xterm or rxvt with cygwin and the MIT kerberos with ssh. I never really figured-out how to handled the mess that is Windows permissions (nothing like root:wheel it seems) so the files in those tarballs have my guids. There is a NOTES.txt there that explains a bit. You can see how I built. I have ssh38, scp38, sftp38 that supports gssapi and gssapi-with-mic. The 51 version supports only gssapi-with-mic.
3. Re:Some interesting features... by Morth · 2010-03-11 00:11 · Score: 1
  
  Both -a and -x are default though, and -T is also default if you give a command to execute, so only -q will actually do something there.
  It is quite common to turn on agent and X11 forwarding in ssh_config though, and then there is a point to those options (and I guess they don't hurt).
4. Re:Some interesting features... by mzs · 2010-03-11 03:22 · Score: 1
  
  Yes, I did a bad job of explaining, for example I have such entries:
  Host host.gateway
  ForwardX11 yes
  ForwardX11Trusted yes
  TCPKeepAlive yes
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  HostName host.example
  ProxyCommand /usr/bin/ssh -24 -o PermitLocalCommand=no -qaxT gateway.example exec /usr/bin/nc %h %p
  In my "Hosts *" sction earlier I have various items I usually like enabled (I have A LOT of hosts I ssh to, many not behind a gateway), such as agent and X11 forwarding. So before it dawned on me that I should leave these kinds of featres off for the gateway I could ot get things like X11 forwarding to host.gateway to work.
  BUt the key idea is that this all works if you disable for the gateway. For example:
  no X11 forwarding
  ssh -x host.gateway
  no pty on host.example (there is never one on gateway.example)
  ssh -T host.gateway 'echo "$TERM"'
  So what happens is that netcat forwards everything to host.gateway:%p and that sshd that gets forked there then can do any of these different modes just like before. The one on the gateway does not. For example I used to run out of pty on a heavily used gateway, the admin did not wish to increase the number, that's no longer a problem for me.
  I also think I quieted the ssh to the gateway since then for some gateways that used a banner I would get the huge gateway banner message. Again, that does not affect the settings of the host behind the gateway, though sometimes it makes it harder to see why a connection is failing (I can't remember if -v works here).
  Anyway I did a poor job of explaining, but it took me years of doing 'ssh gateway ssh host double-escaped-stuff' and two hop X11 forwarding with two proxies in that case before somehow it suddenly hit me that the netcat will forward everything so I just want to disable that stuff on the gateway and then I can enable/disable whatever I wish from the commandline or config files.
5. Re:Some interesting features... by Sancho · 2010-03-11 04:00 · Score: 1
  
  It is quite common to turn on agent and X11 forwarding in ssh_config though, and then there is a point to those options (and I guess they don't hurt).
  Agent forwarding should be selectively enabled only for hosts that you trust completely. A root user on the remote host can use your credentials for as long as you are connected.
Cygwin's package was updated, too by klui · 2010-03-10 09:06 · Score: 4, Interesting

The read-only feature of sftp makes it almost a replacement for anonymous ftp. Too bad it appears to be a global setting.
1. Re:Cygwin's package was updated, too by Sancho · 2010-03-10 09:28 · Score: 4, Interesting
  
  Could you not do this with a combination of Match User and ForceCommand directives? Something like:
  Match User anonymous
  ForceCommand sftp-server -R
  ChrootDirectory /home/anonymous
2. Re:Cygwin's package was updated, too by Korin43 · 2010-03-10 09:40 · Score: 1
  
  Anonymous SFTP? Maybe I'm missing something, but what's the point of encrypting data when it's all public?
3. Re:Cygwin's package was updated, too by Aladrin · 2010-03-10 09:59 · Score: 2, Insightful
  
  Just because it's public data doesn't mean you want anyone else to know what that particular user is doing.
  
  --
  "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
4. Re:Cygwin's package was updated, too by roman_mir · 2010-03-10 10:00 · Score: 4, Insightful
  
  Yes, you are missing the point.
  FTP is a fucking mess, I hate it, I wish I could kill it today everywhere. It is a disaster to manage with a firewall. The horrendous idea of using separate random ports for data connection vs control connections, the active/passive methods, it's is pure evil.
  SFTP is not FTP over SSH if you did not understand, it is a proper FTP that happens to run over a secured link.
  
  --
  You can't handle the truth.
5. Re:Cygwin's package was updated, too by Sancho · 2010-03-10 10:00 · Score: 2, Interesting
  
  Arguably, running one less service would be nice. Also, OpenSSH's chrooting is pretty painless for sftp (though arguably, proper chrooting mostly precludes the need for read-only service--having your server read-only does add another layer of security.)
6. Re:Cygwin's package was updated, too by klui · 2010-03-10 11:30 · Score: 2, Insightful
  
  I think I've just seen another incantation of ssh black magic (the other being command= in authorized_keys). Thanks for the insight.
7. Re:Cygwin's package was updated, too by Spit · 2010-03-10 13:40 · Score: 1
  
  You're obviously not running OpenBSD firewalls. ;)
  
  --
  POKE 36879,8
8. Re:Cygwin's package was updated, too by roman_mir · 2010-03-10 14:31 · Score: -1, Flamebait
  
  You are 100% wrong.
  I am running OpenBSD firewall, and I have a mix behind it, Fedora machines, Win Terminal, Ubuntu and some wintels. I am not a professional admin, I am creating systems but this firewall is on me as well. I have the pf and ftp-proxy configured correctly (checked by someone who knows this by heart), still can't have the ftp working for the internal network. Gone through all configurations, docs, still don't have it working. Have to waste more time on this later, just because the users 'need' the ftp to download shit from other firm...
  
  --
  You can't handle the truth.
9. Re:Cygwin's package was updated, too by eggnet · 2010-03-10 14:58 · Score: 1
  
  Encrypting the password.
10. Re:Cygwin's package was updated, too by grangerg · 2010-03-10 16:00 · Score: 1
  
  ...
  SFTP is not FTP over SSH if you did not understand, it is a proper FTP that happens to run over a secured link.
  No. SFTP isn't really "true" FTP at all---it's the SSH File Transfer Protocol. FTPS and FTPES, however are the encrypted forms of FTP; they're FTP over SSL.
11. Re:Cygwin's package was updated, too by value_added · 2010-03-10 16:25 · Score: 3, Insightful
  
  I am running OpenBSD firewall ... I have the pf and ftp-proxy configured correctly (checked by someone who knows this by heart), still can't have the ftp working for the internal network. Gone through all configurations, docs, still don't have it working. Have to waste more time on this later, just because the users 'need' the ftp to download shit from other firm...
  Sorry, but the pf/ftp-proxy combination works as advertised. I'd suggest your configuration is wrong. Asserting that it doesn't work because "someone who knows this by heart" examined it is meaningless.
  Fix your configuration and stop complaining. Both pf and ftp-proxy can do detailed logging. If you understand FTP, and you examine the logged output, you'll quickly find the source of your errors and, by extension, the solution.
  Granted FTP is a creaky protocol, and while it's true that most people don't understand it (even those that claim they do), it's just as true that it ain't going anywhere. Maybe it's time to brush up on the RFCs?
12. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-10 16:31 · Score: 2, Insightful
  
  SFTP is not FTP over SSH ... it is a proper FTP
  I believe what he is saying is that FTP, in the classical sense, is not a properly done File Transfer Protocol. I'm inclined to agree.
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
13. Re:Cygwin's package was updated, too by mzs · 2010-03-10 19:15 · Score: 1
  
  Have they fixed the bug with ChrootDirectory on Mac OS X? On that system / is group writeable and that fails some sanity check. I do not permit any admin users to ssh in though so it should not really be a problem in practice. (To admin you need to ssh in as yourself, then /usr/bin/login -p admin, from there sudo.) I used to have a dylib I would preload but at some point it stopped working so I would compile my own versions.
  Also it seemed a while back that I would be able to use sftp on even if sftp was disabled on the server. A coworker of mine implied that ot seemed that simply knowing where the sftp helper was you could run it if you could get a shell via ssh. I wonder if that has been addressed?
14. Re:Cygwin's package was updated, too by mzs · 2010-03-10 19:21 · Score: 1
  
  tcpdump is your friend too. It is likely simply some client is not using PASV.or BIN modes.
15. Re:Cygwin's package was updated, too by roman_mir · 2010-03-10 20:04 · Score: 0, Troll
  
  Who is complaining? I am told here; you are not using OpenBSD when I am in fact. There are no obvious errors showing up in the log files, yes, that's my problem. And yes, I had someone look at it who is more experienced that I am in setting up OpenBSD as a firewall and it is a valid thing to do, have another pair of eyes look at it, or are you infallible and never miss something that is obvious for someone else sometimes at the first glance? Geez, to talk to you people here, you are gods.
  
  --
  You can't handle the truth.
16. Re:Cygwin's package was updated, too by roman_mir · 2010-03-10 20:24 · Score: 0, Troll
  
  yes, thank you, Sherlock, what would I ever do without random advice from /. To think, how did I manage to have an OpenBSD box as a firewall since August and never needed to look at the log files through tcpdump? That's it, you have solved it for me.
  
  --
  You can't handle the truth.
17. Re:Cygwin's package was updated, too by roman_mir · 2010-03-10 20:59 · Score: 1
  
  I love this moderation: "I am having a problem, configured everything as found at open bsd web site, logs don't show any errors, a person with much more experience than I have in OpenBSD firewall configurations couldn't help either". /. moderator: "That's a flamebait, you can't be having a problem like that, that's impossible, you are starting a flamewar."
  Love /.
  
  --
  You can't handle the truth.
18. Re:Cygwin's package was updated, too by mzs · 2010-03-10 21:58 · Score: 1
  
  They don't have to be random. Say you decide that will allow 20 simultaneous connections, so then you allocate a block of 40 (if it's not busy you can have less, but TIMEDWAIT after the connection is closed implies you should have some extras) below the ephemeral lower limit. Then in your firewall you open-up those 40 to the world or your organization. If nothing is listening on a port then there really is no harm having that port open. If you like you can block outgoing ICMP port unreachable messages. With the tcp windows pretty much the only things an adversary can get away with is possibly a RST attack. So you could configure your ftp server and firewall like that.
  That said all the firewalls have very good mechanisms now for watching ftp connection and adding temporary rules for any secondary ports needed. You may have better luck reading the man pages and running the tools from the command line with -d and -v options, that way you will get more diagnostics.
  Please don't get upset, there were a lot of people offering useful advice. Maybe you can use HTTP instead if the FTP is too troublesome for you? BTW most people do not read log files using tcpdump, but I guess there are those ubercool that read the raw syslog traffic over the wire instead of tailing some log files, that must be you.
19. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-11 03:23 · Score: 1
  
  I had someone look at it who is more experienced that I am in setting up OpenBSD as a firewall
  Look, I'm sure your cat is very intelligent, and I don't doubt that it's a better sysadmin than you, but I think it is a bit unreasonable to expect a common housepet to properly determine the cause of an issue like this.
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
20. Re:Cygwin's package was updated, too by Just+Some+Guy · 2010-03-11 03:42 · Score: 1
  
  I'll take both sides here. OpenBSD + pf + ftp-proxy does work as advertised if it's set up right. That said, I agree completely that FTP is a freakin' mess and needs to be taken out back and shot. We have an FTP server for clients to upload certain documents to us, but we've adamantly deprecated it for new customers and are setting them all up with WebDAV over HTTPS. The new system wins over the old in every way imaginable.
  
  --
  Dewey, what part of this looks like authorities should be involved?
21. Re:Cygwin's package was updated, too by Sancho · 2010-03-11 03:43 · Score: 1
  
  Have they fixed the bug with ChrootDirectory on Mac OS X? On that system / is group writeable and that fails some sanity check.
  Don't really know, as I haven't had a need to do much advanced configuration on OS X sshd. Sounds like a strange bug, though.
  
  Also it seemed a while back that I would be able to use sftp on even if sftp was disabled on the server.
  Is there really a point to disabling sftp? If you have the filesystem-level permissions, you can perform those operations through SSH.
  "get" a file: ssh remote "cat rfile" > lfile
  "put" a file: ssh remote "cat > rfile" lfile
  And if the admin does some tricky things to only allow certain commands to be executed from the SSH session, they probably aren't stopping those commands from being called through the shell.
22. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 04:02 · Score: 1
  
  couldn't be the cat, it was busy shitting in your soup bowl.
  
  --
  You can't handle the truth.
23. Re:Cygwin's package was updated, too by Sancho · 2010-03-11 04:07 · Score: 1
  
  I constantly get my users complaining that their FTP server isn't working because port 20 incoming isn't open. I've had to start sending them a diagram of how FTP works.
24. Re:Cygwin's package was updated, too by Sancho · 2010-03-11 04:12 · Score: 1
  
  "I am having a problem, configured everything as found at open bsd web site, logs don't show any errors, a person with much more experience than I have in OpenBSD firewall configurations couldn't help either". /. moderator: "That's a flamebait, you can't be having a problem like that, that's impossible, you are starting a flamewar."
  Yeah, it should have been modded "troll."
  This is what you actually originally said:
  
  I have the pf and ftp-proxy configured correctly
  
  (emphasis mine)
  If it was configured correctly, you wouldn't be having the problems. Lots of people use pf+ftp-proxy for exactly this purpose.
25. Re:Cygwin's package was updated, too by Sancho · 2010-03-11 04:19 · Score: 1
  
  That said all the firewalls have very good mechanisms now for watching ftp connection and adding temporary rules for any secondary ports needed.
  Not if the command channel is encrypted. Then the firewall can't read the PORT command.
  FTP really is a mess that needs to go away, but we still get vendors who require it for one reason or another. We even have a couple who sniff the FTP prompt using something like an expect script, so if you're not using a particular version/vendor of FTP, they will fail. Of course, this sort of thing could happen with any protocol.
  Anyway, the guy you replied to obviously has some other issues besides just FTP being a crappy protocol :)
26. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 04:41 · Score: 1
  
  well, shit, as I said, I paid for help, not from someone off the street. http://openbsd.org/support.html#Canada - search for the name Russel. He is listed at OpenBSD site. In his words he could not see anything wrong with the configuration and I configured it before he looked. So am I trolling? Obviously something is not right, but if someone off bsd official commercial support list couldn't help, well then, what can I say, something is broken but it does not look broken. You want to fix it?
  
  --
  You can't handle the truth.
27. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 04:48 · Score: 1
  
  Asserting that it doesn't work because "someone who knows this by heart" examined it is meaningless.
  - well, I did get someone who knows by heart. A person of this list: openBSD commercial support, Russel.
  Now, "asserting that it doesn't work because ... it doesn't work" - because it doesn't. I said something does not work, but it looks correct, logs are not showing problems, the configuration looks correct yet ftp cannot be reached from inside the network. Does it work? No. Did I say "openBSD doesn't work"? No. I said it's not working, whatever the cause is and it looks correct.
  
  --
  You can't handle the truth.
28. Re:Cygwin's package was updated, too by Sancho · 2010-03-11 04:52 · Score: 1
  
  I was just pointing out a difference between what you said and what you (obviously) thought. You didn't give all the information, so your post sounded like maybe a troll or flamebait.
  And it's entirely possible that the problem lies outside of pf+ftp-proxy. "Nothing in the logs" is another clue that pf+ftp-proxy may be working. So where's the real problem? I don't know.
  As I mentioned elsewhere, I, too, think that FTP is a mess. I wholeheartedly share your pain and feelings on it.
29. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-11 05:38 · Score: 1
  
  How'd you determine that? Did you 'read its logs with tcpdump'?
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
30. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 07:01 · Score: 1
  
  Pffft, that was weak. Didn't have to, it talks, told me all about how you ate the soup and liked it.
  
  --
  You can't handle the truth.
31. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-11 07:43 · Score: 1
  
  Funny you should mention talking cats, my nephew claims to have one as well. Of course he is 5, you should probably seek professional psychiatric help...
  
  Pffft, that was weak.
  Of course with your condition you probably didn't catch this, but I was of course referencing this comment:
  
  yes, thank you, Sherlock, what would I ever do without random advice from /. To think, how did I manage to have an OpenBSD box as a firewall since August and never needed to look at the log files through tcpdump? That's it, you have solved it for me.
  You know, the one where you managed to conclusivly demonstrated that you are both a jackass, and a complete idiot, at the same time. It's cute how you still don't get how you messed up right there.
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
32. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 08:01 · Score: 1
  
  You know, the one where you managed to conclusivly demonstrated that you are both a jackass, and a complete idiot, at the same time. It's cute how you still don't get how you messed up right there.
  - that is all in your head, it's small and shriveled now, after tasting that soup.
  
  --
  You can't handle the truth.
33. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-11 08:20 · Score: 1
  
  As I said, cute.
  But I'm in a good mood today so I'll give you a hint: tcpdump isn't a pager, you don't read logs with it.
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
34. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 09:04 · Score: 1
  
  I'll give you a hint
  
  tcpdump -n -e -ttt -i pflog0
  
  bitch.
  
  --
  You can't handle the truth.
35. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-11 09:44 · Score: 1
  
  If you really think packet logs are the only logs relevant to your issue, or the only appropriate use of tcpdump, then I'm afraid I'm at a loss of words to describe the new level of idiocy you have achieved. The best I can do is offer forth my congratulations.
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
36. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 10:14 · Score: 1
  
  who said it was THE ONLY ONE, biatch?
  
  --
  You can't handle the truth.
37. Re:Cygwin's package was updated, too by Sir_Lewk · 2010-03-11 10:27 · Score: 1
  
  A fellow slashdot commenter kindly suggested that you make use of tcpdump to help resolve your issues. You verbally harassed him for his trouble, saying that you have already used it to review your logs.
  Ass-fiend.
  
  --
  "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
38. Re:Cygwin's package was updated, too by roman_mir · 2010-03-11 11:02 · Score: 1
  
  What are you, a knight in the shining armor, fighting for the fella /.ers? Must be the cat shit in your brains.
  
  --
  You can't handle the truth.
39. Re:Cygwin's package was updated, too by mzs · 2010-03-12 02:03 · Score: 1
  
  It's funny but I use rbash (restricted) and rsh (remote)just like that (vxworks).
  But I think we are agreeing, seems pointless to disable sftp if you let people login instead of restricting to certain commands.
40. Re:Cygwin's package was updated, too by Spit · 2010-03-13 23:21 · Score: 1
  
  Chances are you are matching your FTP traffic in anther rule. Check the order of:
  anchor "ftp-proxy/*"
  Make sure it doesn't have a quick rule before or a block rule after which would match it.
  
  --
  POKE 36879,8
Thank you Open SSH devs by overlordofmu · 2010-03-10 09:15 · Score: 5, Informative

I am reading this article and posting to it through a ssh tunnel using OpenSSH on a Gentoo Linux server at home and putty.exe on a work laptop running XP Pro at work.

Firefox sees it as a SOCKS 5 proxy at localhost. The tricky part was setting the config key in Firefox called "network.proxy.socks_remote_dns" to true. (Navigate to about:config and filter for "proxy" to find this setting quickly). The corporate network admins use bogus DNS resolution as a firewall.

I love you, OpenSSH devs. I sincerely thank you.
1. Re:Thank you Open SSH devs by Ponga · 2010-03-10 09:40 · Score: 1
  
  Hmm. I too use SSH tunnel for port redirection to a remote http proxy, but I've never had to set the FF flag you mention as my FF DNS queries go through the proxy "out of the box" - that's my understanding of how a SOCKS compatible proxy should work. Am I wrong here?
2. Re:Thank you Open SSH devs by neiko · 2010-03-10 09:50 · Score: 1
  
  I use the same setup here at my work in conjunction with FoxyProxy to conditionally load internal sites without using the SSH tunnel. Very handy stuff!
3. Re:Thank you Open SSH devs by Hatta · 2010-03-10 09:58 · Score: 1
  
  I do the same thing frequently. I've noticed a weird thing with my configuration. When I'm working through the tunnel, with DNS requests forwarded through the tunnel, and I go to a non-existent domain my ISP (cox) hijacks my NXDOMAIN and serves up a search page (with ads, obv). When I'm at home, I get NXDOMAIN just fine. Can't figure that one out.
  
  --
  Give me Classic Slashdot or give me death!
4. Re:Thank you Open SSH devs by Sancho · 2010-03-10 10:03 · Score: 2, Informative
  
  Are you sure they're going through the proxy out of the box? My Firefox had that configuration knob set to "false" by default, and DNS queries are definitely hitting my company's DNS server.
  If I tune the knob to true, they go through the proxy.
  Both cases verified with tcpdump.
5. Re:Thank you Open SSH devs by overlordofmu · 2010-03-10 10:32 · Score: 3, Interesting
  
  In my case, they block YouTube with a bogus DNS resolution. Internal DNS gives a intranet IP address (which gives a default intranet page) and my home server DNS gives the correct IP address(es). I tested this again, just now, and YouTube only works for me with that setting ("network.proxy.socks_remote_dns" as true) and is blocked if it is changed to false (which I believe is the default).
  
  I am using Firefox version 3.5.8, 32-bit, for x86.
  
  It seems, within Firefox itself, that your DNS queries with SOCKS 5 proxies still use the system default DNS and not the proxy DNS, but I could not say for sure without testing your machine. In my case, I am certain that Firefox is using the system DNS unless I change this setting from its default in Firefox. (I am certain because I just tested it 5 minutes ago.) Also, YouTube works without a proxy if I use the OpenDNS.org DNS servers in my Windows TCP/IP settings. (But then no intranet DNS queries work because OpenDNS knows nothing of our 10.*.*.* intranet.)
  
  Again, I am only speculating, but please consider than your DNS queries are not being proxied and are evidence of where you surf even if your traffic is SSHed.
  
  A final note, when I am really feeling paranoid about my surfing there is the AES 256-bit loopback block device that hold a Linux install on the work laptop. That way, there is no browser history to be searched by corporate. Hell, there is no Linux to be found; it looks like a whole partition of garbage without the decryption keys. It won't boot without them. However, I am developing for Windows on Windows, so the Linux boots are a rarity these days.
6. Re:Thank you Open SSH devs by owlstead · 2010-03-10 10:58 · Score: 1
  
  My provider XS4ALL runs a ssh daemon on port 443 of their server. Using a HTTP (Netscape) proxy works just as well (another good reason to keep the ISP's proxy in the air). Thanks for the remote DNS hint, didn't think about that (DNS at our company is non-restricted).
  Fortunately I did not have to use it for a while, nowadays the proxy settings of the company proxy are more reasonable. Before that I had trouble retrieving many web pages with "bad words". Including those necessary to do my work.
7. Re:Thank you Open SSH devs by Anonymous Coward · 2010-03-10 11:23 · Score: -1, Troll
  
  443 from XS4ALL is an SSL (well HTTPS) daemon, not an SSH daemon. Please hand in your wannabe sysadmin badge leave slashdot.
8. Re:Thank you Open SSH devs by ilikejam · 2010-03-10 11:37 · Score: 1
  
  I recently discovered that Thunderbird can also use SOCKS. No need for mutt in a putty session any more!
  
  --
  C-x C-s C-x k
9. Re:Thank you Open SSH devs by __1200333 · 2010-03-10 12:44 · Score: 1
  
  No need for mutt in a putty session any more!
  Sure you don't "need" to, but why wouldn't you want to?!
  Does thunderbird have the same dns issue as firefox (network.proxy.socks_remote_dns)?
10. Re:Thank you Open SSH devs by sam0737 · 2010-03-10 17:04 · Score: 1
  
  You know what, that's the same thing I did for getting over the Great Firewall of China with a server outside of the mainland.
11. Re:Thank you Open SSH devs by ilikejam · 2010-03-10 22:22 · Score: 1
  
  I like to look at the pretty pictures.
  Remote DNS? No idea. For some reason my work's DNS can see the Internet, so we can resolve everything anyway.
  
  --
  C-x C-s C-x k
12. Re:Thank you Open SSH devs by pnutjam · 2010-03-11 03:33 · Score: 1
  
  Thank you, that is very is very good to know. I didn't know you could get around the DNS issue for a SOCKS proxy.
  
  I went ahead and set up my home server for NX (nomachine) and I run a firefox window on my desktop that is really on my server. Bonus is I can disconnect it and reconnect it. It will still be where I left it. The firewall here blocks most ports other then the standards, 22 is open and NX has no problems
  
  --
  Cheap storage VM.
PLEASE NOTE: by Anonymous Coward · 2010-03-10 09:17 · Score: -1, Redundant

A brief quote from the home page of the project:
>
1. Re:Please note: by Anonymous Coward · 2010-03-10 10:35 · Score: 0, Troll
  
  Of course the license document included with this software spells out exactly what conditions the devs have placed on distribution, preparation of derivative works, etc. If they had wanted to, they could have required these companies to pay, or to provide source code, or whatever. They already made their choice; it's not really fair to whine about it now.
2. Re:PLEASE NOTE: by Anonymous Coward · 2010-03-10 10:36 · Score: 2, Funny
  
  that is brief!
3. Re:Please note: by FuckingNickName · 2010-03-10 10:41 · Score: -1, Troll
  
  They have donated by giving credibility to the project by choosing to use it; this in turn increases the number of eyes testing and contributing towards bug fixes and improvements. This is precisely the way that BSD-derived licenses work: the only thing you can expect is acknowledgement, and the only thing you can hope for is patches. To release under a licence which makes no accommodation whatever for financial compensation then write what comes down to a complaint that people aren't paying you is quite unreasonable.
  If it bothers you that Apple, Red Hat, Cisco, Juniper, and Novell aren't sending you a check in the mail, how about you change your license to make them pay: if it is cheaper for them than forking your code, they'll do it.
  I, for one, would much prefer to contribute toward effort on security at the lower levels rather than a single big tunnel. ssh it is almost as obnoxious as nat in this respect. I also got a bad taste from openssh ever since they disabled the "none" encryption - the amateur radio bands do not allow message encryption, but authentication/signing remains acceptable and useful.
4. Re:Please note: by tsalmark · 2010-03-10 14:34 · Score: 1
  
  I send them a few bucks every time I upgrade server software.
5. Re:Please note: by Anonymous Coward · 2010-03-10 15:09 · Score: 3, Funny
  
  A brief quote from the project's home page:
  Please take note of our Who uses it page, which list just some of the vendors who incorporate OpenSSH into their own products -- as a critically important security / access feature -- instead of writing their own SSH implementation or purchasing one from another vendor. This list specifically includes companies like Cisco, Juniper, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
  So go and DONATE, as i've just done.
  Okay, we get it Theo.
6. Re:Please note: by Abcd1234 · 2010-03-10 17:41 · Score: 3, Insightful
  
  In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
  And they don't have to, either morally or legally.
  OpenSSH is released under the BSD license, and the devs know full well that they may not be financially rewarded for their work. To suddenly expect those users to donate cash just because they use the very code you freed is, to say, the least, hypocritical. After all, if you wanted to be paid for the work you do, why are you releasing it for free to the world under one of the most liberal software licenses possible? Why not a dual license that requires payment for commercial use? Naturally because the BSDs are all about freedom, of course.
  Well, unless they think they're getting screwed financially.
7. Re:Please note: by Gaygirlie · 2010-03-10 19:36 · Score: 3, Insightful
  
  "And they don't have to, either morally or legally."
  Legally, no. But morally? Well, I beg to differ: those companies generate millions of dollars a year and would be in a completely different situation right now if they didn't have OpenSSH to benefit from. As such I see it as rather greedy and selfish not to donate anything at all.
  But alas, this only proves that people have different views of what is morally or ethically acceptable: what I find morally questionable you find completely acceptable, and the same thing would probably work also vice versa on some other topic.
8. Re:Please note: by Anonymous Coward · 2010-03-10 23:18 · Score: -1, Offtopic
  
  I see the moderators have been misusing the "Troll" moderation as a (-1, Disagree). I'm not sure about implementing identity encryption as I would have to think about the implications. But the rest about why you choose the BSD license seems perfectly correct. Businesses contribute by increasing the number of users and potential developers, as well as promoting your own name, which is basically what the parent said.
9. Re:Please note: by Abcd1234 · 2010-03-11 03:54 · Score: 1
  
  Legally, no. But morally? Well, I beg to differ: those companies generate millions of dollars a year and would be in a completely different situation right now if they didn't have OpenSSH to benefit from.
  Uh, so what? Those developers *chose* to release their code under a license which creates absolutely no obligation on the part of the user. They made that choice because they feel that open, free code is a good thing. So if their users don't give them any cash, why should they be surprised or offended? Meanwhile, why should those users feel any obligation whatsoever? The developers make the choice to donate their time. If the project isn't financially viable, that's hardly their problem.
  By your logic, I should expect local pet owners to give me a little cash because I volunteer at the local humane society. Of course, that's ridiculous, because I choose to donate my time without any expectation of a financial quid pro quo. The openssh developers are no different.
Please note: by Anonymous Coward · 2010-03-10 09:25 · Score: 5, Interesting

A brief quote from the project's home page:
Please take note of our Who uses it page, which list just some of the vendors who incorporate OpenSSH into their own products -- as a critically important security / access feature -- instead of writing their own SSH implementation or purchasing one from another vendor. This list specifically includes companies like Cisco, Juniper, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
So go and DONATE, as i've just done.
Thanks OpenSSH | Debian Devs DO NOT TOUCH. by 0100010001010011 · 2010-03-10 09:35 · Score: 4, Funny

OpenSSH is nothing short of magic. I too use it to tunnel out of work's firewall.
Now, Debian Dev. DON'T TOUCH. :)
No X.509 certificateds? by owlstead · 2010-03-10 11:03 · Score: 1

Why can't they use X.509 certificates like everybody else does? Are they too complex for SSH? Why no smart card support for those really secure connections?
Maybe we should just use OpenSSL & telnet or something similar, at least OpenSSL has PKCS#11 support nowadays. The only other thing required is a way to multiplex multiple protocols over SSL, but that certainly sounds doable.
1. Re:No X.509 certificateds? by Anonymous Coward · 2010-03-10 11:37 · Score: 0
  
  The only other thing required is a way to multiplex multiple protocols over SSL, but that certainly sounds doable.
  http://openvpn.net/
2. Re:No X.509 certificateds? by Anonymous Coward · 2010-03-10 11:41 · Score: 0
  
  You might want to read those release notes again, and notice PKCS#11 support as item #2
3. Re:No X.509 certificateds? by Anonymous Coward · 2010-03-10 13:49 · Score: 0
  
  Why can't they use X.509 certificates like everybody else does? Are they too complex for SSH? Why no smart card support for those really secure connections?
  Because X.509 is a huge complicated mess, and the OpenSSH (and OpenBSD) devs like simple things that can be easily checked for bugs and holes.
  There are third-party patches if you're interested though:
  http://www.roumenpetrov.info/openssh/
  Some PKCS#11 patches as well:
  http://sites.google.com/site/alonbarlev/openssh-pkcs11
  Generally the Open... folks are developing to scratch their own itch, and probably feel that these features are overkill (and IMHO they probably are for most people). Of course they use the BSD license, so you're free to fork and patch to your heart's content.
4. Re:No X.509 certificateds? by mzs · 2010-03-10 19:29 · Score: 1
  
  client X.509 certs with TLS is vulnerable to renegotiation attacks. telnet would be vulnerable to some timing attacks with TLS if it were not configured carefully as well. Sometimes simple is better.
5. Re:No X.509 certificateds? by mccaffer · 2010-03-10 21:29 · Score: 1
  
  the cert is not the same as the transport. It's not certs that make TLS vulnerable, it's TLS.
  SSH only has to make sure that it gets the public part of the key on the server. Then it's the same as ssh as normal
history of FTP by Anonymous Coward · 2010-03-10 11:16 · Score: 2, Informative

FTP is a fucking mess, I hate it, I wish I could kill it today everywhere. It is a disaster to manage with a firewall. The horrendous idea of using separate random ports for data connection vs control connections, the active/passive methods, it's is pure evil.
At the time of its invention FTP's design made sense.
TCP allows bi-directional traffic on a port, but TCP was not invented when FTP was first created (1971). The protocol that was around only allowed one-way transmission of data on any connection. So when you FTPed into a machine, and server had to open a connection back to the client to return any data.
Also remember that firewalls were also not invented until the late '80s (earlier '90s?), so the blocking of connections back to the client weren't an issue. It was only later on (mid-'90s) where the combination of active/passive modes and security lock downs became a headache.
By that time there was a large amount of inertial behind FTP--and remember that HTTP was mostly still young in the '90s as well, and the read/write web wasn't that all that popular (and even things like WebDAV isn't used a lot even now).
So while I fell your pain (I'm a sys admin), there aren't / weren't that many alternatives.
1. Re:history of FTP by roman_mir · 2010-03-10 11:19 · Score: 1
  
  I don't dispute any of that, it's obviously true, but FTP should have been either abolished about 20 years ago or at least modified as a protocol standard to transition to a new more sensible implementation. So when the question arises about the reasons of switching to SFTP, well, even disregarding the 'secure' part, the protocol deficiency itself is a valid reason to switch.
  
  --
  You can't handle the truth.
2. Re:history of FTP by mzs · 2010-03-10 19:18 · Score: 1
  
  You mean like rcp or uucp? ftp was so dominant simply because the ftp client was wonderfully interactive for its time.
3. Re:history of FTP by roman_mir · 2010-03-10 20:20 · Score: 1
  
  no, I mean like ftp. FTP should have been modified as a protocol and implementation over time to be more like other well behaved protocols.
  
  --
  You can't handle the truth.
Huh.. by Anonymous Coward · 2010-03-10 11:32 · Score: 0

This morning on Amiga.org: http://www.amiga.org/forums/showthread.php?t=51842
FTP should be dead, long live SFTP by dbIII · 2010-03-10 12:44 · Score: 1

Since the FireFTP addon to Firefox can support sftp we may see the end of plain FTP soon.
I really should do some sort of https thing to allow secure upload of files instead of users having to use FTP, but never get around to more than googling in vain for others doing the same thing. Has anyone seen anything like that?
1. Re:FTP should be dead, long live SFTP by Compaqt · 2010-03-11 04:17 · Score: 1
  
  Anything wrong with WebDAV?
  
  --
  I'm not a lawyer, but I play one on the Internet. Blog
2. Re:FTP should be dead, long live SFTP by dbIII · 2010-03-11 20:36 · Score: 1
  
  Anything wrong with WebDAV?
  "The folder you entered does not appear to be valid. Please choose another"
  The wikipedia page really sums up how it's far more confusing to people to set up than emailing brief instructions on how to connect via FTP.
  The major purpose of FTP now IMHO is to transport files that are too large to email and too sensitive to post on a public web site. That means a lot of novice or occasional users for whichever method and FTP (or ideally SFTP) has a shorter learning curve than WebDAV.
  I would love to be proved wrong, it's been about two years since I looked at WebDAV and I have no idea if it handles files over 2GB, supports reget properly and other oddities that have people still on FTP.
SFTP and FTPS are different by Anonymous Coward · 2010-03-10 16:12 · Score: 1, Informative

SFTP is not FTP over SSH if you did not understand, it is a proper FTP that happens to run over a secured link.
FTP over a secured link is FTPS (FTP over SSL/TLS), which is distinct from SFTP (SSH file transfer protocol).
http://en.wikipedia.org/wiki/Ftps
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol
Performance note:
FTPS can stream files at full TCP speeds, while most SFTP implementations suffer from the SSH and SFTP protocol performance problems caused by having small application-level window and packet sizes (often 32 to 64KB) and requiring a fixed set of packets to be acknowledged before the next bunch is sent.
For details, see section 6.2, "The SSHv2 and SFTP Performance Handbrake" in http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf
and pages 27 to 30 in http://fasterdata.es.net/talks/Tierney-tutorial.pdf.
Bullshit. by Anonymous Coward · 2010-03-11 01:16 · Score: 0

I am getting really tired of people that can't read the licenses of the software they are producing or using.
If you are wrtiitng software and will take issue if you are not paid, then you are using thw wrong licensing cheme.
If you are using software from people that has decided to make it Open, then it is not up to you to go in fits of moral outrage on their behalf: they are grown up people, they know what they are doing ....