Re: SCP/SFTP functionality
On Wed, 30 Apr 2008 14:06:26 -0500, Stephen Frazier [EMAIL PROTECTED] us wrote: That will never get past an auditor who has read about but doesn't under stand REXEC. :) David Boyes wrote: Move his files to SFS, export the SFS directory via NFS to a Linux guest, and configure REXEC on the Linux guest via a private guest LAN that is not connected to external network to allow him to remotely execute SCP on Linux from CMS. Done. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us = == == If FTP makes them freak, REXEC is even worse. I am presented with a document -- the Unix/Linux Security Baseline. No on e I have met yet really understands it. Someone bought a program to snoop around on all servers l ooking for violations. My user is in violation. He knows nothing about VM, he just knows he send s data to a VM userid via FTP, and has been told to stop or use SFTP. I found another document on File Transfer Standards that says FTP over SS L is most preferred. So I pointed out the apparent contradiction. They denied that there is a con tradiction, but someone has been asked to look into revising the Unix/Linux Security Baseline. I guess they get to consider the question of managing the certificates. This being the Bank, the vario us sloppinesses you all mention are probably against the rules. So maybe somewhere down the road they may decide to take advantage of FTP over SSL. Thanks very much for all the information! I know a lot more than when I s tarted out. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: SCP/SFTP functionality
Excellent summary of the situation by the Man from Endicott. [insert theme music from Man from U.N.C.L.E. here] I recommend a POSIX target for SSH into z/VM. From there, after one has signed on using a name that matches *your* VMID, one can issue CP, CMS, or Pipelines commands by proxy. Full screen remains a challenge, but I truly believe this is the right place to start with the VM SSH solution. I cobbled up something like this at work and my teammates just rave about it! (Well ... not really. Maybe I should say that they make noises about it. OKAY FINE, they complain!) The ability to issue CMS and CP commands by way of SSH is vital. We need that capability *now*. Dave Boyes mentioned the certificatastrophe other protocols present. (Not that you cannot play the cert game with SSH, at least GSSAPI, just that you don't *have to*.) Also, the ability to run a CMS Pipeline with its primary input coming from an SSH client and its primary output going back to that SSH client is a beautiful thing. We will miss a huge opportunity if we do no make this real-time pipelining happen. The POSIX target environment can be either OpenVM or Linux. Either way, it runs in its own service virtual machine. Commands are driven on *your*virtual machine by way of a proxy, an agent. The service environment has XAUTOLOG privileges. Suppose you enter the command cms id and your agent is not listening. The service virtual machine logs you on with a command to launch the agent and then re-tries the command. I use a critter like this regularly. Ahhh... -- R; On Mon, Apr 28, 2008 at 6:27 PM, Alan Altmark [EMAIL PROTECTED] wrote: On Monday, 04/28/2008 at 05:05 EDT, McKown, John [EMAIL PROTECTED] wrote: Why? What is wrong with OpenSSH? Trick question. :-) There is nothing wrong with OpenSSH. But remember that in a VM system, we're talking about virtual machines, not processes. There is no hierarchy of virtual machines. No parent-child or sibling connection, no fork()/exec(),no inheritance of files or file descriptors or sockets. The ssh daemon runs in a virtual machine that is NOT the end user's virtual machine. The daemon can listen for ssh connections, encrypt the session, and even challenge the user for a userid and password. ssh requires implementation of public/private key pairs, too. Troublesome, but not impossible to solve as long as I have a central place for all users' public/private keypairs. lightning flashes Done. I have an ssh interactive session. I have created an LDEV (logical 3270 device) and logged you onto it. I am now getting 3270 traffic from CP. Drats. This session is really intended for native ASCII. OK, forget the LDEV. I'll use (horror!) *CCS and create a linemode session instead, with all the EBCDIC traffic converted to ASCII and some sort of control characters (should I use VT220?) thrown in. Now you want to use x3270. Drats. I'm in line mode. Not to mention the block vs. character mode difference. The guest doesn't see a file descriptor to write stdout and stderr, and read from stdin. It sees a virtual 3215 or 3270. But, ok, let's wave our hands and move past it. another flash of lightning You have a terminal session. You enter scp. It wants to use the ssh tunnel. R'uh r'oh! What tunnel? The tunnel isn't in YOUR virtual machine. There is no socket available to you that represents the tunnel. Drats, drats, and double drats, said Dick Dasterdly to Penelope Pitstop. (I can hear his dog, Muttley, laughing.) The ssh clients are relatively easy since those connections DO originate in the user's virtual machine. You would have to tell the remote system that your console is dumb so that it will just run in easy-to-translate line mode. No VT. No character mode. All of this jabbering to illustrate three things: 1. That OpenSSH isn't the problem. Rather, the basic assumption of the ssh protocol, that the target user process has access to the ssh tunnel, doesn't mesh with how consoles are handled in VM. 2. I understand the seductive desire for ssh, reinforced by misguided or misinformed security experts. 3. We *have* given it some considerable thought. OK, four things: 4. All that thinking makes my head hurt. Alan Altmark z/VM Development IBM Endicott -- -- R;
Re: SCP/SFTP functionality
I don't understand why the Unix/Linux world prefers SFTP to FTPS Implementation of SFTP doesn't require certificate management infrastructure and expensive certificates from external organizations. Ssh is also open source and freely distributed; few if any FTPS clients or servers are. The user's only solution is to stop using z/VM. Move his files to SFS, export the SFS directory via NFS to a Linux guest, and configure REXEC on the Linux guest via a private guest LAN that is not connected to external network to allow him to remotely execute SCP on Linux from CMS. Done.
Re: SCP/SFTP functionality
On Wednesday, 04/30/2008 at 01:20 EDT, David Boyes [EMAIL PROTECTED] wrote: I don't understand why the Unix/Linux world prefers SFTP to FTPS Implementation of SFTP doesn't require certificate management infrastructure and expensive certificates from external organizations. Ssh is also open source and freely distributed; few if any FTPS clients or servers are. No certificate management? Feh. You are responsible to adhere to your company's policy regarding certificates. Old or ill-managed certificates are just as dangerous as old or ill-managed passwords. Alan Altmark z/VM Development IBM Endicott
Re: SCP/SFTP functionality
Implementation of SFTP doesn't require certificate management infrastructure and expensive certificates from external organizations. Ssh is also open source and freely distributed; few if any FTPS clients or servers are. No certificate management? Feh. You are responsible to adhere to your company's policy regarding certificates. Old or ill-managed certificates are just as dangerous as old or ill-managed passwords. No argument there -- opportunities for stupidity are as ubiquitous as FORTRAN-like coding styles. Alan Ackerman asked why SSH and SFTP are so successful in the Unix world. SSH doesn't *require* a CA or other certificate management widgets *at all*. It doesn't *require* distribution of certificates before it can be useful. It doesn't *require* generation of certificates by anyone. It doesn't *require* paying for individual host certificates for every host you want to secure. It doesn't *require* figuring out what approved vendors are in the default root certificate list on operating system X, Y or Z and how to integrate your certificate into that infrastructure if it's not included. It doesn't cost anything per year to get started. It Just Works out of the box. And it's preloaded in most places that Unix weenies care about -- even on VMS and newer versions of Windows. How many pages of documentation does it require to explain the setup of SSLSERV, or even to understand what's happening in it? How much is the cheapest enterprise-wise certificate from a company in the default Windows root CA list? The defense rests. Don't get me wrong -- there are places for both. The above is why you don't find FTPS and SSL-wrapped TELNET widely used in the Unix community. Too many moving parts and other stuff needed to get started.
Re: SCP/SFTP functionality
That will never get past an auditor who has read about but doesn't understand REXEC. :) David Boyes wrote: Move his files to SFS, export the SFS directory via NFS to a Linux guest, and configure REXEC on the Linux guest via a private guest LAN that is not connected to external network to allow him to remotely execute SCP on Linux from CMS. Done. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: SCP/SFTP functionality
Why is an SSH daemon absolutely fundamental and prerequisite to a CMS SCP command to move a PDF from my A-disk to one of my linux servers for serving via Apache? It's not. I'm working on porting the PuTTY standalone utilities. They don't require a local SSH server.
Re: SCP/SFTP functionality
Excellent. That product, I might pay for out of my own pocket. /Tom Kern On Tue, 29 Apr 2008 10:46:36 -0400, David Boyes [EMAIL PROTECTED] w rote: Why is an SSH daemon absolutely fundamental and prerequisite to a CMS SCP command to move a PDF from my A-disk to one of my linux servers for serving via Apache? It's not. I'm working on porting the PuTTY standalone utilities. They don't require a local SSH server.
Re: SCP/SFTP functionality
On Thu, 24 Apr 2008 00:08:36 -0400, Alan Altmark [EMAIL PROTECTED] wrote: There is an inherent architectural problem with an ssh *server* on VM: T he IP connection does not terminate in your virtual machine. When you logi n to a system with ssh, you are expected to have logged into your own account (a la telnet), not have a proxy login (a la ftp). Your profile runs, your disks are set up. An scp command would have as its local context, all the files you have accessed (or have access to) in your virtual machine. If ssh were just an alternate way to transfer files, that wouldn't be a big deal since the ftp server has to deal with the same issues. But it isn't. It's a network connection has an endpoint in your virtual machin e that scp, sftp, other ssh services (e.g. interactive console/keyboard) c an use. In previous discussions here, there was a feeling that an ssh *client* i n CMS was more important than having the ability to ssh *into* the system. The client is technically doable, and I await the day that z/OS has one that is not dependent on openSSH. Alan Altmark z/VM Development IBM Endicott = Why is this an inherent architectural problem? Is the problem that VM doesn't allow multiple logons to the same virtual machine, while Unux doe s? I don't understand why the Unix/Linux world prefers SFTP to FTPS, but it does, and in this shop that preference is encoded into Information Security rules. The user who enquired is getting dinged because a piece o f software is running around looking for violations, and he is in violation , since he is using only FTP. FTPS is not an approved option, SFTP is. The user's only solution is to stop using z/VM. I'm not sure I want to do battle with Information Security. Should I? I cannot defend IBM's failure to support SFTP or SSH. I don't even understand it. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: SCP/SFTP functionality
Alan Ackerman wrote: In previous discussions here, there was a feeling that an ssh *client* in CMS was more important than having the ability to ssh *into* the system. CMS is not a multiuser system. SSH into CMS directly does not make sense, because an SSH server is a multiuser-architected server that doesn't scale to CMS. IMHO the OpenSSH way to do what the user is trying to do is this: 1. Have a Linux/390 or OpenSolaris/390 instance running on the target VM instance. 2. Log into the the Linux/390 via SSH and short-hop from that session to CMS. Alternatively, a little more effort but much cuter: * serve up access to your CMS account via 3270Telnet server on a published port served up by the Linux/390 instance. * SSH from your remote client into the Linux/390 instance with a port redirect command on the options line. * BINGO! You've got a local port that directly connects to your CMS instance o I.e., tn3270 localhost /redir_port/ -- Jack J. Woehr# Hipsters believe that irony has http://www.well.com/~jax # more resonance than reason. http://www.softwoehr.com # - Robert Lanham
Re: SCP/SFTP functionality
On Monday, 04/28/2008 at 05:05 EDT, McKown, John [EMAIL PROTECTED] wrote: Why? What is wrong with OpenSSH? Trick question. :-) There is nothing wrong with OpenSSH. But remember that in a VM system, we're talking about virtual machines, not processes. There is no hierarchy of virtual machines. No parent-child or sibling connection, no fork()/exec(),no inheritance of files or file descriptors or sockets. The ssh daemon runs in a virtual machine that is NOT the end user's virtual machine. The daemon can listen for ssh connections, encrypt the session, and even challenge the user for a userid and password. ssh requires implementation of public/private key pairs, too. Troublesome, but not impossible to solve as long as I have a central place for all users' public/private keypairs. lightning flashes Done. I have an ssh interactive session. I have created an LDEV (logical 3270 device) and logged you onto it. I am now getting 3270 traffic from CP. Drats. This session is really intended for native ASCII. OK, forget the LDEV. I'll use (horror!) *CCS and create a linemode session instead, with all the EBCDIC traffic converted to ASCII and some sort of control characters (should I use VT220?) thrown in. Now you want to use x3270. Drats. I'm in line mode. Not to mention the block vs. character mode difference. The guest doesn't see a file descriptor to write stdout and stderr, and read from stdin. It sees a virtual 3215 or 3270. But, ok, let's wave our hands and move past it. another flash of lightning You have a terminal session. You enter scp. It wants to use the ssh tunnel. R'uh r'oh! What tunnel? The tunnel isn't in YOUR virtual machine. There is no socket available to you that represents the tunnel. Drats, drats, and double drats, said Dick Dasterdly to Penelope Pitstop. (I can hear his dog, Muttley, laughing.) The ssh clients are relatively easy since those connections DO originate in the user's virtual machine. You would have to tell the remote system that your console is dumb so that it will just run in easy-to-translate line mode. No VT. No character mode. All of this jabbering to illustrate three things: 1. That OpenSSH isn't the problem. Rather, the basic assumption of the ssh protocol, that the target user process has access to the ssh tunnel, doesn't mesh with how consoles are handled in VM. 2. I understand the seductive desire for ssh, reinforced by misguided or misinformed security experts. 3. We *have* given it some considerable thought. OK, four things: 4. All that thinking makes my head hurt. Alan Altmark z/VM Development IBM Endicott
Re: SCP/SFTP functionality
Now for the really stupid question. Why is an SSH daemon absolutely fundamental and prerequisite to a CMS SCP command to move a PDF from my A-disk to one of my linux servers for serving via Apache? /Tom Kern Alan Altmark wrote: On Monday, 04/28/2008 at 05:05 EDT, McKown, John [EMAIL PROTECTED] wrote: Why? What is wrong with OpenSSH? Trick question. :-) There is nothing wrong with OpenSSH. But remember that in a VM system, we're talking about virtual machines, not processes. There is no hierarchy of virtual machines. No parent-child or sibling connection, no fork()/exec(),no inheritance of files or file descriptors or sockets. The ssh daemon runs in a virtual machine that is NOT the end user's virtual machine. The daemon can listen for ssh connections, encrypt the session, and even challenge the user for a userid and password. ssh requires implementation of public/private key pairs, too. Troublesome, but not impossible to solve as long as I have a central place for all users' public/private keypairs. lightning flashes Done. I have an ssh interactive session. I have created an LDEV (logical 3270 device) and logged you onto it. I am now getting 3270 traffic from CP. Drats. This session is really intended for native ASCII. OK, forget the LDEV. I'll use (horror!) *CCS and create a linemode session instead, with all the EBCDIC traffic converted to ASCII and some sort of control characters (should I use VT220?) thrown in. Now you want to use x3270. Drats. I'm in line mode. Not to mention the block vs. character mode difference. The guest doesn't see a file descriptor to write stdout and stderr, and read from stdin. It sees a virtual 3215 or 3270. But, ok, let's wave our hands and move past it. another flash of lightning You have a terminal session. You enter scp. It wants to use the ssh tunnel. R'uh r'oh! What tunnel? The tunnel isn't in YOUR virtual machine. There is no socket available to you that represents the tunnel. Drats, drats, and double drats, said Dick Dasterdly to Penelope Pitstop. (I can hear his dog, Muttley, laughing.) The ssh clients are relatively easy since those connections DO originate in the user's virtual machine. You would have to tell the remote system that your console is dumb so that it will just run in easy-to-translate line mode. No VT. No character mode. All of this jabbering to illustrate three things: 1. That OpenSSH isn't the problem. Rather, the basic assumption of the ssh protocol, that the target user process has access to the ssh tunnel, doesn't mesh with how consoles are handled in VM. 2. I understand the seductive desire for ssh, reinforced by misguided or misinformed security experts. 3. We *have* given it some considerable thought. OK, four things: 4. All that thinking makes my head hurt. Alan Altmark z/VM Development IBM Endicott
Re: SCP/SFTP functionality
On Monday, 04/28/2008 at 07:53 EDT, Thomas Kern [EMAIL PROTECTED] wrote: Why is an SSH daemon absolutely fundamental and prerequisite to a CMS SCP command to move a PDF from my A-disk to one of my linux servers for serving via Apache? It's not. As I said, the ssh client side (used by scp) doesn't have any architectural impediments. An ssh daemon is needed only at the target end. Alan Altmark z/VM Development IBM Endicott
Re: SCP/SFTP functionality
On Apr 24, 2008, at 12:25 AM, Thomas Kern wrote: I thought SFTP was an ftp like command set inside the SSH protocol and that FTPS was the FTP protected by SSL. Our Network gurus keep referring too out SSL protected TN3270 as TELNETS and even insisted on us using port 992 for it since that was set in some RFC. You're correct. It also confuses people, I have found, unless you spell them out. I can't imagine why. Add to this the question of flavors of FTPS--that is, with stunnel/ pre-VM-5.3 SSLSERV, you *can* encrypt the control channel, which might be good enough. But if you need to encrypt the data too, you need explicit SSL, and you need to negotiate an encrypted channel. It's enough to make a grown man cry. Adam
Re: SCP/SFTP functionality
I know. I have been in too many conversations where I say that z/VM can support FTPS and the other instantly say 'Good, we can use SFTP from our SSH sessions.' So I have to re-educate them and 2 months later the scene repeats with the same cast of characters. At times, I regret having worked out how to do FTPS on z/VM. My time and efforts would have been better utilized in creating a secure drop-zone server using linux. /Tom Kern Adam Thornton wrote: On Apr 24, 2008, at 12:25 AM, Thomas Kern wrote: I thought SFTP was an ftp like command set inside the SSH protocol and that FTPS was the FTP protected by SSL. Our Network gurus keep referring too out SSL protected TN3270 as TELNETS and even insisted on us using port 992 for it since that was set in some RFC. You're correct. It also confuses people, I have found, unless you spell them out. I can't imagine why. Add to this the question of flavors of FTPS--that is, with stunnel/pre-VM-5.3 SSLSERV, you *can* encrypt the control channel, which might be good enough. But if you need to encrypt the data too, you need explicit SSL, and you need to negotiate an encrypted channel. It's enough to make a grown man cry. Adam
Re: SCP/SFTP functionality
No. No one has ported OpenSSH (not even the outbound commandline functions like scp/sftp) to z/VM-CMS. www.ssh.com does reference a product for z/OS, but a search of their website does not have a single document containing 'z/VM'. /Tom Kern Alan Ackerman wrote: Does z/VM support SCP/SFTP functionality? A user asked if z/VM supports SFTP. I know z/VM 5.2 supports a Secure FTP server, and z/VM 5.3 supports both a Secure FTP server client, but I don't know whether that is SFTP. (The user is using the FTP command on a CMS userid.) The TCP/IP manual says: The FTP server may be configured to allow, require, or restrict secure control and data connections using the Transport Layer Security (TLS) protocol. RFC 4217 (Securing FTP with TLS) describes the protocol used by the FTP server. Please see this RFC for more detailed information. The user knows nothing about RFCs. He sent me a link to a security document: UNIX/Linux: Connectivity Controls - FTP Configuration - FTP Service The document says: One of the following circumstances outlines when it is acceptable to leverage FTP: a) The operating system needed to communicate with a UNIX/Linux system does not have SCP/SFTP functionality (i.e. [sic] Mainframe). b) Significant performance issues leveraging SCP/SFTP. c) Business requirement that FTP is embedded into the application layer which is vendor supplied or internally developed (i.e. EDTUP). Does z/VM support SCP/SFTP functionality? Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: SCP/SFTP functionality
Does z/VM support SCP/SFTP functionality? No. That would require a working SSH. VM implements FTPS.
Re: SCP/SFTP functionality
On Apr 23, 2008, at 6:22 PM, Alan Ackerman wrote: Does z/VM support SCP/SFTP functionality? No. SFTP is the FTP command set (mostly) over an SSH channel. Sine Nomine has an FTP-to-SFTP broker, so you can FTP out from CMS, through a Linux guest (so there's no traffic on the wire unencrypted), which turns it into SFTP on the way out. We can also do SSL-wrapped-FTP brokered to plaintext FTP on the way in, but that requires licensing Glub Tech's Secure FTP Wrapper. It's pretty cheap, though: $250 (for a single IP). Adam
Re: SCP/SFTP functionality
On Wednesday, 04/23/2008 at 08:04 EDT, Thomas Kern [EMAIL PROTECTED] wrote: No. No one has ported OpenSSH (not even the outbound commandline functions like scp/sftp) to z/VM-CMS. www.ssh.com does reference a product for z/OS, but a search of their website does not have a single document containing 'z/VM'. No, they do not have support for z/VM. There is an inherent architectural problem with an ssh *server* on VM: The IP connection does not terminate in your virtual machine. When you login to a system with ssh, you are expected to have logged into your own account (a la telnet), not have a proxy login (a la ftp). Your profile runs, your disks are set up. An scp command would have as its local context, all the files you have accessed (or have access to) in your virtual machine. If ssh were just an alternate way to transfer files, that wouldn't be a big deal since the ftp server has to deal with the same issues. But it isn't. It's a network connection has an endpoint in your virtual machine that scp, sftp, other ssh services (e.g. interactive console/keyboard) can use. In previous discussions here, there was a feeling that an ssh *client* in CMS was more important than having the ability to ssh *into* the system. The client is technically doable, and I await the day that z/OS has one that is not dependent on openSSH. Alan Altmark z/VM Development IBM Endicott
Re: SCP/SFTP functionality
I thought SFTP was an ftp like command set inside the SSH protocol and that FTPS was the FTP protected by SSL. Our Network gurus keep referring too out SSL protected TN3270 as TELNETS and even insisted on us using port 992 for it since that was set in some RFC. /Tom Kern Adam Thornton wrote: On Apr 23, 2008, at 6:22 PM, Alan Ackerman wrote: Does z/VM support SCP/SFTP functionality? No. SFTP is the FTP command set (mostly) over an SSH channel. Sine Nomine has an FTP-to-SFTP broker, so you can FTP out from CMS, through a Linux guest (so there's no traffic on the wire unencrypted), which turns it into SFTP on the way out. We can also do SSL-wrapped-FTP brokered to plaintext FTP on the way in, but that requires licensing Glub Tech's Secure FTP Wrapper. It's pretty cheap, though: $250 (for a single IP). Adam
