Skip to main content

Enabling SSH on a Cisco Router for Secure Remote Login

  1. Ensure you have a hostname configured on your router:
    Router#conf t 
  2. Router(config)#hostname router23
  3. You must also configure a domain name:
    Router(config)#ip domain-name jpt
  4. Generate an RSA keypair with a key length of 1024 bits using the following sequence of commands:
    router(config)#
    router(config)#crypto key generate rsa
  5. The name for the keys will be: routername.soundtraining.class (where routername is your router's hostname)
  6. Choose the size of the key modulus in the range of 360 to 2048 for your
      General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.
  7. How many bits in the modulus [512]: 1024% Generating 1024 bit RSA keys ...[OK]
  8. Create a username in the router’s local database for SSH authentication using the following command (for the purpose of the exercise, use the username “user15”):
    router01(config)#username user15 privilege 15 secret p@ssword
  9. Enable login authentication against the local database when logging in to a terminal line with the following commands:
    router01(config)#line vty 0 15
  10. router01(config-line)#login local
  11. router01(config-line)#exec-timeout 0 0
  12. router01(config-line)#logging synchronous
  13.  router01(config-line)#transport input ssh

Comments

Popular posts from this blog

Cisco SG300 CLI Commands

Cisco SG300 CLI Commands Other parts were obtained using the CLI PDF provided by Cisco Remove a Trunk and switch to access config t int gi44 switchport trunk allowed vlan remove 2 switchport mode access switchport access vlan 2 or config t int gi44 switchport mode general switchport general allowed vlan remove 2 switchport mode access switchport access vlan 2 Change CDP Device ID Format to Hostname opposed to default MAC address s-sg300#sh cdp Global CDP information:         CDP is globally enabled         CDP log duplex mismatch is globally enabled         CDP log voice VLAN mismatch is globally enabled         CDP log native VLAN mismatch is globally enabled         Mandatory TLVs validation is disabled         Sending CDPv2 advertisements is enabled         Sending Appliance TLV is enabled       ...

Branches, Part II

Now that we’ve covered the mechanics behind Git branches, we can discuss the practical impact that they have on the software development process. Instead of introducing new commands, this module covers how the typical Git user applies this workflow to real projects, as well as some of the problems that arise in a branched environment. To Git, a branch is a branch, but it’s often useful to assign special meaning to different branches. For example, we’ve been using master as the stable branch for our example project, and we’ve also used a temporary branch to add some CSS formatting. Temporary branches like the latter are called topic branches because they exist to develop a certain topic, then they are deleted. We’ll work with two types of topic branches later in this module. Amid our exploration of Git branches, we’ll also discover that some merges cannot be “fast-forwarded.” When the history of two branches diverges, a dedicated commit is required to combine the branches. This ...

Distributed Workflows

Now that we know how to share information via a centralized workflow, we can appreciate some of the drawbacks of this collaboration model. While it may be convenient, allowing everyone to push to an “official” repository raises some legitimate security concerns. It means that for anyone to contribute content, they need access to the entire project. This is fine if you’re only interacting with a small team, but imagine a scenario where you’re working on an open-source software project and a stranger found a bug, fixed it, and wants to incorporate the update into the main project. You probably don’t want to give them push-access to your central repository, since they could start pushing all sorts of random snapshots, and you would effectively lose control of the project. But, what you can do is tell the contributor to push the changes to their own public repository. Then, you can pull their bug fix into your private repository to ensure it doesn’t contain any undeclared code. If y...