I configurated a bastion server on AWS on my public subnet.
I can make direct ssh to the ec2 instance inside the private subnet, using the bastion host.
I can connect to the bastion host and check if the 7474 port on the private ec2 istance is opened.
nc -v -z -w 5 10.0.3.102 7474; echo $?
Connection to 10.0.3.102 7474 port [tcp/*] succeeded!
0
I want to ssh tunnel from a localhost (my home machine) to a ec2 instance on private network.
ssh -v -C -N -L 9000:PRIVATE_MDM:7474 BASTION
But i getting:
open failed: administratively prohibited: open failed
Authenticated to 52.32.240.40 ([52.32.240.40]:22).
debug1: Local connections to LOCALHOST:9000 forwarded to remote address PRIVATE_MDM:7474
debug1: Local forwarding listening on ::1 port 9000.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 9000.
debug1: channel 1: new [port listener]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Connection to port 9000 forwarding to PRIVATE_MDM port 7474 requested.
debug1: channel 2: new [direct-tcpip]
debug1: Connection to port 9000 forwarding to PRIVATE_MDM port 7474 requested.
debug1: channel 3: new [direct-tcpip]
channel 2: open failed: administratively prohibited: open failed
channel 3: open failed: administratively prohibited: open failed
debug1: channel 2: free: direct-tcpip: listening port 9000 for PRIVATE_MDM port 7474, connect from 127.0.0.1 port 42685 to 127.0.0.1 port 9000, nchannels 4
debug1: channel 3: free: direct-tcpip: listening port 9000 for PRIVATE_MDM port 7474, connect from 127.0.0.1 port 42686 to 127.0.0.1 port 9000, nchannels 3
debug1: Connection to port 9000 forwarding to PRIVATE_MDM port 7474 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: administratively prohibited: open failed
debug1: channel 2: free: direct-tcpip: listening port 9000 for PRIVATE_MDM port 7474, connect from 127.0.0.1 port 42687 to 127.0.0.1 port 9000, nchannels 3
BASTION machine has forbidden to create port forwarding by option AllowTcpForwarding. If you want to have port-forwarding working, you need to allow this option on this machine.
EDIT: Now I see the flaw there. Can you add description what are you trying to achieve? Forwarding your non-used local port to non-used remote port does not make sense. You either forward existing service on remote side to your local port (then use -L -- local port forwarding) or the other way round, your local service to remote port (then you use -R -- remote port forwarding). Without this, you can't proceed further.
SOLUTION: Difference between nc and ssh command in examples is in usage of direct IP address and hostname. The BASTION was not able to resolve PRIVATE_MDM which caused the problem.
Related
I'm trying to use rsync on my dev server to download files to my local machine after checking out a branch on the dev server.
Before using wsl2, I used to be able to do the following:
Remote server
rsync -ave "ssh -p 22001" --delete --exclude-from ~/rsync_exclude_list.txt ~/as/ alex#localhost:/home/alexmk92/code/project
Local SSH config
Host dev-tunnel
HostName dev.sever.co.uk
User as
ControlMaster auto
ControlPath ~/.ssh/sockets/%r#%h:%p
RemoteForward 22001 localhost:22
Host dev
HostName dev.server.co.uk
User as
RequestTTY yes
RemoteCommand cd as; bash
I can then run these with ssh dev and ssh -fvN dev-tunnel if from the remote server I type ssh -p 22001 alex#localhost then I get:
debug1: remote forward success for: listen 22001, connect localhost:22
debug1: All remote forwarding requests processed
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 22001, originator 127.0.0.1 port 34472
debug1: connect_next: host localhost ([127.0.0.1]:22) in progress, fd=5
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to localhost port 22: failed.
debug1: channel 1: free: 127.0.0.1, nchannels 2
I'm guessing this is because WSL2 no longer runs on localhost, and is instead isolated within Hypervisor. Which probably means windows is receiving this request on localhost:22 (where no SSH server is running) and then hangs up the connection.
How can I forward the request to my WSL2 SSH process?
It is possible to add a port mapping to WSL2 machines, using the following WSH script:
$port = 3000;
$addr = '0.0.0.0';
$remoteaddr = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteaddr -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if( $found ) {
$remoteaddr = $matches[0];
} else {
echo "Error: ip address of WSL 2 cannot be found";
exit;
}
Invoke-Expression "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr"
Invoke-Expression "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteaddr"
echo "Success: Port mapping added!";
Of course, you need to change to port and maybe the IP address (first two lines)
Maybe you need to run the script as admin...
I'm running into an issue when I try to vnc into a new VM created with virt-install. When specifying vnc with virt-install using this:
--vnc \
--vncport=5905 \
--noautoconsole
The VM is created and 5905 is listening, but only on ipv4 as shown here:
# netstat -l | grep 5905
tcp 0 0 localhost:5905 0.0.0.0:* LISTEN
The problem is when I try to SSH tunnel using "ssh -v -L 5905:localhost:5905 myhost", I get a connection refused error because the vnc port is trying to forward from the hosts ipv6 local loopback interface and the vnc port is not listening on it:
debug1: Connection to port 5905 forwarding to localhost port 5905 requested.
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed: Connection refused
debug1: channel 3: free: direct-tcpip: listening port 5905 for localhost port 5905, connect from ::1 port 57890 to ::1 port 5905, nchannels 4
I could solve this also by connecting vnc to the hosts ipv4 local loopback, but I'm not sure how to do that. Ideally I would like to have vnc listen on both ipv4 and ipv6.
I was able to get the VM to listen on ipv6 by editing the xml to include this in the graphics parameter:
<graphics type='vnc' port='5905' autoport='no' listen='localhost'>
<listen type='address' address='localhost'/>
</graphics>
You can specify this in the virt-install command by using this:
--graphics vnc,listen=localhost,port=5905 \
If you ask me, virt-install should default to localhost instead of it's ipv4 local loopback :/
So I have to kinit as certain principal locally using his keytab.
Since the Kerberose kdc on remote server, which I reach with on vpn, I need to use ssh to access the server, and thus make tunneling to the service.
For this I did the following:
Copied the krb5.conf from the remote server and replaced the local with it
Copied the keytab of my interest
Since I need access to the service:
ssh -L1088:localhost:88 -L10749:localhost:749 remote_server
Changed the local file krb5.conf to
admin_server = localhost:10749
kdc = localhost:1088
But when I try to kinit
KRB5_TRACE=/dev/stdout kinit -kt ${PRINCIPAL_KEYTAB}.keytab ${PRINCIPAL_NAME}
[12332] 1504171391.121253: Getting initial credentials for ${PRINCIPAL_NAME}
[12332] 1504171391.123940: Looked up etypes in keytab: des, des-cbc-crc, aes128-cts, rc4-hmac, aes256-cts, des3-cbc-sha1
[12332] 1504171391.124027: Sending request (227 bytes) to ${DOMAIN}
[12332] 1504171391.124613: Resolving hostname localhost
[12332] 1504171391.124988: Sending initial UDP request to dgram ::1:1088
[12332] 1504171391.125070: Sending initial UDP request to dgram 127.0.0.1:1088
[12332] 1504171391.125120: Initiating TCP connection to stream ::1:1088
[12332] 1504171391.125165: Terminating TCP connection to stream ::1:1088
[12332] 1504171391.125186: Initiating TCP connection to stream 127.0.0.1:1088
[12332] 1504171391.125216: Terminating TCP connection to stream 127.0.0.1:1088
kinit: Cannot contact any KDC for realm '${DOMAIN}' while getting initial credentials
I retried by adding ssh -vvv and got
debug1: Connection to port 1088 forwarding to localhost port 88 requested.
debug2: fd 15 setting TCP_NODELAY
debug2: fd 15 setting O_NONBLOCK
debug3: fd 15 is O_NONBLOCK
debug1: channel 7: new [direct-tcpip]
debug3: send packet: type 90
debug1: Connection to port 1088 forwarding to localhost port 88 requested.
debug2: fd 16 setting TCP_NODELAY
debug2: fd 16 setting O_NONBLOCK
debug3: fd 16 is O_NONBLOCK
debug1: channel 8: new [direct-tcpip]
debug3: send packet: type 90
I tried to tcpdump, and locally there are tries to connect, but cannot find any packages received to the other site.
I edit out all other information in the krb5.conf.
What I am missing here or is this possible at all?
PS:
netstat says the ports are existing and opened on both machines.
I have no problem to kinit on the server itself.
PSS:
From what I see the kdc is actually listening at port udp 88 not tcp, could this be a problem?
I resolved it after all by using socat and ssh as follows, and several tutorials:
We are receiving udp packages to 1088, but ssh tunnels only tcp, so with socat we can "transform" them:
locally$ socat -T15 udp4-recvfrom:1088,reuseaddr,fork tcp:localhost:1089
Now we create ssh tunnel of that port to the remote server by
locally$ ssh -L1089:localhost:1089 remote_server
After that we transform the tcp packages arriving at 1089 to udp and redirect them to the kdc at port 88 vie
server$ socat tcp4-listen:1088,reuseaddr,fork UDP:localhost:88
Instead of having to tunnel UDP traffic as well, you could force kerberos to only use tcp as following:
[realms]
MY.REALM = {
kdc = tcp/localhost:1088
master_kdc = tcp/localhost:1088
admin_server = tcp/localhost:1749
}
And now setup your tcp/ssh tunnel as before:
ssh -L1088:kdc.server:88 -L1749:kdc.server:749 ssh.hop
I mount a SSH port forwarding tunnel to a remote server RemoteServerSSH and forward the 55555 port to a non-existing equipment (this is what I try to test).
$ hostname
MyMachine
Setting the forwarding tunnel
$ ssh -q -N -p 22 -vvv \
-i ~/.ssh/MyKey \
-o Compression=yes \
-o ServerAliveInterval=3 \
-o serverAliveCountMax=3 \
-L *:55555:RemoteDownItem:9100 user#RemoteServerSSH
Testing the tunnel
When I telnet the device directly I got the correct behavior (not connected). However, when I try to reach it through the tunnel, telnet says it's connected:
$ telnet RemoteDownItem 9100 # Not Connected = OK
$ telnet MyMachine 55555 # Connected! Why? should be same as above
When I measure the telnet time connection, it is instantaneous (1ms!).
It is the SSH client that answers me, it does not cross the ssh tunnel! Why ?
Verbose
...
debug1: Local connections to *:55555 forwarded to remote address 10.220.9.183:9100
debug3: channel_setup_fwd_listener: type 2 wildcard 1 addr NULL
debug1: Local forwarding listening on 0.0.0.0 port 55555.
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [port listener]
debug3: sock_set_v6only: set socket 5 IPV6_V6ONLY
debug1: Local forwarding listening on :: port 55555.
debug2: fd 5 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new [port listener]
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Connection to port 55555 forwarding to 10.220.9.183 port 9100 requested.
debug2: fd 6 setting TCP_NODELAY
debug2: fd 6 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK
debug1: channel 2: new [direct-tcpip]
Question
Is there an SSH parameter to forward the telnet connection directly to the endpoint?
Project Related Question
Telnet connect to non-existing adress
Consider how a tunnel works. When you run something like ssh -L *:55555:RemoteDownItem:9100 user#host, the port forward is handled like this:
The local ssh instance binds to TCP port 55555 and listens for connections.
An "originator" connects to port 55555 on the local system. The local ssh instance accepts the TCP connection.
The local ssh instance sends a "direct-tcpip" request through the SSH connection to the remote ssh server.
The remote ssh server attempts to connect to host "RemoteDownItem" port 9100.
At step 4, if the ssh server is able to connect to the target of the tunnel, then the ssh client and server will each relay data between the originator and the target through the direct-tcpip channel.
Alternately, at step 4, the server may not be able to make the TCP connection to the target. Or the server may be configured not to permit forward requests. In either case, it will respond to the client with an error (or a message saying the channel is closed).
At this point, the only thing that the local ssh instance can do is to close the TCP connection to the originator. From the perspective of the originator, it successfully connected to a "server" (the ssh client), and then the "server" almost immediately closed the connection.
The OpenSSH software doesn't contain any logic to handle this in a more sophisticated way. And handling it in a more sophisticated way may be difficult. Consider:
The remote SSH server has no idea whether it can connect to "RemoteDownItem" port 9100 until it tries. So it's problematic for ssh to figure out in advance that the port forward won't work.
Even if one attempt to connect to the target fails, the next attempt might succeed. So it's problematic for ssh to assume the port forward won't work, just because one attempt failed.
The remote SSH server could successfully connect to the target, and then the target could immediately close the TCP connection. So the ssh server, ssh client, and originator all have to handle this behavior anyway.
In a moment of weakness I sheepishly followed a tutorial on how to connect to my Amazon EC2 remote server bypassing a public library's Wifi ssh restriction.
So first thing I did was adding the following (last) line to my /etc/ssh/sshd_config file residing in my remote EC2 AMazon server:
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
ListenAddress 443
Then I restarted the ssh server and, in a genius move, logged out from my remote server. So when in my local machine I do this...
$ ssh -i /path/to/key.pem xxx#xx.xx.xxx.xx -p 443 -v
...I get this:
$ ssh -i /path/to/key.pem xxx#xx.xx.xxx.xx -v -p 443
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xx.xx.xxx.xx [xx.xx.xxx.xx] port 443.
debug1: connect to address xx.xx.xxx.xx port 443: Connection timed out
ssh: connect to host xx.xx.xxx.xx port 443: Connection timed out
If I try to ssh to default's port 22 I get this:
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xx.xx.xxx.xx [xx.xx.xxx.xx] port 22.
debug1: connect to address xx.xx.xxx.xx port 22: Connection refused
ssh: connect to host xx.xx.xxx.xx port 22: Connection refused
I also added the following line in my Amazon's EC2 'Security Groups'...
Custom TCP port 443
... to no avail.
Did I effectively locked me out of my remote server? I was following a tutorial on how to tunnel and then this happened. Shouldn't have just added to /etc/ssh/sshd_config...
Port 443
...instead of 'ListenAddress 443' ?
I have never had problems ssh'ing to my remote server before (which is a Debian Wheezy).
As far as I know I can still detach my volume, re-attach it into a new instance, fix the sshd_config file, etc. I hope there's an alternative to that.
So my question is: It is possible to connect to my remote server considering the line 'ListenAddress 443' in ssh_config ? If so, how? And perhaps more importantly, why is that I can't connect on Port 22 if I hadn't touched or changed anything n sshd_config besides the ListenAddress 443?
Thanks in advance!
Edit:
telnet xx.xx.xxx.xx 22
Trying xx.xx.xxx.xx...
telnet: Unable to connect to remote host: Connection refused
You can't connect because of one of three reasons:
sshd on the remote server is down because it can't parse ListenAddress 443.
sshd parsed ListenAddress 443 into an IP address ('443' can be interpreted as an IP address - an IPv4 address is represented at low levels by a 32-bit unsigned integer) but was unable to bind to the IP address represented by '443' and is down.
sshd parsed ListenAddress 443 into an IP address, successfully bound to that IP address, and is now running and listening for incoming connections on "0.0.1.187" or some similar interpretation of '443' as an IP address.