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.

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:[color=blue]
> 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.[/color]

Wences wrote:[color=blue]
> 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:
>[/color]

SSH Server? Sorry but is that different from ssh? The secure shell.
[color=blue]
> 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:[color=green]
> > 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.[/color][/color]

SpreadTooThin wrote:[color=blue]
> Wences wrote:[color=green]
>> 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:
>>[/color]
>
> SSH Server? Sorry but is that different from ssh? The secure shell.[/color]

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?

Nico Kadel-Garcia wrote:[color=blue]
> SpreadTooThin wrote:[color=green]
> > Wences wrote:[color=darkred]
> >> 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:
> >>[/color]
> >
> > SSH Server? Sorry but is that different from ssh? The secure shell.[/color]
>
> 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?[/color]

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.

SpreadTooThin wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> Anyhow for anonymouse data ssh should be ok. What is the method for
> setting up sshd
> for this application?
>
> TIA from a newbie.[/color]

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.

Nico Kadel-Garcia wrote:[color=blue]
> SpreadTooThin wrote:
>[color=green]
> > 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.[/color]
>
> 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.
>[/color]

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

[color=blue][color=green]
> > Anyhow for anonymouse data ssh should be ok. What is the method for
> > setting up sshd
> > for this application?
> >
> > TIA from a newbie.[/color]
>
> 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.[/color]

> > > Now.. because its medical data.. There are rules that need to be[color=blue][color=green][color=darkred]
> > > followed.. and for whatever
> > > reason ssh is not 'ethical'. It would appear that one needs ssl/tsl.[/color][/color][/color]
[color=blue]
> See [url]http://medical.nema.org/dicom/2006/06_15pu.pdf[/url]
> Page 24.[/color]

[color=blue]
>From what I read there: there are scarce mentions to SSH, and none[/color]
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.

[color=blue]
> But ssh and sshd do support tls don't they?[/color]

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:[color=blue]
> Nico Kadel-Garcia wrote:[color=green]
> > SpreadTooThin wrote:
> >[color=darkred]
> > > 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.[/color]
> >
> > 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.
> >[/color]
>
> See [url]http://medical.nema.org/dicom/2006/06_15pu.pdf[/url]
> Page 24.
> But ssh and sshd do support tls don't they?
> Sorry but this thread seems to have lost its direction. :)
>
>[color=green][color=darkred]
> > > Anyhow for anonymouse data ssh should be ok. What is the method for
> > > setting up sshd
> > > for this application?
> > >
> > > TIA from a newbie.[/color]
> >
> > 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.[/color][/color]