The reasoning behind your current setup is probably some combination of the following three reasons.
The VPN is a security solution for outside your company's network (See #1 below). SSH however, might be a second layer of security outside of your company's network... but its main purpose is to secure the traffic within your company's network (See #2 Below)....
SSH is an extremely popular target for brute-forcing attempts. If you have an SSH server directly on the Internet, within minutes, you will see login attempts with all kinds of user names (and passwords) - often thousands per day even on small insignificant servers.
Now it is possible to harden SSH servers (the main three mechanisms are requiring an SSH key,...
Preventing outbound ssh connections, and thus any tunnels, would require a complete blockade of outbound connections via deep packet inspection. Looking at ports will be 100% useless. You have to look at the actual packet payload to know it's SSH. (this is what websense is doing.)
The only other option is setting up a "proxy" host. Lock down the ...
Unfortunately the ASA doesn't show a good explanation in the error message. It's required to create an RSA key on the ASA, either via console or command line in the ASDM, executing the command crypto key generate rsa, for example with highest possible modulus size:
crypto key generate rsa modulus 2048
in global configuration mode. The default modulus would ...
ssh version 2 for IOS 12.1(19)E and later
SSH from one switch to another... for reasons I can't explain, Cisco calls SSHv2 SSH-1.99...
SRV1#debug ip ssh client
SSH Client debugging is on
Jun 4 13:45:28.747 CDT: SSH1: sent protocol version id SSH-1.99-Cisco-1.25 <-----
Jun 4 13:45:28.787 CDT: SSH CLIENT0: protocol ...
(Examples performed on ISR 1921 G2)
Before we get into the details, I would suggest that instead of backing up your key, you just pull the new key from the new router and update your scripts. You will need to get onto the router without SSH to load the config/enable SSH anyways. This can be done with a script and console cable... you can even pull the new ...
Backing up the host keys to replace them is more trouble than it's worth.
If you don't want your scripts to barf on key changes (in *nix), run ssh like this...
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@hostname
This tells the ssh client to use an empty Known Hosts file and do not force strict key checks.
As mentioned in the ...
I got response from Cisco Tech support and there are a few things not correctly described in the manual.
First, ASR router supports key size 1024 bit or smaller contrary to its manual(supporting up to 2048 bit key).
Second, only the key part of SSH public key must be 'de'coded w/ base64 en/decoding program.
SSH Key Generation
ssh-keygen -b 1024 -t rsa -f ...
It looks like, "No". There's nothing specific in TACACS+ to transport a certificate exchange, however an ASCII data payload could suffice. (the RFC is a decade old) The real question is if ACS has any method to handle it? And that also appears to be "no". The only mention I can find to PKI or certificate based authentication is for EAP-TLS, which is not ...
There is another method, if you're merely looking at stopping people from using SSH as a proxy workaround why not rate limit it to say 20kB/sec or so, that ends up painful enough for web, but imperceptible for console use.
If you wanted to allow file transfers at normal speed this wouldn't be an option though.
Junos's /etc/ssh/primes file had an off by 8 bug. That is, moduli in that file advertized to be 2048bits, were in fact 2056 bits long.
Cisco SSH client is very strict in this regard, and hence refuses to proceed. As a work around, delete /etc/ssh/primes file from your Junos device. This will cause Junos to use Group14 moduli.
The ability to SSH to the firewall and ping outbound are usually two unrelated events and configuration. Since you're unable to ping the firewall's own 192.168.0.10 from itself, the interface appears down.
After ensuring vlan 100 is up/up, you'll need both a crypto key for SSH and a statement like ssh 192.168.0.0 255.255.255.0 inside to permit all inside ...
switchport mode access
switchport access vlan 1
switchport mode access
switchport access vlan 1
interface vlan 1
ip address 220.127.116.11 255.255.255.0
This should be the bare minimum configuration to get your scenario working, at least some IP connectivity.
The VPN allows you to connect to your employer's private network and acquire an IP address of that private network. Once you're connected to the VPN, it's like you are using one of the computers inside the company -- even if you are physically located on the other side of the world.
Most probably, your employer requires you to connect via VPN first because ...
If you control the SSH server and the firewall then you can control access by blocking access to whatever port the SSH server is using (22 by default). Unless the port has previously been opened, then inbound connections are likely to be blocked anyway, although you'll probably found that outbound connections will be allowed. With the right design and ...
For some reason the Juniper documentation (http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/command-summary/ssh.html) doesn't mention it, but it is possible. The command is:
does anyone have experience with these things?
Centuries, actually. And that experience says to leave things you know very little (or nothing) about alone, especially when they're systems that (a) work, and (b) have worked for years. Live with it for a few years before declaring it crap.
I call this "new kid syndrome"; the guy comes in, and from day-one ...
Your SSH client is saying "we can't agree on the cipher: server wants X but I'm configured not to speak X". This is a completely general SSH problem, not specifically related to this model of switch, which is that the SSH clients are regularly changed, usually to disallow older, weaker, ciphers. This isn't about key length, it's about cipher algorithms.
General-purpose key pairs may be used for multiple purposes, including SSL (e.g., for the HTTPS management interface) and IPsec. The SSH key pair is reserved for SSH and no other tasks.
One practical difference in management between IPsec/SSL and SSH keys is that the former are typically signed (either by a public CA or by a company's in-house certificate ...
It isn't necessary to create a domain name to create SSH keys. The below syntax will allow you to generate RSA keys for SSH use without one.
router(config)#crypto key generate rsa general-keys label RSAKEY
You can use an application called ser2net to make use of USB to serial cables. There is a 4x serial -> one USB available which would cover 4x switches. That way you get virtual USB ports like ttyUSB0, ttyUSB1, ttyUSB2, ttyUSB3. You can then map these USB ports to TCP ports like:
2001:telnet:600:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT banner
The DNS is issued by default from your local host, not from the proxy, when using SOCKS (probably because SOCKS4 didn't support other way).
Make sure you have checked the checkbox "Remote DNS" in the Proxy configuration of the Firefox:
You'll need to have a hostname and a domain and generate the keys for ssh to work. My notebook says:
ip domain name example.com
crypto key generate rsa modulus 2048
ip access-list standard LEGIT
permit 192.168.2.0 0.0.0.255
line vty 0 4
access-class LEGIT in
privilege level 15
transport input ssh
As no one else has mentioned it ... ...
I would pick up a cheap Cisco router/ASA/pix device and set it up with port forwarding/DMZ on the ATT router so all packets going to your public IP that aren't receiving traffic for connections like your wife, go to the router/ASA/pix. Then I would configure it as a remote VPN termination point.
An ASA5505 will probably set you back $200. But you might be ...
SSH is an encryption protocol used for several things. Encrypting traffic in a VPN tunnel is one of them. Your traffic is encrypted using SSH, but it then needs to be wrapped in valid IP packets (tunnel) to traverse a network like the Internet. This tunnel is the VPN.
Basically, your employer blocks outside network traffic, for security, unless that traffic ...
You need the VPN to get into the local network.
You don't then need to secure your connection to individual servers, as it'll already be encrypted by the VPN link.
However, how else would you connect to them? SSH is the de facto console access protocol for remote servers; installing and configuring an unsecure one would be an additional management overhead,...
If we ignore all the cryptography involved in the Confidentiality and Integrity services that both of these services provide, the only main remaining difference between SSH and SSL are how they engage the concept of Authenticity. Authenticity is the process of confirming the other party of the communication is indeed who they say they are. Both protocols ...