SSH connection Lost after switch accessmode vlan * - ssh

When I attempt to assign a port (say Gi1-2) to a vlan other than vlan 1, the SSH connection is lost upon firing the switchport access vlan command.
I have created 2 VLANs (10,20) in addition to the default vlan 1. The PC I am using to access the switch is connected to Gi10. When I try to assign that port to one of the vlan’s (say vlan 10), the connection locks up.
Here are the commands I am using
Switch# configure terminal
Switch(config)# interface range Gi1-2
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
<<--- terminal doesn’t respond anymore ---->>
Before configuring the same, vlan 1 (default vlan) is assigned with an ip address (192.168.1.254).
After this if I try to connect to the switch via SSH, the switch is no longer seen on the network from this PC.
If I switch the cable to another port, then I can connect to it. So, I am assuming that since the ports are on Vlan 1, they are accessible via SSH.
Also tried this under telnet, with the same results.
Any suggestions are welcome.

what do you mean when you say you create vlan 10 and 20, do you assign them IP address ? you understand that vlan and int vlan are 2 different things. SVI is a logical interface where as vlan logical network (broadcast doamin)

Related

SSH not working locally but is working externally after running nmap

I need to be able to SSH into a device on my network. Normally I am able to simply ssh into its local IP address.
I recently ran an nmap scan on it, and now when I try to ssh into its local IP address, I recieve the following:
kex_exchange_identification: read: Connection reset by peer
Connection reset by <IP> port 22
This network is setup in a somewhat unique way. It has one router that manages the Wi-Fi network (what my machine is connected to) which is connected to another box that also acts as the modem. IP addresses that are connected to the Wi-Fi box start with 192.168, whereas those connected to the modem box start with 10.0. The device I am trying to access is connected to the modem box.
Historically, just typing in its 10.0. local address has allowed me to ssh into it with no issue, even though my device is on the 192.168 network, and arp -a does not show it.
Checking the ssh logs of the device via journalctl -fu ssh, I can see that every failed ssh attempt is accompanied by the following message:
Connection reset by 10.0.0.96 port 49949 [preauth]
I do not recognize the IP above, and the port changes every time.
Is this some sort of anti-spam protection that was triggered by my use of nmap? I know it's not just my computer because I am unable to ssh into the device from anything else on my network.
Note that connecting to a VPN then using SSH to connect to the external IP address (which is port-forwarded properly) works, as does connecting via ssh to the machine from the machine itself (127.0.0.1)l
How can I fix this issue?

SSH Not Working with Cisco Integrated Services Router

I'm trying to ssh into my cisco ISR router. DHCP is working and I can ping the default gateway (the ISR), and can ssh with other devices on the LAN. so I know the LAN connection isn't the problem. I set up a local user that works with console logins so that's not the problem either.
I set up my ssh connection on the router with the following commands:
(config)#line vty 0 21
(config-line)#login local
(config-line)#exec-timeout 3
(config-line)#rotary 1
(config-line)#transport input ssh
(config)#crypto key generate rsa
(config)#ip ssh version 2
(config)#ip ssh port 2222 rotary 1
(config)#ip ssh authentication-retries 3
Then when I nmap the router it has the following ports open:
PORT STATE SERVICE
22/tcp open ssh
However, every time I try to log in to the router I get a Network is unreachable error. This is using the 2222 and 22 port and testing the normal IP and the hostname#ip formats for ssh and absolutely nothing works. I managed to get into telnet with the default settings earlier, but I'm not sure how to get in with SSH.
Thank you all for the help, I know it was very open ended so just let me know anything that could be helpful and I'll provide it.
One logical test step to do, would be switch back to port 22.
Network unreachable usually indicates there's no packet response coming from the host.
It could be because of multiple reasons, but since you've mentioned that ping and telnet went fine. I'd suggest you revert the port config, restart the unit once. See how it goes.
Other possible reasons could be ACL block and/or firewall block on your machine but I think it's unlikely.

SFTP, SSH & SSH Tunneling

