DICOM on SSH? - SSH

This is a discussion on DICOM on SSH? - SSH ; Hi I have a medical imaging application that I normally communicates with its peers via TCP/IP. There is a client and a server portion to this application that listens on a port and client that sends to that port. (Typically ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: DICOM on SSH?

  1. DICOM on SSH?

    Hi I have a medical imaging application that I normally communicates
    with its peers via TCP/IP.
    There is a client and a server portion to this application that listens
    on a port and client that
    sends to that port. (Typically port 104).

    My question is how do I use ssh under this application? ie. What do I
    do so that the
    communications between the client and server go through ssh.

    The only configuration parameters that these applications have (that is
    relevant to tcp/ip)
    is a host name and port number.

    TIA.


  2. Re: DICOM on SSH?

    You use an SSH tunnel.
    If Box-1 is running the SSH server, and this med app is listening on
    port 104, in Box-2 you do something like:

    ssh -C -L 2323:127.0.0.1:104 Box-1

    (If you're using putty, that's allow compression and add a local
    tunnel).
    And leave it running. Then, again in Box-2, (on another Window) you
    tell the med app to connect to localhost on port 2323. It's connection
    will be caught by SSH, encrypted, and sent to Box-1. In Box-1, the SSH
    server will decrypt it and send it to 127.0.0.1 (from Box-1's point of
    view, i.e: Box-1) on port 104, so the med app will receive it.

    SpreadTooThin wrote:
    > Hi I have a medical imaging application that I normally communicates
    > with its peers via TCP/IP.
    > There is a client and a server portion to this application that listens
    > on a port and client that
    > sends to that port. (Typically port 104).
    >
    > My question is how do I use ssh under this application? ie. What do I
    > do so that the
    > communications between the client and server go through ssh.
    >
    > The only configuration parameters that these applications have (that is
    > relevant to tcp/ip)
    > is a host name and port number.
    >
    > TIA.



  3. Re: DICOM on SSH?


    Wences wrote:
    > You use an SSH tunnel.
    > If Box-1 is running the SSH server, and this med app is listening on
    > port 104, in Box-2 you do something like:
    >


    SSH Server? Sorry but is that different from ssh? The secure shell.

    > ssh -C -L 2323:127.0.0.1:104 Box-1
    >
    > (If you're using putty, that's allow compression and add a local
    > tunnel).
    > And leave it running. Then, again in Box-2, (on another Window) you
    > tell the med app to connect to localhost on port 2323. It's connection
    > will be caught by SSH, encrypted, and sent to Box-1. In Box-1, the SSH
    > server will decrypt it and send it to 127.0.0.1 (from Box-1's point of
    > view, i.e: Box-1) on port 104, so the med app will receive it.
    >
    > SpreadTooThin wrote:
    > > Hi I have a medical imaging application that I normally communicates
    > > with its peers via TCP/IP.
    > > There is a client and a server portion to this application that listens
    > > on a port and client that
    > > sends to that port. (Typically port 104).
    > >
    > > My question is how do I use ssh under this application? ie. What do I
    > > do so that the
    > > communications between the client and server go through ssh.
    > >
    > > The only configuration parameters that these applications have (that is
    > > relevant to tcp/ip)
    > > is a host name and port number.
    > >
    > > TIA.



  4. Re: DICOM on SSH?

    SpreadTooThin wrote:
    > Wences wrote:
    >> You use an SSH tunnel.
    >> If Box-1 is running the SSH server, and this med app is listening on
    >> port 104, in Box-2 you do something like:
    >>

    >
    > SSH Server? Sorry but is that different from ssh? The secure shell.


    Oh, my. You are newbie. It's OK, we'll walk through it with you. There are
    several protocols called "SSH", the older SSH1 and the newer SSH2. When you
    connect to a machine with SSH, the protocol, you're using using an SSH
    "client" on your end, and the software that answers your attempt and
    actually sets up the connection is the SSH "server".

    OK? Now, most SSH clients are shell clients: Some are SCP or SFTP clients,
    for transferring files, but those are also SSH clients because they use the
    SSH protocol. Does that also make sense?



  5. Re: DICOM on SSH?


    Nico Kadel-Garcia wrote:
    > SpreadTooThin wrote:
    > > Wences wrote:
    > >> You use an SSH tunnel.
    > >> If Box-1 is running the SSH server, and this med app is listening on
    > >> port 104, in Box-2 you do something like:
    > >>

    > >
    > > SSH Server? Sorry but is that different from ssh? The secure shell.

    >
    > Oh, my. You are newbie. It's OK, we'll walk through it with you. There are
    > several protocols called "SSH", the older SSH1 and the newer SSH2. When you
    > connect to a machine with SSH, the protocol, you're using using an SSH
    > "client" on your end, and the software that answers your attempt and
    > actually sets up the connection is the SSH "server".
    >
    > OK? Now, most SSH clients are shell clients: Some are SCP or SFTP clients,
    > for transferring files, but those are also SSH clients because they use the
    > SSH protocol. Does that also make sense?


    Yep makes sence.. If I had thought about it for more than 30 seconds I
    would have
    done a man sshd.
    Now.. because its medical data.. There are rules that need to be
    followed.. and for whatever
    reason ssh is not 'ethical'. It would appear that one needs ssl/tsl.

    Anyhow for anonymouse data ssh should be ok. What is the method for
    setting up sshd
    for this application?

    TIA from a newbie.


  6. Re: DICOM on SSH?

    SpreadTooThin wrote:

    > Yep makes sence.. If I had thought about it for more than 30 seconds I
    > would have
    > done a man sshd.
    > Now.. because its medical data.. There are rules that need to be
    > followed.. and for whatever
    > reason ssh is not 'ethical'. It would appear that one needs ssl/tsl.


    That rule makes *NO* sense. I can see insisting on SSL for consistency
    reasons, rather than insisting that vendors support multiple encryption
    protocols, and there's a whole fascinating set of laws about exporting
    encryption tools in software as a "munition", making it illegal to ship to
    Cuba and some other countries from the US. Can you point us to this medical
    data policy or regulation? It sounds very odd indeed.

    > Anyhow for anonymouse data ssh should be ok. What is the method for
    > setting up sshd
    > for this application?
    >
    > TIA from a newbie.


    For anonymous data, for an interactive application like medical imaging
    software? Why would you bother using an encrypted protocol at all?

    Either way, if you want to keep things simple, it should be straghtforward
    to set up SSH or SSL to use a tunneled port: that way, a port 104 client on
    your local machine can be transmitted to a port 104 service on the server
    over an encrypted SSH or SSL link to the server. You lose some logging that
    way, but goodness knows I've done this to access expensive, licensed
    software remotely.

    In fact, roughly 15 years ago, I urged the use of VNC or, if necessary, VNC
    over SSH to provide remote access to CT software on a very expensive server,
    instead of paying $10,000 for antoerh turnkey SGI system with the very
    expensive software. I think only a few researchers used it, without the
    formal agreement of the department manager, but I still thought it was a
    good idea.



  7. Re: DICOM on SSH?


    Nico Kadel-Garcia wrote:
    > SpreadTooThin wrote:
    >
    > > Yep makes sence.. If I had thought about it for more than 30 seconds I
    > > would have
    > > done a man sshd.
    > > Now.. because its medical data.. There are rules that need to be
    > > followed.. and for whatever
    > > reason ssh is not 'ethical'. It would appear that one needs ssl/tsl.

    >
    > That rule makes *NO* sense. I can see insisting on SSL for consistency
    > reasons, rather than insisting that vendors support multiple encryption
    > protocols, and there's a whole fascinating set of laws about exporting
    > encryption tools in software as a "munition", making it illegal to ship to
    > Cuba and some other countries from the US. Can you point us to this medical
    > data policy or regulation? It sounds very odd indeed.
    >


    See http://medical.nema.org/dicom/2006/06_15pu.pdf
    Page 24.
    But ssh and sshd do support tls don't they?
    Sorry but this thread seems to have lost its direction.


    > > Anyhow for anonymouse data ssh should be ok. What is the method for
    > > setting up sshd
    > > for this application?
    > >
    > > TIA from a newbie.

    >
    > For anonymous data, for an interactive application like medical imaging
    > software? Why would you bother using an encrypted protocol at all?
    >
    > Either way, if you want to keep things simple, it should be straghtforward
    > to set up SSH or SSL to use a tunneled port: that way, a port 104 client on
    > your local machine can be transmitted to a port 104 service on the server
    > over an encrypted SSH or SSL link to the server. You lose some logging that
    > way, but goodness knows I've done this to access expensive, licensed
    > software remotely.
    >
    > In fact, roughly 15 years ago, I urged the use of VNC or, if necessary, VNC
    > over SSH to provide remote access to CT software on a very expensive server,
    > instead of paying $10,000 for antoerh turnkey SGI system with the very
    > expensive software. I think only a few researchers used it, without the
    > formal agreement of the department manager, but I still thought it was a
    > good idea.



  8. Re: DICOM on SSH?

    > > > Now.. because its medical data.. There are rules that need to be
    > > > followed.. and for whatever
    > > > reason ssh is not 'ethical'. It would appear that one needs ssl/tsl.


    > See http://medical.nema.org/dicom/2006/06_15pu.pdf
    > Page 24.



    >From what I read there: there are scarce mentions to SSH, and none

    implies its not being ethical, least to being not ethical.
    It still holds true that the document only recomends TLS, but it
    doesn't say anything about SSH being inadmissible.

    And then again, they say:
    "NEMA has no power, nor does it undertake to police or enforce
    compliance with the contents of this document." and a lot more along
    that line, so my guess is if you still prefer SSH, to TLS you can go
    ahead --at your own risk.


    > But ssh and sshd do support tls don't they?


    Not to my knowledge. TLS and SSH are two different protocols, designed
    for different things. TLS is the difference between HTTP and HTTPS.

    If you want to use TLS, the Wikipedia says:

    --begin quote--
    While an increasing number of client and server products can support
    SSL natively, many still do not. In these cases, a user may wish to use
    standalone SSL products like Stunnel to provide encryption. However,
    the Internet Engineering Task Force recommended in 1997 that
    application protocols offer a way to upgrade to TLS from a plaintext
    connection, rather than use a separate port for encrypted
    communications - this prevents use of wrappers such as Stunnel.
    SSL can also be used to tunnel an entire network stack to create a VPN,
    as is the case with OpenVPN.
    --end quote--

    But I've never tried any of those products...



    SpreadTooThin wrote:
    > Nico Kadel-Garcia wrote:
    > > SpreadTooThin wrote:
    > >
    > > > Yep makes sence.. If I had thought about it for more than 30 seconds I
    > > > would have
    > > > done a man sshd.
    > > > Now.. because its medical data.. There are rules that need to be
    > > > followed.. and for whatever
    > > > reason ssh is not 'ethical'. It would appear that one needs ssl/tsl.

    > >
    > > That rule makes *NO* sense. I can see insisting on SSL for consistency
    > > reasons, rather than insisting that vendors support multiple encryption
    > > protocols, and there's a whole fascinating set of laws about exporting
    > > encryption tools in software as a "munition", making it illegal to ship to
    > > Cuba and some other countries from the US. Can you point us to this medical
    > > data policy or regulation? It sounds very odd indeed.
    > >

    >
    > See http://medical.nema.org/dicom/2006/06_15pu.pdf
    > Page 24.
    > But ssh and sshd do support tls don't they?
    > Sorry but this thread seems to have lost its direction.
    >
    >
    > > > Anyhow for anonymouse data ssh should be ok. What is the method for
    > > > setting up sshd
    > > > for this application?
    > > >
    > > > TIA from a newbie.

    > >
    > > For anonymous data, for an interactive application like medical imaging
    > > software? Why would you bother using an encrypted protocol at all?
    > >
    > > Either way, if you want to keep things simple, it should be straghtforward
    > > to set up SSH or SSL to use a tunneled port: that way, a port 104 client on
    > > your local machine can be transmitted to a port 104 service on the server
    > > over an encrypted SSH or SSL link to the server. You lose some logging that
    > > way, but goodness knows I've done this to access expensive, licensed
    > > software remotely.
    > >
    > > In fact, roughly 15 years ago, I urged the use of VNC or, if necessary, VNC
    > > over SSH to provide remote access to CT software on a very expensive server,
    > > instead of paying $10,000 for antoerh turnkey SGI system with the very
    > > expensive software. I think only a few researchers used it, without the
    > > formal agreement of the department manager, but I still thought it was a
    > > good idea.



+ Reply to Thread