Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSH 5.4 Released

timothy posted more than 4 years ago | from the but-it's-secret dept.

Encryption 127

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.'"

cancel ×

127 comments

Sorry! There are no comments related to the filter you selected.

open anus (-1)

Anonymous Coward | more than 4 years ago | (#31430656)

First post

SFTP improvements (3, Informative)

Ponga (934481) | more than 4 years ago | (#31430758)

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

Re:SFTP improvements (3, Funny)

ig88b (1401217) | more than 4 years ago | (#31430854)

I'm confused. You're excitedly sad about the sftp improvements?

Re:SFTP improvements (0)

Anonymous Coward | more than 4 years ago | (#31431020)

Hell yeah - tab completion and recursive get/put are long overdue!

Re:SFTP improvements (1)

moonbender (547943) | more than 4 years ago | (#31431030)

No, no, he meant to write "Atlas!!"

Weirdo.

Re:SFTP improvements (0)

Anonymous Coward | more than 4 years ago | (#31434486)

No, no, he meant to write "Atlas!!"

Weirdo.

I dunno, I think a book of maps is more bizarre than excitedly sad.

Re:SFTP improvements (0)

Anonymous Coward | more than 4 years ago | (#31436470)

No, he meant to write "At last!"

Nut-job.

Re:SFTP improvements (2, Funny)

Torrance (1599681) | more than 4 years ago | (#31431318)

- Implement tab-completion of commands, local and remote filenames

Well thank frak.

Re:SFTP improvements (1)

Hatta (162192) | more than 4 years ago | (#31431572)

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.

Re:SFTP improvements (2, Interesting)

Sancho (17056) | more than 4 years ago | (#31431620)

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!

Re:SFTP improvements (1)

Hatta (162192) | more than 4 years ago | (#31431752)

I usually have my credentials in ssh-agent, but I think I've been prompted for a password after hitting tab before.

Re:SFTP improvements (1)

klui (457783) | more than 4 years ago | (#31434622)

Tab-completion is not enabled if libedit is not installed. Cygwin's distribution doesn't enable it.

Re:SFTP improvements (1)

OttoM (467655) | more than 4 years ago | (#31435684)

Tab completion only applies to interactive sftp session, of course.

Re:SFTP improvements (1)

Sancho (17056) | more than 4 years ago | (#31438438)

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 [launchpad.net]

Re:SFTP improvements (0)

Anonymous Coward | more than 4 years ago | (#31435706)

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.

Re:SFTP improvements (0)

Anonymous Coward | more than 4 years ago | (#31432060)

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

Re:SFTP improvements (1)

beav007 (746004) | more than 4 years ago | (#31433412)

Sounds great, but I think I'll wait for the Debian-approved version.

Re:SFTP improvements (1)

ifrag (984323) | more than 4 years ago | (#31436458)

What does that mean exactly? Oh right, the Debian-approved one should have guessable private keys [slashdot.org] .

Re:SFTP improvements (1)

mzs (595629) | more than 4 years ago | (#31434998)

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 -'\'''

Re:SFTP improvements (1)

mzs (595629) | more than 4 years ago | (#31435010)

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 -'\'''

Re:SFTP improvements (1)

mzs (595629) | more than 4 years ago | (#31435022)

There's just a little bit more:
cat /dev/null`" && mkdir -p "$n" && cd "$n" && bunzip2 -c - | tar xvf -'\'''

Re:SFTP improvements (1)

mzs (595629) | more than 4 years ago | (#31435050)

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.

Re:SFTP improvements (1)

Sancho (17056) | more than 4 years ago | (#31438604)

Something like pastebin would have been useful.

http://pastebin.com/ [pastebin.com]

New, Problematic Protocol Introduced (-1, Troll)

jfjfjdk (1260722) | more than 4 years ago | (#31430778)

Available here [openbsd.org] . 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.

Re:New, Problematic Protocol Introduced (2, Insightful)

Kjella (173770) | more than 4 years ago | (#31430936)

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.

Re:New, Problematic Protocol Introduced (3, Informative)

OttoM (467655) | more than 4 years ago | (#31431022)

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.

Re:New, Problematic Protocol Introduced (0)

Anonymous Coward | more than 4 years ago | (#31434962)

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.

Re:New, Problematic Protocol Introduced (1)

mccaffer (80806) | more than 4 years ago | (#31435742)

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

Re:New, Problematic Protocol Introduced (2, Interesting)

OttoM (467655) | more than 4 years ago | (#31435792)

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... (1, Informative)

Anonymous Coward | more than 4 years ago | (#31430786)

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.

Re:Some interesting features... (1)

Morth (322218) | more than 4 years ago | (#31431836)

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.

Re:Some interesting features... (1)

mzs (595629) | more than 4 years ago | (#31435138)

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/ [fnal.gov]

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.

Re:Some interesting features... (1)

Morth (322218) | more than 4 years ago | (#31436322)

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

Re:Some interesting features... (1)

mzs (595629) | more than 4 years ago | (#31437826)

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.

Re:Some interesting features... (1)

Sancho (17056) | more than 4 years ago | (#31438740)

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 (4, Interesting)

klui (457783) | more than 4 years ago | (#31430938)

The read-only feature of sftp makes it almost a replacement for anonymous ftp. Too bad it appears to be a global setting.

Re:Cygwin's package was updated, too (4, Interesting)

Sancho (17056) | more than 4 years ago | (#31431224)

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

Re:Cygwin's package was updated, too (2, Insightful)

klui (457783) | more than 4 years ago | (#31432592)

I think I've just seen another incantation of ssh black magic (the other being command= in authorized_keys). Thanks for the insight.

Re:Cygwin's package was updated, too (1)

mzs (595629) | more than 4 years ago | (#31435184)

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?

Re:Cygwin's package was updated, too (1)

Sancho (17056) | more than 4 years ago | (#31438310)

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.

Re:Cygwin's package was updated, too (1)

Korin43 (881732) | more than 4 years ago | (#31431382)

Anonymous SFTP? Maybe I'm missing something, but what's the point of encrypting data when it's all public?

Re:Cygwin's package was updated, too (2, Insightful)

Aladrin (926209) | more than 4 years ago | (#31431650)

Just because it's public data doesn't mean you want anyone else to know what that particular user is doing.

Re:Cygwin's package was updated, too (4, Insightful)

roman_mir (125474) | more than 4 years ago | (#31431654)

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.

history of FTP (2, Informative)

Anonymous Coward | more than 4 years ago | (#31432462)

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.

Re:history of FTP (1)

roman_mir (125474) | more than 4 years ago | (#31432504)

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.

FTP should be dead, long live SFTP (1)

dbIII (701233) | more than 4 years ago | (#31433174)

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?

Re:history of FTP (1)

mzs (595629) | more than 4 years ago | (#31435194)

You mean like rcp or uucp? ftp was so dominant simply because the ftp client was wonderfully interactive for its time.

Re:history of FTP (1)

roman_mir (125474) | more than 4 years ago | (#31435508)

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.

Re:Cygwin's package was updated, too (1)

Spit (23158) | more than 4 years ago | (#31433556)

You're obviously not running OpenBSD firewalls. ;)

Re:Cygwin's package was updated, too (-1, Flamebait)

roman_mir (125474) | more than 4 years ago | (#31433858)

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

Re:Cygwin's package was updated, too (3, Insightful)

value_added (719364) | more than 4 years ago | (#31434492)

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?

Re:Cygwin's package was updated, too (1)

mzs (595629) | more than 4 years ago | (#31435206)

tcpdump is your friend too. It is likely simply some client is not using PASV.or BIN modes.

Re:Cygwin's package was updated, too (0, Troll)

roman_mir (125474) | more than 4 years ago | (#31435516)

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.

Re:Cygwin's package was updated, too (0, Troll)

roman_mir (125474) | more than 4 years ago | (#31435432)

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.

Re:Cygwin's package was updated, too (1)

Sir_Lewk (967686) | more than 4 years ago | (#31437858)

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.

Re:Cygwin's package was updated, too (1)

roman_mir (125474) | more than 4 years ago | (#31438766)

couldn't be the cat, it was busy shitting in your soup bowl.

Re:Cygwin's package was updated, too (1)

Sancho (17056) | more than 4 years ago | (#31438892)

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.

Re:Cygwin's package was updated, too (1)

roman_mir (125474) | more than 4 years ago | (#31435640)

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 /.

Re:Cygwin's package was updated, too (1)

Sancho (17056) | more than 4 years ago | (#31438970)

"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.

Re:Cygwin's package was updated, too (1)

Just Some Guy (3352) | more than 4 years ago | (#31438298)

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.

Re:Cygwin's package was updated, too (1)

grangerg (309284) | more than 4 years ago | (#31434360)

...

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.

Re:Cygwin's package was updated, too (2, Insightful)

Sir_Lewk (967686) | more than 4 years ago | (#31434530)

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.

SFTP and FTPS are different (1, Informative)

Anonymous Coward | more than 4 years ago | (#31434418)

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 [wikipedia.org]
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol [wikipedia.org]

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 [auckland.ac.nz]
and pages 27 to 30 in http://fasterdata.es.net/talks/Tierney-tutorial.pdf [es.net] .

Re:Cygwin's package was updated, too (1)

mzs (595629) | more than 4 years ago | (#31435872)

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.

Re:Cygwin's package was updated, too (2, Interesting)

Sancho (17056) | more than 4 years ago | (#31431658)

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

Re:Cygwin's package was updated, too (1)

eggnet (75425) | more than 4 years ago | (#31434028)

Encrypting the password.

Thank you Open SSH devs (5, Informative)

overlordofmu (1422163) | more than 4 years ago | (#31431078)

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.

Thanks OpenSSH | Debian Devs DO NOT TOUCH. (4, Funny)

0100010001010011 (652467) | more than 4 years ago | (#31431306)

OpenSSH is nothing short of magic. I too use it to tunnel out of work's firewall.

Now, Debian Dev. DON'T TOUCH. :)

Re:Thank you Open SSH devs (1)

Ponga (934481) | more than 4 years ago | (#31431374)

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?

Re:Thank you Open SSH devs (2, Informative)

Sancho (17056) | more than 4 years ago | (#31431696)

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.

Re:Thank you Open SSH devs (3, Interesting)

overlordofmu (1422163) | more than 4 years ago | (#31432052)

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.

Re:Thank you Open SSH devs (1)

neiko (846668) | more than 4 years ago | (#31431514)

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!

Re:Thank you Open SSH devs (1)

Hatta (162192) | more than 4 years ago | (#31431640)

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.

Re:Thank you Open SSH devs (1)

owlstead (636356) | more than 4 years ago | (#31432314)

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.

Re:Thank you Open SSH devs (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31432532)

443 from XS4ALL is an SSL (well HTTPS) daemon, not an SSH daemon. Please hand in your wannabe sysadmin badge leave slashdot.

Re:Thank you Open SSH devs (1)

ilikejam (762039) | more than 4 years ago | (#31432652)

I recently discovered that Thunderbird can also use SOCKS. No need for mutt in a putty session any more!

Re:Thank you Open SSH devs (1)

__1200333 (1200333) | more than 4 years ago | (#31433178)

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)?

Re:Thank you Open SSH devs (1)

ilikejam (762039) | more than 4 years ago | (#31435938)

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.

Re:Thank you Open SSH devs (1)

sam0737 (648914) | more than 4 years ago | (#31434666)

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.

Re:Thank you Open SSH devs (1)

pnutjam (523990) | more than 4 years ago | (#31438080)

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

PLEASE NOTE: (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#31431094)

A brief quote from the home page of the project:

>

Re:PLEASE NOTE: (2, Funny)

Anonymous Coward | more than 4 years ago | (#31432090)

that is brief!

Please note: (5, Interesting)

Anonymous Coward | more than 4 years ago | (#31431190)

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.

Re:Please note: (0, Troll)

Anonymous Coward | more than 4 years ago | (#31432082)

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.

Re:Please note: (-1, Troll)

FuckingNickName (1362625) | more than 4 years ago | (#31432150)

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.

Re:Please note: (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31436118)

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.

Re:Please note: (1)

tsalmark (1265778) | more than 4 years ago | (#31433874)

I send them a few bucks every time I upgrade server software.

Re:Please note: (3, Funny)

Anonymous Coward | more than 4 years ago | (#31434078)

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.

Re:Please note: (3, Insightful)

Abcd1234 (188840) | more than 4 years ago | (#31434808)

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.

Re:Please note: (3, Insightful)

Gaygirlie (1657131) | more than 4 years ago | (#31435264)

"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.

Re:Please note: (1)

Abcd1234 (188840) | more than 4 years ago | (#31438610)

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.

Bullshit. (0)

Anonymous Coward | more than 4 years ago | (#31436604)

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

No X.509 certificateds? (1)

owlstead (636356) | more than 4 years ago | (#31432374)

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.

Re:No X.509 certificateds? (0)

Anonymous Coward | more than 4 years ago | (#31432650)

The only other thing required is a way to multiplex multiple protocols over SSL, but that certainly sounds doable.

http://openvpn.net/

Re:No X.509 certificateds? (0)

Anonymous Coward | more than 4 years ago | (#31432678)

You might want to read those release notes again, and notice PKCS#11 support as item #2

Re:No X.509 certificateds? (0)

Anonymous Coward | more than 4 years ago | (#31433604)

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.

Re:No X.509 certificateds? (1)

mzs (595629) | more than 4 years ago | (#31435234)

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.

Re:No X.509 certificateds? (1)

mccaffer (80806) | more than 4 years ago | (#31435764)

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

Huh.. (0)

Anonymous Coward | more than 4 years ago | (#31432614)

This morning on Amiga.org: http://www.amiga.org/forums/showthread.php?t=51842

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>