I would like to understand the concept of SSH tunneling in detail as I am learning a few things around this topic. I have gone through some details in public forum but still got a few questions.
An SFTP service is running in a remote server and I have been given credentials to connect to it. I am using GUI like WinScp to connect the remote server. What's the role of SSH tunneling here?
Remote SFTP Server admin asked me to generate RSA public key from my machine and its added to the remote server. Now, I can directly connect to the server from SSH terminal without password. What's the role of SSH tunneling here?
Is tunneling implicit or need to be called explicitly for certain circumstances?
Please clarify.
SSH tunneling, SSH console sessions and SFTP sessions are functionally unrelated things.
They can be used simultaneously during single session but usually it is not the case so do not try to find any relation or role of tunneling in ssh/sftp session.
It does not makes sense to mix ssh tunneling with multiple ssh/sftp sessions.
Basically you would use dedicated ssh session for tunneling and extra sessions for console and transfers.
What the heck SSH tunneling is?
Quite often both parties (you and server) reside in different networks where arbitrary network connections between such networks are impossible.
For example server can see on its network workstation nodes and service nodes which are not visible to outside network due to NAT.
The same is valid for the user who initiates connection to the remote server:
so you (ssh client) can see your local resources (worstation nodes and server nodes) but can't see nodes on network of remote server.
Here comes ssh tunneling.
SSH tunnel is NOT a tool to assist ssh related things like remote console ssh sessions and secure file transfers but quite other way around - it is ssh protocol who assists you with building transport to tunnel generic TCP connections the same way TCP proxy works. Once such pipe is built and in action it does not know what is getting transferred via such pipe/tunnel.
Its concept is similar to TCP proxy.
TCP proxy runs on single node so it serves as acceptor of connections and as iniciator of outgoing connections.
In case of SSH tunneling such concept of TCP proxy is split in two halves - one of the nodes (participating in ssh session) performs role of listener(acceptor of connections) and second node performs role of proxy (i.e. initiates outgoing connections).
When you establish the SSH session to the remote server you can configure two types of tunnels which are active while your ssh connection is active.
Multiple ssh clients use notations like
R [IP1 :] PORT1 : IP2 : PORT2
L [IP1 :] PORT1 : IP2 : PORT2
The most confusing/hard part to understand in this ssh tunneling thing are these L and R markers/switches(or whatever).
Those letter L and R can confuse beginners quite a lot because there are actually 6(!!!) parties in this game(each with its own point of view of what is local and what is remote):
you
ssh server
your neighbors who want to expose theirs ports to anyone who sees the server
your neighbors who want to connect to any service server sees
anyone who sees the server and want to connect to any service your
neighbor provides (opposite side/socket of case #3)
any service in a local network of server who wants to be exposed to
your LAN (opposite side/socket of case#4)
In terms of ssh client these tunnel types are:
"R" tunnel (server listens) - YOU expose network services from your LOCAL LAN to remote LAN (you instruct sshd server to start listening ports at remote side and route all incoming connections )
"L" tunnel (you listens) - Server exposes resources of its REMOTE LAN to your LAN (your ssh client starts listening ports on your workstation. your neighbors can access remote server network services by connecting to the ports of your workstation. server makes outgoing connections to local services on behalf of your ssh client)
So SSH tunneling is about providing access to the service which typically is inaccessible due to network restrictions or limitations.
And here is simple conter-intuitive rule to remember while creating tunnels:
to open access to Remote service you use -L switch
and
to open access to Local service you use -R switch
examples of "R" tunnels:
Jack is your coworker(backend developer) and he develops server-side code at his workstation with IP address 10.12.13.14. You are team lead (or sysadmin) who organizes working conditions. You are sitting in the same office with Jack and want to expose his web server to outside world through remote server.
So you connect to ssh server with following command:
ssh me#server1 -g -R 80:ip-address-of-jack-workstation:80
in such case anyone on the Internet can access Jack's current version of website by visiting http://server1/
Suppose there are many IoT Linux devices (like raspberry pi) in the world sitting in multiple home networks and thus not accessible from outside.
They could connect to the home server and expose theirs own port 22 to the server for admin to be able to connect to all those servers.
So RPi devices could connect to the server in a such way:
RPi device #1
ssh rpi1#server -R 10122:localhost:22
RPi device #2
ssh rpi1#server -R 10222:localhost:22
RPi device #3
ssh rpi1#server -R 10322:localhost:22
and sysadmin while being at server could connect to any of them:
ssh localhost -p 10122 # to connecto first device
ssh localhost -p 10222 # to connecto second device
ssh localhost -p 10322 # to connecto third device
admin on remote premises blocked ssh outgoing connections and you want production server to contact bitbucket through your connection...
#TODO: add example
Typical pitfalls in ssh tunneling:
mapping remote service to local priviledged port
ssh me#server -L 123:hidden-smtp-server:25 # fails
#bind fails due to priviledged ports
#we try to use sudo ssh to allow ssh client to bind to local port switches
sudo ssh me#server -L 123:hidden-smtp-server:25 # fails
#this usually results to rejected public keys because ssh looks for the key in /root/.ssh/id_rsa
#so you need to coerce ssh to use your key while running under root account
sudo ssh me#server -i /home/me/.ssh/id_rsa -L 123:hidden-smtp-server:25
exposing some service from local network to anyone through the public server:
typical command would be
ssh me#server -R 8888:my-home-server:80
#quite often noone can't connect to server:8888 because sshd binds to localhost.
#To make in work you need to edit /etc/ssh/sshd_config file to enable GatewayPorts (the line in file needs to be GatewayPorts yes).
my tunnel works great on my computer for me only but I would like my coworkers to access my tunnel as well
typical working command you start with would be
ssh me#server -L 1234:hidden-smtp-server:25
#by default ssh binds to loopback(127.0.0.1) and that is the reason why noone can use such tunnel.
#you need to use switch -g and probably manually specify bind interface:
ssh me#server -g -L 0.0.0.0:1234:hidden-smtp-server:25

IP not getting released from interface - Redhat 7

I am trying to use a single IP as a "floating IP" by assigning it to a secondary interface eth1 between 2 VMs. The primary interface eth0 has 2 different IPs for both VMs. Only one of the VMs will have the IP assigned to eth1 at any given time. If we have any issues with the primary VM we will unassign the IP from eth1 of the primary VM and reassign it to the secondary VM.
We are unassigning and assigning the IP using -
/sbin/ip addr ${ACTION} ${IP} dev ${INTERFACE}
However once we unassign the IP from eth1 of the primary VM and assign it to eth1 of the secondary VM I am unable to ssh to the secondary VM right away. I get a -
ssh: connect to host x.x.x.x port 22: Connection timed out
After about 15 mins some cache somewhere gets cleared and then I am able to ssh to the secondary box.
Have the following setting already updated in sshd_config and sshd has been restarted.
GSSAPIAuthentication no
UseDNS no
We are using Redhat 7.6
Any help in the troubleshooting what could be causing the delay in ssh'ing to the secondary box is much appreciated!
Thanks!
Your issue is with your network gear and the clients arp tables.
After you change the address check your arp tables with arp -a on Linux and show ip arp (Cisco gear). You will see the old MAC address maps to the old server IP.
After you change ip addresses send a gratuitous arp and that will force everything to update.
Assume your ethernet address is 10.0.10.1 and you are using eth1.
yum install arping -y
arping -A -I eth1 10.0.10.1
This very similar to what VMware does when you VMotion a VM to another host. It sends an RARP to notify the network the MAC address has moved to different a port.
EDIT: Also note, in older RHEL ver ifup-eth script used the arping tool to send a GARP. That means I might also try ip link set eth1 down and ip link set eth1 up see if that works.
This issue got resolved. We had to update the arp neihbor cache to get this to work so incorporated that into our script.

cannot connect to internet from virtual machine

I am using Vmware Player to use Ubuntu 14.04 but I am unable to get any internet connection in my virtual machine even though my system is connected to the internet. The original OS in my system is Windows 7. Can anybody suggest the way out.
Found the solution by browsing through multiple threads. Compiling it here.
EDIT : Please check if your network is in bridged mode or not if you are using VMWare/ VirtualBox before following the steps below. Enabling bridge mode and restarting guest OS can resolve the issue.
First check if your network is disabled by using the following cmd in terminal:
sudo lshw -C network
If it shows disabled after the name of your adapter ( note down the logical name for later use)
*-network DISABLED
description: Ethernet interface
product: 82545EM Gigabit Ethernet Controller (Copper)
vendor: Intel Corporation
physical id: 1
bus info: pci#0000:02:01.0
logical name: ens33
All we need to do is enable the adapter, so lets get started.
open up your interfaces file by using the following cmd:
sudo gedit /etc/network/interfaces
My file had the following data written:
auto lo
iface lo loopback
But the logical name of my NIC was ens33 ( not lo), so i changed it to read the following and saved the file.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto wlan0
iface wlan0 inet dhcp
Now time to restart the networking service.
sudo /etc/init.d/networking restart
check if network is back up, it shouldn't have that disabled tag anymore.
sudo lshw -C network
Enjoy your internet :)
If that doesn't work -> But as explained earlier change the network adaptor settings to bridged in your virtual machine settings.
If all that does not work, the best way to resolve the issue is
Restore your VM network settings
If you are using an older version download a new version (trial version would also work) - we are just updating your settings
Follow the steps:
Depending on how you are connected to the network, try either Bridged or NAT mode for the VM's network adapter. Keep in mind that you may lose connectivity from the host machine to the VM. In this case you'll need another network adapter.
In most cases NAT should work. In this case only your host machine's IP is visible to the network, and ports are allocated for the VM to communicate to the outside world. The problem is that you can't connect to the VM from the host machine if you need to. Add another adapter as I mentioned above and connect to its IP address. You will have two adapters - one for the Internet and the other for host-to-guest.
In the bridge mode the VM is visible to the outside network, so a network configuration is required that enables the VM to get an IP address and participate in the network (for example, network administrators may block unknown MAC addresses). The host machine talks with the VM as it were just a computer on the network.
Update your question with additional information if my suggestion does not work: guest OS, how your host computer is connected to the network, what the current configuration of the VM's network adapters is. Is it a home or a workplace computer?
UPDATE
So I guess if you are connected to a corporate LAN, then NAT will work while Bridge will not. To add another interface 1) add an adapter in VMWare Player; 2) Add an interface in Ubuntu. Assuming your existing interface is eth0, edit /etc/network/interfaces, adding these lines:
auto eth1
iface eth1 inet dhcp
Then restart the networking service:
sudo /etc/init.d/networking restart
UPDATE 2
Another reason for your not being able to connect to the Internet may be a proxy server. Make sure that the proxy configuration in the VM is the same as in the host machine.
CLose VM,
Go to VM Settings and Network adapters
Then click on adapter 1 and select Shared Networking NAT.
Start VM