I see this line in the phpinfo:
Environment
SSH_CONNECTION 84.143.217.132 51075 111.243.0.218 31130
Is this SSH tunnel? What is this?
Upon a successful connection, OpenSSH sets several environment variables.
SSH_CONNECTION shows the address of the client, the outgoing port on the client, the address of the server and the incoming port on the server.
So it identifies the client and server ends of the connection. You can read more about that here: Wikibooks.org/OpenSSH/Client applications.
Related
If I ssh into host3.example.com 192.168.1.1, where host2.example.com also resolves to 192.168.1.1, is there any way for the remote machine to tell which hostname was used for the connection?
i.e. Does the ssh protocol send the remote name to the remote machine, like SNI in HTTPS?
(I am running an ssh server from within an application, so I am free to modify the ssh server to provide this information, if ssh clients provide it.)
As far as I know, there is no protocol extension like SNI for SSH. The DNS name (of the server) is not passed to the server by the client. See also this discussion.
How does SSH dynamic forward (-D) function under the hood?
I understand that SSH dynamic forward opens a SOCSK4 proxy on the local host, and that each connection to the SOCK4 proxy is forwarded over the SSH tunnel to the remote destination.
Does SSH intercept the connections to the SOCKS4 proxy? I mean, it cannot be a "normal" SOCKS4 proxy, because then it would directly proxy the connections to the remote hosts.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
When the -D flag is given, the SSH client will start a built-in SOCKS4/5 proxy. (note: "SOCKS", not "SOCK").
-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.
When another application wishes to connect to a proxied service, they will establish a connection via this SOCKS server. The SOCKS protocol is a little bit of negotiation that occurs at the beginning of a connection, something like this: (inspired by the wiki page)
ssh -D 1234 user#remote is execute, the SSH client starts a SOCKS proxy server listening on port 1234.
A local application wishes to communicate with a service via the SOCKS proxy, so connects to port 1234.
The SOCKS client asks for a connection to a particular IP address and port - e.g: 66.102.7.99, port 4321.
The SOCKS server, in this case the SSH client, will negotiate to establish this onward connection with it's server (remote, from above). This may fail.
The SOCKS serve will respond to the client with success / failure information.
If successful, all data passed through this socket will now be forwarded appropriately:
From the local application, to the SSH server (remote), and then onto 66.102.7.99.
From 66.102.7.99 to the SSH server (remote), and then onto the local SSH client, and ultimately the local application.
Does SSH intercept the connections to the SOCK4 proxy?
No, the SSH Client is the SOCKS proxy.
I mean, it cannot be a "normal" SOCK4 proxy, because then it would directly proxy the connections to the remote hosts.
I suppose it's not really - the SSH Client and Server act together to achieve the function of a "normal" SOCKS proxy. The high-level result is that the proxy listens on one host, but forwards data from another host, with a magical link in between.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
TCP is a connection-oriented method of communication. That is to say that once a connection is established, data can flow in both directions, and is reliably identified as "related to that connection". With this information it is trivial to associate the data with arbitrary rules such as "forward to the SSH server, who will forward to 66.102.7.99".
I am attempting to create an SSH server (using Paramiko, but that's mostly irrelevant here). I am wondering if there is any way to determine the hostname that the SSH client requested. For example, if I were to connect with
ssh user#example.com
but I also had a CNAME record that pointed to the same server so I could also connect with
ssh user#foo.com
then I would like the server to know in the first case the user requested example.com and in the second, foo.com.
I have been reading through SSH protocol documents like:
https://www.rfc-editor.org/rfc/rfc4253
https://www.rfc-editor.org/rfc/rfc4252
But cannot find out if there is a way to do this.
In general, the ssh protocol does not support this. It's possible that a given ssh client may send an environment variable that gives you a hint, but that would happen after key exchange and user authentication, which would be far later than you'd want the information. It happens that if you were using Kerberos authentication via one of the ssh GSS-API mechanisms described in RFC 4462, you would get the hostname the user requested as part of the GSS exchange. That almost certainly doesn't help you, but it happens to be the only case I'm aware of where this information is sent.
For ssh virtual hosting you're going to need to dedicate an IP address or port for each virtual host. Take a look at port sharing or IPv6 as possibilities for your application.
I SSH into my workstation, which is a mac running OS X Yosemite, daily. Unfortunately, I noticed a while back that enabling remote login into my machine has put it under the fire of many automated dictionary attacks trying to log in using the default port, 22.
To make my machine more secure, I changed the SSH port. To do so, I edited the /etc/services file, and changed the following two lines:
ssh 2123/udp # SSH Remote Login Protocol
ssh 2123/tcp # SSH Remote Login Protocol
That greatly reduced the number of dictionary attacks, but now when I try to SSH from my workstation to other machines, I always need to specify the port (which is usually port 22).
This is easy enough for most simple tasks, just specify the port when SSHing in:
ssh -p22 me#another.computer.com
It becomes a pain for more complicated tasks where specifying the port is not an option, but it can still be done by adding an entry in ~/.ssh/config:
Host github.com
Hostname ssh.github.com
Port 443
Between these two options, I could always connect to any machine I wanted to connect to. However, I'm now writing a script that will connect to machines that will have different IP addresses (and domain names), and there is no optional argument to specify the port number.
I have also been getting frustrated that it does not default to port 22 for outgoing connections, but I do not want to change my incoming port back to 22.
Is it possible to change the incoming SSH port, but still have the default outgoing SSH port? That is, can I only allow people to login to my workstation using port 2123, but when I try connecting to other machines, the default port it tries to use is port 22?
I'm running OS X 10.10.2 Yosemite.
Change the ssh port back in `/etc/services' - that sets the defined port for the ssh protocol.
Then change the port that sshd listens on. On OS-X this is more complicated than it need be. See https://serverfault.com/questions/18761/how-to-change-sshd-port-on-mac-os-x
I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services