Re: a question about proper use of ssh
[ On Thursday, September 6, 2001 at 00:23:14 (-0500), '[EMAIL PROTECTED]' wrote: ] Subject: Re: a question about proper use of ssh Umm. I think you mis-understood me abit. I'm not asking how should I config -my- sshd, but what is the general usage of the client ssh. And this would include using ssh on a public terminal (for example, at Linux World Expo, at the Email garden or some linux internet cafe' or a friend's house). A dot file is not something that can used in that critria (sp?). In other words, what can I -try- to instill (sp?) in my users/cleints on the proper usage of ssh. they can do whatever they want, but I want to be able to give them a good head-start. There is no really safe way to use a public terminal with SSH unless you can verify the integrity of its hardware and its software, right from the keycaps to the network interface. SSH implicitly requires that the server administrator trust the client host hardware, software, *and* user. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Hide ssh version string?
[ On Thursday, August 16, 2001 at 14:29:24 (-0600), Apolis, Jeff wrote: ] Subject: Hide ssh version string? ... well our security policy dictates that we obscure the version numbers of any running application when at all possible - to make a hacker's job just a little bit harder. Why bother? That's just idiotic security by obscurity. If anything it'll invite more attack attempts than it thwarts! Oh, look! Some idiot thinks he can hide his broken SSHd from me! Watch this! :-) Attack robots will often attack anyway. Witness CodeRed and its variants. I've thousands of attacks in my apache logs -- it sure as heck didn't bother to check what web server I was running, let alonwe what release. Are there any negative side effects to doing this? I suspect some subtle interoperability issues with other variants of SSH which try to determine OpenSSH bugs based on it's reported version number. !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN Please DO NOT EVER send HTML crap to public mailing lists (or to me!)! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: [ssh]: Subject emails
[ On Friday, August 10, 2001 at 10:15:04 (+0900), J Grant wrote: ] Subject: [ssh]: Subject emails I have a small request, could the moderator of the email list add [ssh]: to the subject of emails that go through this list please? It would be simpler to search for emails I file then and also I can reply to important emails quicker. Would anyone else be interested in this subject modification? NO! Absolutely not! This is a request, i have only just joined so I dont want to sound authoritive. There are at least three other headers to filter/sort with. If/when the list is moved to ssh.com it may even gain more headers. Almost every modern mail reader can trivially filter and/or sort on any of the already available headers. If yours can't it's high time you upgraded to something that can. There's absolutely no need to have the MLM software pollute a sender-defined header with redundant information that only gets in the way and takes up valuable space. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: I hate xauth
[ On Monday, July 30, 2001 at 07:17:55 (-0500), Tony Mantler wrote: ] Subject: Re: I hate xauth I rarely if ever connect to systems that are either A: multi-user or B: even remotely untrusted, Do you understand how trust propogates implicitly by your act of trusting a remote host, especially when you're running the likes of X11? Even with plain old SSH with all forwarding disabled on both ends, you must still trust both the client and server hosts, and the server admin must trust not just you, but also your ability to run a secure client host since if you can't then there's literally no way for the server admin to trust you since you might not be the one in direct control of the data stream SSH is sending to the server, and you might not see everything the server is sending back to you. Use of SSH does not itself imply everything's secure -- SSH just offers a way of protecting the data crossing a public or semi-public network between two more or less equally trusted hosts. You must still ensure that all your hosts, clients and servers, are as secure as you need them to be. (In general I'd guess that the SSH-2 protocol provides at least an order of magnitude more network security than any host it's commonly used with. :-) If you trust your local client system then you must not ever connect it with SSH to any remote host that's even vaguely less trusted than your local client. You must certainly never allow any less trusted client to connect to it as a server either! Note that this all means if either host is not multi-user (i.e. does not have a deeply embedded core mechanism in the OS to maintain the identity of user actions and data, as well as offering protection mechanisms for the user processes and data), then you have to be very very very careful about what uses you make of that system to ensure that it is kept as secure as any other system it is connected to. so xauth authentication really just gets in my way for me, and I'd like to be able to turn it off. I've never had any problems with SSH setting up xauth authentication for my remote X11 clients. It just works. It's so clean and simple and automatic that I can't even quite imagine doing it any other way any more! -- Tony Nicoya Mantler - Renaissance Nerd Extraordinaire - [EMAIL PROTECTED] Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/ Now those three places are really a long way appart from each other! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: How can I access anonymously with the sftp client ?
[ On Tuesday, April 3, 2001 at 11:39:53 (+0200), Francisco
=?iso-8859-1?Q?Jes=FAs_Mart=EDn?= Mateos wrote: ]
Subject: How can I access anonymously with the sftp client ?
I have installed Openssh 2.5.2 in my RedHat 7.0. I have activated the
"sftp" subsystem with the following configuration:
Subsystem sftp /usr/libexec/openssh/sftp-server
But I can't access anonymously to the system with the sftp client (The
wu-ftpd is correctly configured).
What's the problem ?
SFTP is not FTP. It is a very badly named substitute for CP. Sftp
clients will never talk to your wu-ftpd.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: getting shared dynamic libraries
[ On Tuesday, March 20, 2001 at 12:55:22 (+1100), Damien Miller wrote: ] Subject: Re: getting shared dynamic libraries That is just silly - if someone is in a position to play games with you system libraries then they can do a lot more damage than that. That's not always true (witness LD_LIBRARY_PATH and the atrocities attributed to its misuse). Since libc is almost always a dynamic lib, then it makes little sense to statically link against other things. That's bull. Libc is not always a dynamic library, and it often makes lots of sense to statically link sensitive binaries (be they sensitive in the generic security sense, or only in the sense that they have to be highly available and reliable). You may want to statically link against OpenSSL if you plan on upgrading it. All OpenSSL releases to date have broken binary compatability. If you staticly link ssh or sshd then presumably you statically link the entire binary, not just with a few of the dependent libraries. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: getting shared dynamic libraries
[ On Wednesday, March 21, 2001 at 11:42:07 (+1100), Damien Miller wrote: ]
Subject: Re: getting shared dynamic libraries
On Tue, 20 Mar 2001, Greg A. Woods wrote:
[ On Tuesday, March 20, 2001 at 12:55:22 (+1100), Damien Miller wrote: ]
Subject: Re: getting shared dynamic libraries
That is just silly - if someone is in a position to play games with you
system libraries then they can do a lot more damage than that.
That's not always true (witness LD_LIBRARY_PATH and the atrocities
attributed to its misuse).
LD_LIBRARY_PATH is ignored for setuid apps (like ssh) by any sane OS. If
an attacker is able to set arbitrary env vars, then you have bigger
problems than statically linked binaries are going to solve, they could
just diddle $PATH and point you to a trojan ssh binary for example.
SSH is not entirely a setuid application. In fact now in SSH-2.4.x only
ssh-signer2 is setuid.
While what you say is mostly true for the SSH daemon (because it's
usually started at boot by a root-owned process), there are still lots
of games an attacker can play that could make use of the properties of
dynamic loaders
Since libc is almost always a dynamic lib, then it makes little sense
to statically link against other things.
That's bull. Libc is not always a dynamic library, and it often makes
lots of sense to statically link sensitive binaries (be they sensitive
in the generic security sense, or only in the sense that they have to be
highly available and reliable).
Systems without a dynamic libc generally statically link eveything anyway,
so this issue is moot.
Excuse me? My systems all have both static and dynamic libraries and
usually give the full ability to statically or dynamically link any
given program that's built on them! All of /bin and /sbin are
statically linked on my systems, while most of /usr/bin and /usr/sbin
are linked dynamically.
All the world's not linux or solaris you know!
You must have a lot of RAM:
[djm@xenon openssh]$ ls -l ssh ssh.static
-rwxrwxr-x1 djm djm186020 Mar 21 11:43 ssh
-rwxrwxr-x1 djm djm 1158408 Mar 21 11:43 ssh.static
The size of the binary file image does not show the real memory
footprint of any program. First off you have to use 'size' to get even
a round number estimate. Secondly you have to examine the actual memory
footprint of both the first process and subsequent instances of it.
Furthermore on all modern unix and unix-like systems the text portion of
all binaries, including static binaries, are shared amongst all
instances of processes loaded from those binaries (and in fact that's
how some dynamic loading systems work too).
Finally you have to consider the mix of processes running on the system
during general use. Shared text means that additional memory used by
library code in static binaries might not add up to any significant
percentage of total memory use on any given general purpose system.
Meanwhile the added resources consumed by ld.so and the various extra
tables necessary to do the run-time linking might be quite significant.
Profiling memory use on unix is never as simple as running "ls -l" (not
even on ancient V7!).
FYI for the first step on NetBSD/i386 with egcs-1.1.2 and '-g -O2':
$ size ssh2.static ssh2.dynamic
textdatabss dec hex filename
834671 23000 44252 901923 dc323 ssh2.static
566919 19152 856 586927 8f4af ssh2.dynamic
That's a bit more, but not a terribly large amount more, and most of it
is shared text anyway. (I am curious about the 42k BSS that must be in
some library module.)
On many systems this won't work properly anyway - Solaris and Linux need to
be able to dynamically load nss libs etc.
Yeah, but I don't use such stupid and broken systems in any place where
the security of the likes of SSH is necessary. :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: OpenSSH/scp - F-Secure SSH server Problems
[ On Friday, March 16, 2001 at 10:23:19 (+1100), Damien Miller wrote: ]
Subject: Re: OpenSSH/scp - F-Secure SSH server Problems
On Thu, 15 Mar 2001, Greg A. Woods wrote:
Exactly! That's why the "built-in subsystem" feature is a wart!
There's no way to enforce implementations to honour the registered
names!
So what? If people want to break there systems, then we shouldn't
stop them. Unix provides no way to _force_ people not to rename 'rm'
to 'ls' either and it still works pretty well - people don't do it
becuase it is _stupid_ to mess with well-known names.
Strangely with SSHv1 we all learned (or already knew implicitly) how to
deal with the problems of command paths and naming (and indeed
capabilities and syntax) on SSH servers. This was possible because
there was a direct association between the system being connected to,
and its uniqueness.
SSHv2's "built-in subsystem" introduces a new naming system, and one
that will not necessarily be in the direct control of server
administrators (but rather with software developers). This new naming
system is infinitely harder to deal with from the user level because it
now depends on the type of server software running on the target system,
not on the former direct relationship with the server system's name
and/or address.
SSHv2's "built-in subsystem" is not just not necessary -- it's
detrimental to the successful management of user's (and programmer's)
expectations!
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: OpenSSH/scp - F-Secure SSH server Problems
[ On Wednesday, March 14, 2001 at 18:41:39 (-0600), mouring@localhost[eviladmin.org]
wrote: ]
Subject: Re: OpenSSH/scp - F-Secure SSH server Problems
On Wed, 14 Mar 2001, Greg A. Woods wrote:
[..]
Or are you suggesting that if OpenBSD connects to Solaris that I should
run a different sftp-server then if Linux connects to Solaris?
IMNSHO that should be up to the client, but restricted by the server
administrator.
IMNSHO it's up to the administrator and not the connecting client.
Ben, that's almost exactly what I said, but only from the opposite
perspective! The current subsystem naming scheme does *NOT* allow the
administrator to control what service is expected under which name! The
administrator *MUST* adhere to either a given implementation, or if a
central naming authority is defined, then to that authority, or else
face inter-operability problems!
By the fact no one is requiring you to register your program name with
an IANA type group you can still have pure chaos.
Exactly! That's why the "built-in subsystem" feature is a wart!
There's no way to enforce implementations to honour the registered
names!
Without the "built-in subsystem" feature the expectations set by the
design are completely different and already well understood and handled
by not only SSH-v1 implementations, but indeed by most other generic
remote transport protocols (well, except maybe SSL which has an alarming
number of TCP port numbers assigned to it -- one for every SSL-wrapped
service).
I write a program call
'Foo' that uses SSH to call 'Bar'. You write a program call 'Bar' and
install it and it happens to fall before my program in the path. Thus,
chaos.
Fortunately most everyone's been dealing with this single level of
naming and its consequences for decades now and we have the solutions
down pat.
Adding unnecessary forced generic naming indirection is rarely a good
thing. It's nice to have in personal environments (eg. shell aliases
and such, but just ask anyone who uses your shell prompt how much
difficulty they have when faced with someone else's aliases, or vice
versa). A naming indirection scheme is necessary when the underlying
topology is inflexible (eg. IP addresses -- if you move around the
topology you need a new number, so having a constant name is of extreme
benefit).
However in scenarios where the client's expectations of what services
are available are set by its understanding of the host it's about to
connect to, the *lack* of a generic force protocol-level naming
indirection scheme allows the administrator of that host to choose the
name-space entirely, and allows the clients to adjust their use of
command or application names on the server to suite that particular
server. (Eg. "ssh remhost dir" for M$/DOS, or "ssh remhost ls" for
POSIX.) A naming system indirection scheme at this level only adds the
need for totally unnecessary *global* co-ordination and co-operation.
Yes of course names can be defined in the form "[EMAIL PROTECTED]", as
Bill Sommerfeld said in his response to this thread, however that
doesn't ease the problem any at all and still requires a global registry
for unqualified names. All it does is provide an outlet for those who
want to define their own naming scheme -- they won't have to pressure
implementors into providing non-standard names, but as we've seen in
other very similar situations the implementors will still bend the rules
for even the slightest reason.
Just look at the mess that appears on any given segment of the public
Internet w.r.t. TCP and UDP port numbers. Sure there are lots and lots
of people using the registered names for the protocols they are defined
to represent. However there are a very large and very significant
number of people using illegal port numbers (most Unix systems come with
at least one or two by default!). You cannot sit in the middle of the
Internet and pick off random packets from the "wire" and be guaranteed
that the port number specified in the header will have any relation at
all to the contents of the data within the defined mappings by IANA.
Indirection in this case was not necessarily a good idea, and it has not
been anywhere near 100% successful! The only problem in this case was
many people have a harder time using numbers to identify things and so a
common naming scheme was devised to make things easier to remember and
to refer to. Fortunately with command and application names that might
be invoked by remote SSH clients, there's no need for another naming
scheme because they already have memorable names.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: OpenSSH/scp - F-Secure SSH server Problems
[ On Tuesday, March 13, 2001 at 22:20:53 (+0100), Markus Friedl wrote: ]
Subject: Re: OpenSSH/scp - F-Secure SSH server Problems
On Tue, Mar 13, 2001 at 02:20:46PM -0500, Greg A. Woods wrote:
There are a zillion ways on most server-type platforms to do such
indirection without having to integrate it into SSH, not to mention that
almost all of those alternatives would then lead to total independence
of SSH and thus total portability across all generic transport protocols.
sftp _is_ total independeny of SSH and runs portable across
all generic transport protocols.
Well, maybe, but sftp, at least in SSH, currently relies on the
"built-in subsystem" feature.
I'm sure you could rip it out and make it stand alone (eg. work over
rsh), but hmmm... wouldn't doing so also make it independent of the
"built-in subsystem" in SSH? Duh! So yes:
The "built-in subsystem" feature is bad design. It has no business
being directly in the transport protocol. It is an ugly wart.
tell [EMAIL PROTECTED], not me, i don't care.
I tried but the address either you or someone else supplied originally
in this thread contained a typo and my message bounced. :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: OpenSSH/scp - F-Secure SSH server Problems
[ On Tuesday, March 13, 2001 at 22:37:21 (-0600), [EMAIL PROTECTED] wrote: ]
Subject: Re: OpenSSH/scp - F-Secure SSH server Problems
inetd must be ill-thought-out...
CGI/Perl scripts that define out EXTACTLY what binary they want to use
must be ill-thought-out.
inittab must be ill-thought-out.
Do I need to go on? There are more you just need to look around at
a standard POSIX unix install.
Obviously you're missing the point.
That paths to binaries in all of your examples, and more importantly in
all but the inetd case the meaning of the service names, are
*administrator* defined.
The "built-in subsystem" wart on SSH introduces in a naming scheme that
the client and server must agree upon, just as they must agree upon
TCP/UDP port numbers.
At the very minimum a very strict and central naming registry must be
defined if this sillyness has any chance of resulting in inter-operable
implementations.
Correct binary?!? Are you telling me as the ADMIN of my box *I* don't
know where *I* put sftp-server?! Pish-posh.
Ah, I see you've taken my words in completely the opposite way I
intended them.
I mean specifically that without the "built-in subsystem" wart the
administrator of an SSH server, will have complete and total control of
what binary the client executes via either $PATH, chroot, or some other
scheme which controls the interpreter used by sshd for the given
client's connection.
The "built-in subsystem" idea makes sshd into something more like inetd
where you must intuit what an arbitrary client means when it gives you a
very small piece of information (the port number in the case of TCP/UDP,
and the subsystem name in the case of SSH). Now suddenly the client is
totally authoritative in knowing how to name the service it wants
(barring the existance of a strict subsystem naming registry and
associated application protocol definitions).
Without the "built-in subsystem" feature the server is authoritative.
Yes this means that the client may be forced to adjust to a given
server, but this is a far better approach and leads to total
inter-operability. With subsystems any two conflicting groups of
clients using subsystem names without agreeing on what service they
refer to will not be able to inter-operate equally with any given
server.
Or are you suggesting that if OpenBSD connects to Solaris that I should
run a different sftp-server then if Linux connects to Solaris?
IMNSHO that should be up to the client, but restricted by the server
administrator.
What hardcoded path? There is no hardcoded paths for sftp-server in sshd
unless NetBSD botched things (which I doubt). Subsystems are defined in
your sshd_config. How is this configured 'hard coded in the sshd'? Heck
you can do:
subsystem myrenamedsftpserver /path/to/sftp-server
then hack a sftp to launch ssh with 'myrenamedsftpserver' instead of
'sftp'. How is this hardcoded?
OK, not hard-coded in the binary, but only by the installation.
I don't get your arguments. I personally would rather state where system
services are instead of sshd randomly guessing where thing
are.
I agree, but you've missed the fact that the client hard-codes the
service name, leading to either total chaos, or at best IANA mediated
chaos.
Depending on $PATH for critical services *IS* a secure risk. This is one
of the first things drilled into first year Web/CGI developers.
You need to think harder about the total trust and risk relationships
between the SSH client and the server before you worry about $PATH.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: ASCII Files
[ On Saturday, March 10, 2001 at 16:42:52 (-0500), Bob Babcock wrote: ]
Subject: Re: ASCII Files
To be blunt, why are the programs that implement the ssh protocol so stupid?
Ftp solved this problem years ago by making ascii transfers part of the
protocol. Apparently ssh doesn't do this, but that doesn't stop an ssh
program from doing the trivial line termination translations when it sends a
file. All that would be needed are commands or checkboxes for, say,
"binary", "to-unix", "to-dos" and "to-mac". Auto-sensing is a little harder,
and I don't know if an ssh program can tell what OS is running on the other
end.
Well, to be blunt the file transfer protocol and programs are absolutely
NO place to put conversion routines. Do them right once in a proper set
of utilities for each relevant platform and be done with it
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: OpenSSH/scp - F-Secure SSH server Problems
[ On Tuesday, March 6, 2001 at 18:47:10 (-0500), Davis, Ricardo C. wrote: ]
Subject: OpenSSH/scp - F-Secure SSH server Problems
Is there some know problem between the 'scp' client in OpenSSH 2.5.1p1 and
F-Secure's SSH 2.4.0 server? The client is running on a Linux (2.2.17) box
and server is running on Win2K. When I try to transfer files it asks me for
the password (which I provide) then it hangs. Using 'scp -v' didn't provide
any helpful info; it's as though the problem happened before the
authentication completed. I've looked through both the openssh-unix-dev and
secure-shell list archives and I haven't seen any issue between the two.
OpenSSH does not yet seem to implement server support for SSH-v2.4's
"scp" which now, for reasons that mystify me greatly, seems to now
depend on sftp on the server side.
However I have not had any trouble with any OpenSSH client "scp" talking
to an SSH-2.4 server.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: OpenSSH/scp - F-Secure SSH server Problems
[ On Sunday, March 11, 2001 at 12:06:51 (+0100), Markus Friedl wrote: ]
Subject: Re: OpenSSH/scp - F-Secure SSH server Problems
On Sun, Mar 11, 2001 at 12:21:47AM -0500, Greg A. Woods wrote:
OpenSSH does not yet seem to implement server support for SSH-v2.4's
"scp" which now, for reasons that mystify me greatly, seems to now
depend on sftp on the server side.
However I have not had any trouble with any OpenSSH client "scp" talking
to an SSH-2.4 server.
you could install openssh's scp on the server then scp works
from the openssh client.
But that's the part that works already. It's SSH-2.4.0 client scp to
OpenSSH server that doesn't work (and which needs sftp server-side
support).
(I don't really understand why rcp over ssh wasn't sufficient and why
SSH-2.4.0 now uses the sftp gunge to implement scp, but perhaps there's
a reasonable reason)
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: ASCII Files
[ On Sunday, March 11, 2001 at 14:20:05 (-0500), Blue Lang wrote: ] Subject: Re: ASCII Files There is no reason not to include these kinds of routines in ssh, except for the fact that sftp is not, in any sense, an ftp client. It is an interactive wrapper around scp. Actually it's the other way around now in SSH-2.4.0 -- scp is more of a wrapper around sftp (though it's not exactly that). If someone wanted to write this functionality into scp, that would be great. I suggest doing it in open.. IMNSHO anyone who even considers doing such a thing should not be allowed to write code -- that's the totally wrong approach. As has already been said, any file transfer program, and in particular any file transfer protocol, should *NEVER* be allowed to alter the contents of any file. Furthermore it's much better do build one correct tool to do data conversions than to spread similar functionality amongst any number of other tools where it can only rot and/or diverge. Just because FTP did it doesn't mean it was the right way to do it (or even a good way to do it). Mistakes are best left in the past. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
RE: OpenSSH/scp - F-Secure SSH server Problems
[ On Sunday, March 11, 2001 at 13:37:34 (-0800), Roeland Meyer wrote: ]
Subject: RE: OpenSSH/scp - F-Secure SSH server Problems
I echo your lack of understanding. Sometimes, "if it ain't broke ... don't
fix it" applies and if you *are* going to muck with it, create an
enhancement and leave the, working, original alone.
I know that the "rcp" protocol is rather old and rather poorly
documented (outside the source and the various books that have covered
it in more detail, such as those of the late Mr. Stevens). I don't
quite understand what limitations it might have had w.r.t. SSH though.
It would appear that the sftp stuff is finally documented in the new
IETF secsh draft-ietf-secsh-filexfer-00.txt, published in on or about
Jan 9.
My guess is this is just an excuse to use the "built-in subsystem"
feature bloat in the secsh protocol.
I also don't understand the
fascination folks have for FTP. Anything that uses non-deterministic
dynamically reassigned ports is fundimentally insecurable.
In this case (i.e. in the case of wanting to "ftp" over SSH) the issue
is with the stupid user interface. Naive users are looking for some SSH
file copying tool that works just like their FTP clients, i.e. where
they can see a list of files on the server and click/drag/whatever them
to effect the copy.
If you've looked at the SSH-2.4.0 sftp client on Unix you can only laugh
at it, but I would guess (not having seen one) that an sftp client on
M$-Winblows (or Mac-OS) would be something more touchy-feely-GUI and it
will no doubt make the users much happier than they would be with the
likes of this:
ssh remhost ls -l /some/dir
scp remhost:/some/dir/some.file .
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Block scp, allow ssh? (now way off topic)
[ On Thursday, March 8, 2001 at 09:54:50 (-0600), Michael R. Jinks wrote: ] Subject: Re: Block scp, allow ssh? (now way off topic) Given the sophisication of network monitoring tools these days, I'm going to ask how you'd do this. On the one hand I agree that the company in question is trying to do something awfully impractical and maybe pointless (if it's that important I'll just Xerox it and walk it out in my trouser leg ten pages at a time... Is security going to pat me down as I leave every day?). But if they really are willing to take this so far as monitoring for anything encrypted and squashing it, how would one get around that? Well, maybe, but given that most idiots are still using proprietary software that they don't have a clue about, even the most sophisticated monitoring tools won't likely be used in any intelligent way, so even a well thought out security policy (of which there are hardly any) won't be implemented in reality. Steganography? And then you _really_ look like you're trying to do something nasty even if you're really just trying to protect mail to your wife and your stock broker. Well, when it comes down to Spy vs. Spy, any number of measures and counter measures are possible, including not making use of most information you might learn, just as the Allies supposedly didn't make use of much of the Enigma traffic they decoded during WWW-II. However depending on the nature of what you're trying to communicate, covert channels can avoid even the most sophisticated monitoring tools. It all depends on the ratio of secret to non-secret traffic you've got to send (and how much you might be able to spoof other senders of non-secret traffic from inside your network). Heck you can even use DNS as a covert channel! I second the opinion that this comes down to who you trust -- employees or strangers. Inside jobs constitute a majority of known security compromises recently (and probably forever), but the way around that is not to forbid secure communication, that just leads to bad will. and if you forbid secure communications then you cause people to seek all manner of work-arounds I'm curious to know what is so important that it must be protected by these measures, and whether there might be some better way of doing it than at the network protocol level, which strikes me as clumsy and obviously has significant drawbacks that have nothing to do with protecting the company. even if you have enormous secrets to protect, if you've got a more or less general purpose Internet connection then forbidding secure communications is like asking for your employees to walk out with all your secrets by whatever means they can I.e. the only way to prevent covert channels over a general purpose Internet connection is to cut the cable. :-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Block scp, allow ssh? (slightly off topic)
[ On Wednesday, March 7, 2001 at 13:37:30 (-0600), Michael R. Jinks wrote: ] Subject: Re: Block scp, allow ssh? (slightly off topic) As I read the post, they don't expect to stop file transfers, only hidden ones -- they want to be able to monitor all of the traffic across their firewall (even if that means attackers can easily do so as well). The only way to stop *hidden* file transfers is to cut the cable. Period. There are an infinite number of possible covert channels over a general purpose Internet connection. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
weird interoperability problems between SSH-2.4.0 and OpenSSH-2.2.0/NetBSD
I'm having trouble with interoperability between SSH-2.4.0 and
OpenSSH-2.2.0 as it appears in NetBSD-1.5.1, aka
NetBSD_Secure_Shell-20001003:
21:23 [104] $ ssh2 -v -m hmac-sha1 whome.planix.com
debug: hostname is 'whome.planix.com'.
debug: Unable to open /home/most/woods/.ssh2/ssh2_config
debug: connecting to whome.planix.com...
debug: entering event loop
debug: ssh_client_wrap: creating transport protocol
debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize:
Added "hostbased" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize:
Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize:
Added "password" to usable methods.
debug: Ssh2Client/sshclient.c:1142/ssh_client_wrap: creating userauth protocol
debug: Ssh2Common/sshcommon.c:502/ssh_common_wrap: local ip = 204.92.254.15, local
port = 51951
debug: Ssh2Common/sshcommon.c:504/ssh_common_wrap: remote ip = 204.29.161.33, remote
port = 22
debug: SshConnection/sshconn.c:1866/ssh_conn_wrap: Wrapping...
debug: Ssh2Transport/trcommon.c:599/ssh_tr_input_version: Remote version:
SSH-1.99-OpenSSH_2.2.0 NetBSD_Secure_Shell-20001003
debug: Ssh2Transport/trcommon.c:789/ssh_tr_input_version: Remote version has rekey
incompatibility bug.
debug: Ssh2Transport/trcommon.c:1120/ssh_tr_negotiate: c_to_s: cipher 3des-cbc, mac
hmac-sha1, compression none
debug: Ssh2Transport/trcommon.c:1123/ssh_tr_negotiate: s_to_c: cipher 3des-cbc, mac
hmac-sha1, compression none
debug: Ssh2Client/sshclient.c:406/keycheck_key_match: Host key found from database.
debug: Ssh2Common/sshcommon.c:137/ssh_common_disconnect: DISCONNECT received: Message
authentication check fails.
warning: Authentication failed.
debug: Ssh2/ssh2.c:85/client_disconnect: locally_generated = TRUE
Disconnected; MAC error (Message authentication check fails.).
debug: uninitializing event loop
Feb 20 21:38:11 whome sshd[18858]: Disconnecting: Corrupted HMAC on input.
If I change the MAC to hmac-md5, it works:
21:56 [105] $ ssh2 -v -m hmac-md5 whome.planix.com
debug: hostname is 'whome.planix.com'.
debug: Unable to open /home/most/woods/.ssh2/ssh2_config
debug: connecting to whome.planix.com...
debug: entering event loop
debug: ssh_client_wrap: creating transport protocol
debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize:
Added "hostbased" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize:
Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize:
Added "password" to usable methods.
debug: Ssh2Client/sshclient.c:1142/ssh_client_wrap: creating userauth protocol
debug: Ssh2Common/sshcommon.c:502/ssh_common_wrap: local ip = 204.92.254.15, local
port = 51896
debug: Ssh2Common/sshcommon.c:504/ssh_common_wrap: remote ip = 204.29.161.33, remote
port = 22
debug: SshConnection/sshconn.c:1866/ssh_conn_wrap: Wrapping...
debug: Ssh2Transport/trcommon.c:599/ssh_tr_input_version: Remote version:
SSH-1.99-OpenSSH_2.2.0 NetBSD_Secure_Shell-20001003
debug: Ssh2Transport/trcommon.c:789/ssh_tr_input_version: Remote version has rekey
incompatibility bug.
debug: Ssh2Transport/trcommon.c:1120/ssh_tr_negotiate: c_to_s: cipher 3des-cbc, mac
hmac-md5, compression none
debug: Ssh2Transport/trcommon.c:1123/ssh_tr_negotiate: s_to_c: cipher 3des-cbc, mac
hmac-md5, compression none
debug: Ssh2Client/sshclient.c:406/keycheck_key_match: Host key found from database.
debug: Ssh2Common/sshcommon.c:306/ssh_common_special: Received SSH_CROSS_STARTUP
packet from connection protocol.
debug: Ssh2Common/sshcommon.c:356/ssh_common_special: Received SSH_CROSS_ALGORITHMS
packet from connection protocol.
debug: Unable to open /home/most/woods/.ssh2/identification
debug: Ssh2AuthClient/sshauthc.c:309/ssh_authc_completion_proc: Method 'publickey'
disabled.
debug: Ssh2AuthPasswdClient/authc-passwd.c:92/ssh_client_auth_passwd: Starting
password query...
[EMAIL PROTECTED]'s password:
I see the following note in the CHANGES file which would seem to hint
that the problem I'm encountering was fixed long ago:
2000-11-27 Sami J. Lehtinen [EMAIL PROTECTED]
[[ ]]
* Fixed SHA-1 key length. Now we are compatible with OpenSSH and
the new drafts.
Is this a NetBSD problem, an OpenSSH problem, or what?
(Next I'm off to find out why SSH-2.4.0's sshd crashes when I try to
connect to it from NetBSD's ssh)
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
libwrap configure.in tests still broken after all these years (in SSH-2.4.0)
DENCIES = $(DEPENDENCIES) ! ssh2_LDADD = @PAM_CLIENT_LIBS@ $(LDADD) @LIBWRAP_LIB@ ssh2_LDFLAGS = -o $@ sshd2_SOURCES = sshd2.c sshd2_DEPENDENCIES = $(DEPENDENCIES) ! sshd2_LDADD = @PAM_DAEMON_LIBS@ $(LDADD) @LIBWRAP_LIB@ sshd2_LDFLAGS = -o $@ ssh_agent2_SOURCES = ssh-agent2.c *** *** 409,415 # defines ! SSH_DEFS = -DETCDIR=\"$(etcdir)\" -DSSH_BINDIR=\"$(bindir)\" COMPILE = $(CC) $(KERBEROS_INCS) $(INCLUDES) $(SSH_DEFS) $(DEFS) $(CPPFLAGS) $(CFLAGS) $(X_CFLAGS) LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) --- 409,415 # defines ! SSH_DEFS = -DETCDIR=\"$(etcdir)\" -DSSH_BINDIR=\"$(bindir)\" @LIBWRAP_INC@ COMPILE = $(CC) $(KERBEROS_INCS) $(INCLUDES) $(SSH_DEFS) $(DEFS) $(CPPFLAGS) $(CFLAGS) $(X_CFLAGS) LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Can SSH be used just for encrypted authentication and then let the rest of the session be unencrypted ?
[ On Thursday, February 1, 2001 at 11:45:57 (+0100), Andreas Schott wrote: ] Subject: Re: Can SSH be used just for encrypted authentication and then let the rest of the session be unencrypted ? This is a very useful thing for backup/recovery, where we e.g. use the rsh-protocol and would like to switch to ssh, but it is impossible to encrypt/decrypt gigabytes of data. You are far Far FAR safer to just use 'rsh' than to try disabling the encryption in 'ssh' under some misguided attempt to gain better performance. 'ssh' without data link encryption is, for all intents and purposes, exactly the same as 'rsh' (though perhaps with the addition of other more complex authentication algorithms that you'd find difficult to use in an automated script environment anyway!). Properly configured, with regular auditing, and with properly configured and reliable local authoritative DNS servers for all domains concerned, especially for the reverse zones, 'rsh' is probably *more* secure than 'ssh' would be without data transport encryption because if you mess with 'ssh' you may risk reducing it's ability to protect other more sensitive connections. Even if you did have secure methods for using stronger authentication in an un-encrypted 'ssh' bastardisation you still wouldn't be any better off than 'rsh' because it couldn't tell you anything that 'rsh' can't tell you in the first place (unless of course you've broken 'rsh' by allowing unprivileged user processes to bind to reserved ports or something equally silly). Furthermore it is on an internal network, so snooping data is never the problem, but as long as rsh is an allowed protocol, you need to rely on other methods to avoid usage of rsh for other things, than just the backup/restore. So it is a very useful thing to encrypt only the authentication. Encrypting only the authentication leaves your connections *wide* open to hijacking, *especially* within an internal network! In this case 'rsh' is no less secure and the rsh authetication is based on out-of-band information (which hopefully comes from an authoriative nameserver running on both the server and client, and of course from secure user-id databases on each). Do not even contemplate removing the data link encryption from 'ssh'. Use existing, proven, non-encrypted protocols instead, such as 'rsh'. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
RE: Can SSH be used just for encrypted authentication and then let the rest of the session be unencrypted ?
[ On Wednesday, January 31, 2001 at 13:49:41 ( -0500), Ng, Kenneth (US) wrote: ] Subject: RE: Can SSH be used just for encrypted authentication and then let the rest of the session be unencrypted ? Sometimes you want the authentications encrypted to prevent outsiders from getting the passwords, but the actual data itself is considered not sensitive. Or your using public key exchange to authenticate, but the data is not sensitive. Being able to turn off the encryption would be nice when you have to move gigabytes across a LAN inside of the allowed backup time window. What I've done when I needed to do this is to lower the encryption strength to use blowfish instead of IDEA or 3DES. I've doubled throughput by doing this. Ah, but if your session authentication parameters are sensitive then the data stream is sensitive, by definition. If you were to run the rest of the session in a clear TCP channel then you would risk it being hijacked, and at that point you may as well not even have a password or any other kind of authentication because they hijacker is going to have his way with your remote session anyway. TCP circuit hijacking is almost kid's play these days. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: autologin considered harmful?
[ On Tuesday, November 21, 2000 at 14:52:59 (+1100), Jeff Turner wrote: ] Subject: Re: autologin considered harmful? So the only thing a sysadmin can really do is make sure that users can't hurt the system EVER. That's a laudable goal, but achieving it is practically impossible to achieve 100% in current system, especially if your job is to also protect users from each other to some degree. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: ssh tunnelling over ssh ?
[ On Tuesday, November 21, 2000 at 13:46:48 (-0800), Carson Gaspar wrote: ]
Subject: Re: ssh tunnelling over ssh ?
--On Saturday, November 18, 2000 12:33 PM -0500 "Greg A. Woods"
[EMAIL PROTECTED] wrote:
Sorry, no, that's not the only case by far. In the common way SSH is
use the other, and far more important, case is when the initial
connection is made. If a rogue server process could open and listen on
the default port (say there was no sshd running, or there was some bug
that could trigger the crash of the real one) then it could hand hout a
bogus host key on the *initial* handshake. An unsuspecting user could
connect to a server for the first time and be tricked into accepting a
bogus key.
Once again - we're talking about requiring the _client_ to use a
priveledged port, not the server. Please comment appropriately.
No, I'm not talking about the client -- I'm talking explicitly about the
server needing to use a priviledged port in order that the client can
trust it *BEFORE* a valid host key association has been established.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: autologin considered harmful?
[ On Monday, November 20, 2000 at 09:07:47 (-0600), Dave Dykstra wrote: ]
Subject: Re: autologin considered harmful?
A very smart security expert successfully pursuaded me that if a user's
machine is compromised, all bets are off. It makes no difference whether
you use passwords/passphrases or not, the cracker can still get in to the
server. The vital thing is to secure the user's machine, not introduce
artificial barriers that don't make any difference anyway.
Exactly!
A good article that discusses the fallacy of trusted client software
more generally is Schneier's Crypo-Gram article (an updated version also
appeared in Aug. 2000 "Information Security" trade rag, p. 20):
URL:http://www.counterpane.com/crypto-gram-0005.html
(search for "trusted client software")
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: ssh tunnelling over ssh ?
[ On Wednesday, November 15, 2000 at 15:54:07 (-0800), Carson Gaspar wrote: ] Subject: Re: ssh tunnelling over ssh ? Requiring a priveledged port on the server adds _no_ security and is a bad idea. I added an option to turn that silly requirement off. That's not necessarily true, at least not in all situations. Requiring that the server listen on a privileged port helps ensure, at least in a configuration where the hosts are truly trusted (but the users on those hosts may not be trusted 100% -- after all they don't have the root password), that the server process was started by a privileged user. This applies directly to SSH and is in fact could be viewed as a critical requirement with SSH on a multi-user system. In some scenarios where the local network wire is also trusted one can even use the fact that the client connected from a trusted port to know that the information passed by the client is in effect authenticated. This also applies to SSH since it is this fact which corroberates the authenticity of the client's host key by implying that it was done by a privileged process capable of reading the protected host key. None of this matters so much once the first handshake is done, or if some other means of public key distribution is done, but for the initial handshake under default configurations this is still somewhat important since it's really the only assurance that the key being offered is trustworthy. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Mandrake ssh security alert
[ On Thursday, October 12, 2000 at 10:00:10 (-0600), dreamwvr wrote: ]
Subject: Re: Mandrake ssh security alert
Actually any version of ssh 1.2 or less as well as openssh 1.21 or less..
Indeed, but the really important thing to remember is that doing
*anything* with a compromised server, let alone SSH'ing into it, is very
risky business indeed.
If you have some automated job running "scp" or "ssh" and you don't have
good strong intrusion detection facilities to protect the server (which
would make it at least possible to stop the automated job before it
allowed any propogation of the attack) then you're taking massive risks
already.
Any SSH server trusting a compromised client is in even worse shape, and
if you agree with Bruce Schneier (or me! ;-) then you'll know there is
no such thing as "trusted client software"! :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Automating sftp with UNIX scripts
[ On Wednesday, October 4, 2000 at 12:57:54 (-0400), Ruiyuan Jiang wrote: ]
Subject: Automating sftp with UNIX scripts
I want to automate sftp session to get and put files on the ssh2
server through such as cron job. Is this possible to use sftp2? I
tried to write a script much similar as regular ftp scripts to
automatically get and put files on the ftp server without human
interaction but failed. Does anyone know how? Thanks in advance.
Sftp is a stupid (and mostly unnecessary) hack to keep people who only
understand the `ftp' user interface happy (it's not using the FTP
protocol underneath/through SSH, after all).
Why don't you just use "scp"? It's easily automatable in scripts since
its user interface is really not that much different (at least in
philosophy) from "cp" itself!
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: SSH grants free license for SSH Secure Shell for Universities
[ On Wednesday, March 1, 2000 at 23:21:09 (EST), Jeffrey Altman wrote: ]
Subject: Re: SSH grants free license for SSH Secure Shell for Universities
In short, SSH grants universities around the world a free right to use
SSH Secure Shell free of charge within their organization for
non-commercial use. This includes both Windows and Unix versions.
Please be very specific with your definition of "non-commercial use"
in your license.
Indeed! You might also want to make inquiries to a legal authority who
is unbiased and knowlegable of copyright laws in other jurisdictions.
It is quite possible your "non-commercial use" license is no more worthy
than a shrink-wrap trade secret license in some places.
I.e. in some jursidictions it would appear to still be impossible to
enforce a "no-commercial-use" license under the copyright law if the
software in question is freely distributed, and especially if it is
freely re-distributable. The copyright law would seem to be intended to
protect how a work is published and distributed, not how legally
obtained copies are used by their legal owners.
If you want to control how your software is actually used (i.e. as
opposed to the way the word "use" is meant in copyright law) then you
have to enter into individual binding contracts with every user you
provide your software to. Anything freely redistributable obviously
cannot be controlled by individual legally binding contracts.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: sftp
[ On Tuesday, October 12, 1999 at 09:39:52 (-0400), Charles Karney wrote: ] Subject: Re: sftp Of course it is sometimes programs that have difficulty learning and adapting! True enough. However except for rare exceptions FTP has been difficult to use programmatically anyway But, unfortunately, the current implementation of sftp is completely useless for interfacing to other programs. (The last version I tries was 2.0.12. I think the same applies to 2.0.13.) Case in point: sftp with ange-ftp in Emacs. As I understand it there's no need to use FTP with Emacs -- you should be able to use scp as an rcp replacement, and from what I've been told (and what I've read in various forums), Emacs will be quite happy with it (I don't use ange-ftp -- it rather annoys me far too much! ;-). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: sftp
[ On , October 8, 1999 at 04:39:17 (-0700), Harry Putnam wrote: ]
Subject: Re: sftp
I may have missed the boat here. I understood 'sftp' to be the secure
ftp client included with SSH-2*.
Yes, that's supposedly the case. As far as I can tell sftp was added
because people claimed they couldn't live without an FTP-like interface
to SSH. Nobody's ever given any concrete evidence of this fact to the
best of my knowledge though.
My understanding was that 'sftp' did all the things you mention above.
SSH-1.27 has "scp", which does many of the things an ftp client does
but not all. I thought 'sftp' would fill in the rest.
I cannot imagine anything that ssh and scp can't do together that any
Unix-style FTP client can do (with the exception of perhaps specialised
things like re-starting a failed transfer -- something that ssh and scp
couldn't do without additional lines of shell script assisting them).
In fact for anyone already accustomed to using simple shell scripts and
commands like 'cp', ssh scp can do infinitely more than any normal FTP
client can on its own.
I think sftp is simply for people who's ability to learn and adapt has
been somehow lost or turned off or something! ;-) Otherwise it was
just a waste of a "small matter of programming."
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: ssh mailing list archives
[ On Thursday, March 25, 1999 at 14:11:03 (-0800), Steve Acheson wrote: ]
Subject: Re: ssh mailing list archives
If you look in the FAQ, it has three locations for mailing list
archives:
http://www.cs.hut.fi/ssh/ssh-archive
http://www.egroups.com/list/ssh/info.html
http://www.progressive-comp.com/Lists/?l=secure-shellr=1w=2#secure-shell
Steve
FAQ: http://www.employees.org/~satch/ssh/faq
Unfortunately no matter how complete and informative your FAQ is (and it
is really very good!) it's currently not in the most obvious place, and
many of the most obvious web pages related to SSH don't contain links to
it (ssh.fi and ssh.org will remain nameless, and I won't even mention
www.cs.hut.fi/ssh ;-).
I did a test query for "ssh faq" on hotbot.com and didn't have much luck
either
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: ssh mailing list archives
[ On Friday, March 26, 1999 at 12:49:12 (-0800), Steve Acheson wrote: ]
Subject: Re: ssh mailing list archives
Unfortunately no matter how complete and informative your FAQ is (and it
is really very good!) it's currently not in the most obvious place, and
many of the most obvious web pages related to SSH don't contain links to
it (ssh.fi and ssh.org will remain nameless, and I won't even mention
www.cs.hut.fi/ssh ;-).
Good point, of course. Any suggestions on getting into the
"appropriate places"?
Sorry, I meant to direct that remark more to the SSH folks than to you.
I suspect though that they're not really interested in pointing people
at external sources of information, or they would already have done so.
I did a test query for "ssh faq" on hotbot.com and didn't have much luck
either
I suppose I could go register with one of them somewhere?
I was almost wondering if employees.org had web-crawler/robot inhibitors
or something
I tried "SSHFAQ" on hotbot again, and that was much more successful,
with only two results, your URL on top, but unfortunately without
knowing that this might be a unique keyword from having seen a copy it's
unlikley many people would use only one word for such a search.
I tried "ssh faq" again and this time your URL came up 19 (out of
5,800!). Perhaps it rose up because I had clicked on it (they do
click-through accounting now). AltaVista found only 383, but your URL
didn't appear within the first 20 pages. For "SSH FAQ" AltaVista's
first choice is for the "Soap, Sundry Herb FAQ", believe it or not.
Unfortunately the old URL, and mirrors of it still show up an awful lot,
and there's no indication in the old copy that there's a much newer and
more relevant one available elsewhere.
The comp.security.ssh FAQ as recorded in most FAQ archives also seems to
be the old one.
I don't know too much about registering for search engines, but I think
it might be a good idea to try and update all the FAQ archives
(particularly faqs.org and of course cis.ohio-state.edu), and/or perhaps
even to do a monthly posting of the ASCII FAQ to comp.security.ssh.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: transfering files back along an existing connection
[ On Friday, February 12, 1999 at 11:42:03 (-0600), Dave Dykstra wrote: ] Subject: Re: transfering files back along an existing connection I understand Greg's and Steve's points and agree with them, but when I am forced to use ssh on an unsecured client I still feel more comfortable using off-board hardware authentication because it at least limits the kinds of attacks that can be done and it limits vulnerability to attacks that occurred before or during its use and leaves nothing like a private key around to be exploited later. Not much, but better than nothing. I know several people who carry around FreeBSD or Linux boot floppies with SSH on them, and this would be my preferred solution too if I were stuck with such a situation. The trick here is preparing for this scenario. I trust the average office and datacentre hardware a lot more than I trust any foreign software. Last time I was at a conference terminal room I was able to poke around on the machines enough to be reasonably sure they hadn't been hacked, and that the ssh installation was pristine, and indeed the person who had configured the machines was willing to give strong assurances too. The time before that I was volunteering in the conference room and I personally audited the machines and installed SSH, more for my own use than for anyone else, as at that time not so many users at that particular conference were already using SSH. It's really too bad sshd doesn't have an option to reject unknown hosts -- i.e. force users to obtain a valid public key for a host before they are allowed to login from it and optionally to ignore ~/.ssh/known_hosts completely. Somewhere I've a wish-list of such features for SSH, but I'd been putting off doing anything about it waiting to see which implementation of ssh2 would be the primary one I use For now I just use a pretty vanilla ssh1. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: transfering files back along an existing connection
[ On Wednesday, February 3, 1999 at 20:19:16 (-0800), Joe Rhett wrote: ]
Subject: Re: transfering files back along an existing connection
If I am using a one-time hardware-based authentication mechansim, how
exactly would the root user of this untrusted host do anything I wouldn't
like, other than decrypting what I type/read? (we don't do much more than
read mail and update source files)
Well, depending on exactly what the client machine consists of, and what
software and firmware it runs, the possiblities are *endless*.
The simplest example would be the installation of a trojan horse inside
your trusted network using your authenticated channel (and hiding the
covert activity, of course).
Auditing *might* catch such covert activities, but since you've only
your human brain at the client end to create corresponding audit logs
with, only the most inquisitive analysis of audit logs on the trusted
side might reveal truely covert activities, and of course since there's
no way for you to provide secure audit logs on the client side to
corroberate your activities, about the best you can hope for is that you
do not get implicated as an accomplice.
The people who work remotely are aware that the encryption can be
compromised on the host they are on, and don't do things like copy secret
keys around. The strong authentication prevents another session from being
opened by anyone else then or later. :-)
Losing secrets are the least of your problems. The real issue is that
you've opened a fully authenticated and authorized covert channel (or
multiples if you consider SSH's ability to tunnel connections!) for the
untrusted client machine to do with what it pleases, and to do so
completely without your knowledge.
The higher the risk level, and the stronger the authentication you use,
and the deeper you dive into your "trusted" home network, the more value
any threat might perceive for using the covert channel you've oppend for
them. Their risk may be relatively low compared with the immediate
pay-back they may profit from. Just because you know better than to
copy secret keys around doesn't mean the covert channel user will be
prevented from doing so.
If you really must trust a client's hardware and operating systems then
you may as well simply go all the way and trust them to keep your RSA
private key safe for the duration of your visit. You need only wipe out
their host keys (and perhaps your personal RSA keys for that site) just
before you get ready to leave (after which point at worst they'll be
forced to learn your password to make any use of the key copies they may
have retained without your authorization). Turning off
PasswordAuthentication will prevent even this, though doing so may imply
that you'll have to carry your personal RSA private key with you in
order to make the initial trusted connection.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: How do I sz/rz under an ssh connection?
[ On Sat, January 23, 1999 at 11:40:39 (+0200), Sami Lehtinen wrote: ]
Subject: Re: How do I sz/rz under an ssh connection?
In this case you would do the connection like this
% ssh -L 2:remote_host:1 remote_host
if I understood you correctly.
That's what I thought, but when I tried it I ended up only with a login
session on the remote_host. The same happened with -R. I did't see
anything listening on either port on either system in either case.
However I'd been doing my tests with an out-of-date ~/.ssh/known_hosts
file, and I wasn't reading the warning message that said: "Local port
forwarding is disabled to avoid attacks by corrupted servers."
Now that I've updated my known_hosts file, everything's working fine!
Thanks!
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: How do I sz/rz under an ssh connection?
[ On Thu, January 21, 1999 at 16:07:25 (-0800), Joe Rhett wrote: ]
Subject: Re: How do I sz/rz under an ssh connection?
Wow. Who needs functionality when almighty arrogance will do instead?
You miss the point. Every single one of your examples forces me to log out,
transfer the files I want, then log back in again.
Wait a minute here. If you have to "log out and log back in again"
around each transfer then you're doing something wrong. SSH, like rsh
before it, and even FTP, works perfectly fine, in parallel with your
current login session. It should be possible to invoke it from either
end (though if Unix is at one end and not the other there may be some
advantage to invoking it at that end all the time).
This should all be possible even if you're connected to your local
computer with a "dumb" terminal. Of course if you've got any kind of
multi-"window" environment at your "workstation" then you should be able
to have one or more a command-line sessions running on each end (even
with multiple slogin connections!), and life will be even more exciting
and versatile (and of course this kind of environment can be emulated
using job control or tools such as screen on Unix clients).
SSH is a _network_ tool, not a modem tool. It need not be restricted to
opening one connection at a time or even to transfering one file at a
time (that's just a limitation of bandwidth and latency).
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Long term viability of SSH, will there be a free SSH 2?
[ On Fri, January 22, 1999 at 08:10:41 (+), Michael wrote: ]
Subject: Re: Long term viability of SSH, will there be a free SSH 2?
I don't think so. The author of one of the best, TTSSH, has already
said he considers the effort too great to support 2.xx
That's not a very good answer or attitude. The 1.x protocol was purely
experimental, and is inadequate for long-term real-world use. There
probably wouldn't even be a 2.x protocol design if 1.x was OK.
The liscensing for 2.0 clearly needs to change if it is to be
supported in the long term by the "open" community
That would be nice, but it won't matter much so long as we have at least
one good "open" implementation of the final IETF sanctioned protocol,
and it seems that will be the case, and it'll happen sooner if some of
us stop being lazy and put some effort into supporting those
implementations of 2.x that are already proceeding and/or writing our
own implementations.
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: How do I sz/rz under an ssh connection?
[ On Fri, January 22, 1999 at 13:17:45 (EST), Jeffrey Altman wrote: ]
Subject: Re: How do I sz/rz under an ssh connection?
Besides, ssh is supposed to be able to replace rlogin and I can use
Kermit to make a 'login' connection using the sub-process mechanism in
C-Kermit to start rlogin.
Using kermit with rlogin is just as silly as using kermit with ssh.
Both "scp/ssh" and "rcp/rsh" are prefectly adequate and sufficiently
*complete* user interfaces to their respective file transfer and remote
job submission protocols.
Using SSH to tunnel a kermit connection, while rather bizzare and
unnecessary and possibly even counter-productive thing to do, has the
effect that one need only enter one's authentication once, and
guarantees that all data passed over the network by kermit will be
encrypted. Using "ssh" as the communications channel for kermit would
do the same, but seems even less logical thing for an SSH user to do
since SSH should already do everything they need to do.
(I still don't see how, from either the manual page or the on-line help,
that I can even tell kermit to popen("ssh") and use that as the
communications channel.)
In any case, why don't you post patches to SSH that allow it to work
without a controlling terminal when it doesn't need to request a
password from the user? (or perhaps you or someone else has and I
missed seeing them...)
Alternately why don't you change kermit so that it has all the smarts
about how to invoke ssh with appropriate port forwarding so that the
user need only "SET NETWORK TYPE SSH" and "CONNECT"?
Even better why not implement the SSH-v2 protocol right in Kermit and it
could be the SSH client of choice for the masses?
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: How do I sz/rz under an ssh connection?
[ On Mon, January 18, 1999 at 15:25:39 (EST), Jeffrey Altman wrote: ]
Subject: Re: How do I sz/rz under an ssh connection?
want to. But for the rest of us who are used to typing
kermit -s file
kermit -g file
sz file
it is perfectly okay for us to continue doing so.
I know that kermit can work well and transparently through an existing
SSH "login" session (though I suspect the buffering parameters might
best be tuned carefully to attain the best throughput and to prevent
thrashing against the windowing of SSH and TCP/IP). I think I was
careful not to mention kermit as one of those "silly redundant
protocols", though to some extent the implication was there and was
intended.
It seems that trying to use rz/sz over SSH is much harder than using
kermit, but then that's always been the case no matter what the
communications path! ;-)
However what you've said fits right in with what I was saying about how
people can get fixated on the old paradigms that might have been imposed
on them by tools that they once used and not break out of their shells
and make use of the much wider variety of tools that are available to
them in new environments. Using some "old-fashioned" file transfer
protocol intended originally for use over dedicated and often unreliable
connections (such as modems, serial cables, etc.) is one such fixation.
That said, it would be nice if kermit could make use of SSH tunnels
though (I looked briefly at C-Kermit 6.0(192) but couldn't see a way to
do that...) such as in the same way one might use rdist over SSH (in
which case kermit could automatically treat the tunnel as a plain old
highly reliable pipe and not bother to do any protocol goop).
--
Greg A. Woods
+1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods
Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
