# SSH Questions

## Shining Arcanine

I am a computer science undergraduate student. To make my assignments easier, I installed 64-bit Gentoo Linux (kernel 2.6.31, GCC 4.4.1, ext4 and KDE 4.3.1 with only 64-bit libraries and 32-bit support specifically disabled in the kernel) on a VMWare Virtual PC using VMWare Player on my desktop and set it up so I could SSH into the virtual PC from the internet. I have a few questions/problems with this configuration.

1. I have sshd configured to prevent myself from directly logging in as root to make things harder for any would be hackers. I understand that I can configure SSH to disallow the use of passwords and instead require DSA keys to login. What is the exact benefit to doing this and would I get the same/a similar benefit if I were to disallow the use of DSA keys for logging in (as I don't use DSA keys). Is there anything beyond this that I can do to make it more difficult for someone to hack into the virtual PC via SSH short of disabling ssh?

2. I want to be able to do a remote X-Windows session into the virtual machine from my laptop. I know that I need to set ForwardX11 in ssh_config to yes and X11Forwarding in sshd_config to yes. After doing this and restarted sshd, whenever I attempt to do a remote X session into my virtual machine, the display is sent to the virtual machine's display rather than the system from which I am connecting. DISPLAY by default is being set to localhost:10.0 and I have tried setting it to the remote computer's address, but no matter what I do, it does not work. I have even tried setting X11UseLocalhost to no (as opposed to the default of yes) in sshd_config, but this setting appears to have no effect. How do I get this to work?

3. I want to be able to do a remote X-Windows session into the virtual machine from my university. My university has a firewall that prevents SSH from working. However, when I am on campus, I can SSH into a UNIX (Sun Solaris 9) server that the university maintains and then SSH into my virtual machine from there. Is there any way to route a remote X-Windows session into my virtual PC from either my laptop or one of my university's computers (both of which have X-Windows software installed) through my university's UNIX server to bypass my university's firewall? If the information is of any use, I can establish an X-Windows session into my university's UNIX server from both my house and any computer on my university's internal network.

----------

## avx

Keys add to the security, since you/the hacker would need them to authorise on the system. Of course, the hacker could get acces to the keyfiles by a MITM-attack, but that's nothing too trivial, so should at least stop the scriptkiddies. Key-generation is easy, as is the configuration needed for them to be used and if you need to log on from different machines, you could place them on a memorystick or something like that. Beyond that, you could change the port to be some non-default port, i.e. :52349 instead of the default :22. You can also setup portknocking, where the port is closed but if you send a specific set of packets and the firewall(i.e. iptables) is configured correctly, you can open the ports from the outside(gentoo wiki or google for more info). You can also run some scripts to disallow connects from an ip, if this ip has a number of X failed logins. There's pretty much you can do, googleing for something like 'ssh security tips' should bring up a lot of info.

No clue on the other things, I'm not using X-forwarding, sry.

----------

## tuber

Regarding problem number 2, are you saying that when you SSH into your VM from your laptop, the DISPLAY variable is set to localhost:10.0, and when you try to run, say, an xterm, nothing happens?

----------

## Shining Arcanine

 *tuber wrote:*   

> Regarding problem number 2, are you saying that when you SSH into your VM from your laptop, the DISPLAY variable is set to localhost:10.0, and when you try to run, say, an xterm, nothing happens?

 

Well, I am using some software my university gave me called X-Win32, which is supposed to ssh into the virtual machine and execute the command "/usr/bin/xterm -ls" for me (as far as I understand anyway). Aftter which, I am presented with a Unix shell, whose environment DISPLAY variable is set to localhost:10.0 and into which I can type startx. Upon typing startx, KDE does start, except it is displayed in the virtual PC's window on my desktop computer, which is my problem. I cannot seem to get it to be displayed on the computer I am using to connect.

I know the software I am using to connect is configured properly for two reasons. The first is because it works with my university's unix server. The second is because I had setup less customized Gentoo virtual machine where I could get it to work prior to this one. That machine was erased to create this one, as I didn't some of the stuff that was done when following the manual and I wanted to configure it to be the way I wanted it to be from the start. To my surprise, it was really easy for me to do that, but it came at the cost of not being able to get a remote X-Windows session working.

I remember on the original machine, I just had to modify DISPLAY to get it to work (and at some point, I believe it started being set for me, although I have no idea what I did that caused it to do that), but this time that doesn't seem to be the case. I know that I had to change the network configuration to get traceroute working, as the virtual NAT that VMWare Player used by default was interfering with its operation (not to mention my ability to forward a port to it). It is now connected to a virtual switch, so its DHCP is coming from my router. This probably should not be the cause of the problem though. Perhaps I am just not setting DISPLAY correctly. I am curious as to why it is not being automatically configured for me.

----------

## Shining Arcanine

 *ph030 wrote:*   

> Keys add to the security, since you/the hacker would need them to authorise on the system. Of course, the hacker could get acces to the keyfiles by a MITM-attack, but that's nothing too trivial, so should at least stop the scriptkiddies. Key-generation is easy, as is the configuration needed for them to be used and if you need to log on from different machines, you could place them on a memorystick or something like that. Beyond that, you could change the port to be some non-default port, i.e. :52349 instead of the default :22. You can also setup portknocking, where the port is closed but if you send a specific set of packets and the firewall(i.e. iptables) is configured correctly, you can open the ports from the outside(gentoo wiki or google for more info). You can also run some scripts to disallow connects from an ip, if this ip has a number of X failed logins. There's pretty much you can do, googleing for something like 'ssh security tips' should bring up a lot of info.
> 
> No clue on the other things, I'm not using X-forwarding, sry.

 

Thanks, I changed the port number. I will have a chat with my networking professor about some of the other things you mentioned tomorrow.

----------

## timeBandit

 *ph030 wrote:*   

> Of course, the hacker could get acces to the keyfiles by a MITM-attack, but that's nothing too trivial, so should at least stop the scriptkiddies.

 No, the keys cannot be compromised by a man-in-the-middle attack. SSH never transmits either half of the key pair (public or private) over the wire.

During negotiation of the link, each end of the channel uses its half of the key (public key at the server, private key at the client) to encrypt/decrypt authentication packets for its peer. Basically, the server generates a challenge and encrypts it with the public key of the client (which must be uploaded in advance to the server). The client decrypts the challenge using the private key, generates an appropriate response, encrypts it (again using the private key) and sends it back to the server. The server decrypts this reply using the public key and, if it the response is valid, authenticates the client. Since only someone holding the matching private key could have read the challenge and created a readable reply, the server knows with extremely high confidence that the client user is authentic.

Once the introductions are out of the way, the server generates a single-use encryption key for the session, encrypts it with the public key and sends it to the client. Client and server then use this key and a fast, symmetric algorithm (e.g., DES, IDEA, Blowfish, etc.) to encrypt all traffic for the rest of the session. Public/private key encryption is too slow for this purpose, hence the switch.

Notice the defenses against man-in-the-middle:Public/private keys are never exchanged.Session keys are valid for one session only.Session keys are never transmitted in the clear.The last line of defense is provided by host authentication. An SSH server has a private/public key pair of its own, called the host key. When you connect to a server, it send its public key to your client, which retains it to verify it is connecting to the same host in the future. If a hacker tries to spoof the server's identity, the malicious server will not have the correct private key. The client warns you (optionally, prevents login altogether) if the host's identity changes--a warning you should take very seriously.

----------

## timeBandit

 *Shining Arcanine wrote:*   

> 2. I want to be able to do a remote X-Windows session into the virtual machine from my laptop. I know that I need to set ForwardX11 in ssh_config to yes and X11Forwarding in sshd_config to yes.  DISPLAY by default is being set to localhost:10.0 ...

 This is correct behavior and suggests you have set up X11 forwarding properly (at the server at least). X clients connect to display :10 at the server. All traffic on this display is forwarded through the tunnel to your SSH client, which in turn tries to hand it to an X  server on display :0 (by default) on your client machine. Do you have an X server running on the client machine before you login to SSH?

 *Quote:*   

> 3. I want to be able to do a remote X-Windows session into the virtual machine from my university. My university has a firewall that prevents SSH from working. However, when I am on campus, I can SSH into a UNIX (Sun Solaris 9) server that the university maintains and then SSH into my virtual machine from there. Is there any way to route a remote X-Windows session into my virtual PC from either my laptop or one of my university's computers (both of which have X-Windows software installed) through my university's UNIX server to bypass my university's firewall?

 Yes. All you need to do is forward X11 on both links and it should Just Work(tm).

```
laptop $ ssh -X you@sunbox

sunbox $ ssh -Y you@vmbox

vmbox $ nohup xterm &

vmbox $ #An XTerm window from vmbox should open on your laptop.
```

Notice the use of trusted X11 forwarding (-Y) on the second hop. By default, untrusted forwarding (-X) won't work because the xauth data will not match (ssh warns you of this). Once you've got the basic tunnels working, you can (and should) find out how to avoid trusted forwarding, which is a security risk.

Once you have basic X11 forwarding working, you should investigate using NX instead. NX is a compressed and cached version of the X11 protocol optimized for use over slow links (WANs, the Internet). It is quite snappy even over 768Kb (upload) ADSL. You will quickly discover that X11 over the Internet is a dog, if it's usable at all. The protocol is really only suitable for fast LANs.

----------

## Shining Arcanine

 *timeBandit wrote:*   

>  *Shining Arcanine wrote:*   2. I want to be able to do a remote X-Windows session into the virtual machine from my laptop. I know that I need to set ForwardX11 in ssh_config to yes and X11Forwarding in sshd_config to yes.  DISPLAY by default is being set to localhost:10.0 ... This is correct behavior and suggests you have set up X11 forwarding properly (at the server at least). X clients connect to display :10 at the server. All traffic on this display is forwarded through the tunnel to your SSH client, which in turn tries to hand it to an X  server on display :0 (by default) on your client machine. Do you have an X server running on the client machine before you login to SSH?
> 
>  *Quote:*   3. I want to be able to do a remote X-Windows session into the virtual machine from my university. My university has a firewall that prevents SSH from working. However, when I am on campus, I can SSH into a UNIX (Sun Solaris 9) server that the university maintains and then SSH into my virtual machine from there. Is there any way to route a remote X-Windows session into my virtual PC from either my laptop or one of my university's computers (both of which have X-Windows software installed) through my university's UNIX server to bypass my university's firewall? Yes. All you need to do is forward X11 on both links and it should Just Work(tm).
> 
> ```
> ...

 

I just tried running firefox in the xterm Window that X-Win32 gives me and it opened Firefox on the computer. I then tried startkde it and opened on my computer. However, if I type Xorg or startx, it opens on the virtual machine. This isn't a huge problem, but I expected things to work differently (I am new to this stuff). Also, you are right, it is extremely slow. I had been hoping that my desktop would have been faster than my university's UNIX server, but it isn't.  :Sad: 

Anyway, I will try doing the other things you told me about when I am on campus. Thankyou for your help.

----------

## avx

@timeBandit, thanks for correction  :Smile: 

----------

## Hu

The observed behavior sounds correct.  startx is used to start an X server, so it will take control of a display on the machine where it is started.  startkde, firefox, and similar commands start X clients, which will connect to the server named in $DISPLAY and render themselves there.  This is why they appear on your local desktop, since you have a Microsoft Windows-hosted X server displaying those applications.

----------

