Ofcourse you can specify bastion Jump host using option '-J' to ssh command, if not configured in config file. Note scp does not seems to support '-J' flag as of now. (i could not find in man pages. However above scp works with config file setting). Using scp, rsync and ssh requires the password unless you add the public key from src host to authorisedkeys on destination host.
Easy transfer of files to/from Cisco Router
As a consultant, I'm constantly working remotely with people but still need an easy way of transferring files with a router (captures, OS files, etc). This tip is 101 stuff but since I needed to help someone today with this I thought I would pass it along.My little scenario here is an example using IOS routers but I've also tested it on XE.
When I need to upload or download files to/from a router, I like to use SCP to transfer the files. I like this better then trying to stand up an FTP or TFTP server. This is especially handy when working with devices outside the firewall. SCP uses Secure Shell (SSH) to securely copy files. With SCP you connect directly to the device and transfer files back and forth. This is useful for transferring captures or OS files.
On the router, you'll need to enable SSH, AAA, and SCP.
Enable SCP on the router.
Starting in 6.0(2)N1(1), NX-OS also supports SCP.
Enable with:
On Mac or Linux, to push or pull the files, you can use the built in command line.
You don't have to but I suggest going to the directory on your computer where the file you want to upload is or where you want to download the file to. Open terminal on your Mac or Linux to run the commands below.
Download file:
In this example I'm downloading the file callfail to the current local directory. In case you don't catch it, the dot at the end means the current local directory.
In this example I'm downloading the file callfail to my Documents folder.
Upload file:
In this example I'm uploading the IOS from the local directory to the router.
If you happen to be on Windows, WinSCP and PSCP (from the makers of putty) are pretty popular. WinSCP is a GUI based option, PSCP is CLI like above.
Cisco Reference Doc:
http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_secure_copy_ps6922_TSD_Products_Configuration_Guide_Chapter.html
I recommend disabling the SCP server when not needed.
В качестве scp клиента можно пользоваться тем, что включен в пакет Putty.
Configuring and using scp and sftp
If the security risks of FTP are simply too much for you to deal with, consider switching to the secure suite of tools distributed by OpenSSH. OpenSSH offers secure versions of all the old familiar remote access and transfer tools, like Telnet (replaced by ssh), FTP (replaced by sftp), and rcp (replaced by scp). The client and server for each of these tools is preconfigured so that it's ready to go as soon as you log in for the first time on most modern Linux distributions. OpenSSH tools are everywhere: Every version of Linux, Solaris, PalmOS, Mac OS X, and Windows all have functional ports and user clients.
| Note | OpenSSH is installed by default on all Fedora Core server installations. If you choose another type of installation, you will need to install OpenSSH by hand before you can use it. |
OpenSSH tools are not just for logins and file transfers. They can even be used to make insecure protocols behave more securely in much the same way as SSL allows web traffic to travel safely between a browser and a server. In fact, many insecure protocols can be tunneled securely over a remote SSH to local SSH machine connection, including X11, POP3, Telnet, SMTP, rsync, and so forth.
OpenSSH and Fedora Core
Fedora Core gives you all the OpenSSH tools you need, straight out of the box. If you select the regular server installation, you'll see these packages on your system after installation is complete:
You will have the base OpenSSH package, some password authentication programs for the X11 GUI environment, all the OpenSSH clients including ssh, scp, and sftp, and the OpenSSH server itself, sshd. Though you can start using the OpenSSH tools right away, it's best to spend a few minutes configuring sshd so that it does precisely what you want it to.
Configuring sshd
The sshd daemon takes its configurations from the /etc/ssh/sshd_config file. As you can see later, most of the file is commented out. If you read the comments in the configuration file, you'll realize that most of these options are the default-compiled settings, but the settings are left in the file for reference. If you want to change how sshd behaves on your system, just remove the hash marks to uncomment a setting, and then change the setting from its default-compiled setting. Read through the sample file to see some of our suggestions for change:
This default setting indicates that when sshd runs, it first offers sessions in SSH v 2 protocol to the connecting client, and then falls back to the SSH v1 protocol if required by the client. SSH 2 is more secure than the older version 1, and v1 has many known vulnerabilities. The only reason to run it is that some older ssh-based commercial packages require it. Don't run SSH v1 on your server. If you uncomment and edit this line, you can force your SSH daemon to offer only SSH v 2 to incoming clients. To do this, remove the hash mark and the trailing ,1 so that the line simply reads Protocol 2.
By default, the sshd service binds to all IP addresses associated with your server. If sshd is running on a firewall or on a multi-LAN server, you might choose to remove the hash mark and change the line ListenAddress 0.0.0.0 to something like ListenAddress 10.1.1.1 to restrict SSH logins to a particular side of your network.
| Note | This configuration file is longer and more complex than what you see here. We're showing you only the most commonly tweaked settings. |
The last two lines in the preceding code block enable key-based authentication. SSL, SSH, and other modern encryption methods use dual-key encryption, a method that requires both a public and a private key to encrypt and decrypt a secure session or data stream. If you turn on key-based authentication in sshd, you remove the username/password authentication step and allow access only with a known set of keys. This is not necessarily more secure, as it now ties security to the remote trusted host's own security. However, this setting is often the only viable solution if you need remote automation scripts and other back-end programs to log into systems without requiring a human to type in a password.
| Caution | You probably should not enable key-based authentication unless you are in a provably secure environment AND you trust everyone on your LAN plus everyone who has access to the server AND your security honchos approve it as an acceptable security policy. |
The X11Forwarding yes setting permits users to tunnel server-side X11 client programs and output over SSH to the local X11 GUI (called the local X11 server). That is, you could ssh into a remote system, start the Mozilla browser from the command line on the server, and get the GUI window for the Mozilla program running on the remote server 'painted' on your local desktop X GUI. Imagine being able to run GNOME, KDE, and Linux applications off your Fedora Core machine while sitting in front of a Windows PC in a lab across the country, or running a system load graph for each of your servers on your local desktop. This is a powerful feature. It's safe to leave this function enabled, even if you never use it. Just be aware that you might get an unexpected window on your local machine if you're issuing commands over an ssh session.
The final line in the file turns on the sftp subsystem of sshd. It is enabled by default in most modern Linux distributions. If you can get into your server via ssh, then you can probably access sftp resources with the sftp client as well.
Configuring OpenSSH Services
Once you've determined that all the appropriate packages are on your system and made your basic sshd configuration file changes, it's time to check the server-side service. Everything you need to run OpenSSH services is managed by the sshd daemon. Verify that the daemon is running with the command
or the optional Red Hat command
If the daemon is running, you can use this command to stop and restart it in order to reload the changes in your config file:
In fact, you can do this while connected to the server through an SSH connection, and never lose the session. Just another reason why OpenSSH tools are the new de facto standard for remote Linux/UNIX access.
Finally, you should ensure that sshd will come up when the machine is booted and when runlevels change. The easiest way to do this is with the init script control tool chkconfig. First, check the existing configuration for the sshd service:
Since most servers boot into runlevels 3 and 5 almost exclusively (on Red Hat-other distributions may use different runlevels), these settings are appropriate for almost all cases.
If you want to configure the server so that it will not run a service such as sshd at boot time, you can turn the service off in all runlevels like this:
Check it again:
| Note | This shows that the service will be started when the server comes up into runlevels 2, 3, 4, or 5 (levels 0, 1, and 6 are for shutting down, single user or 'safe mode', and rebooting, respectively). See Chapter 5 for more information on runlevels. |
When you're ready to configure it to be on at boot time again, use chkconfig to turn the service on and verify that the runlevels are correct (most network services are configured to come up in either 2-5 or 3-5):
| Note | The chkconfig control tool only defines boot and runlevel settings for a given service or daemon when the entire system changes state (boots or changes runlevels). It does not start or stop a service in real time. If you need to make sure that sshd does not start after a reboot (set it to 'off'), as well as stop the sshd service now running, then you should use this command sequence: |
which will configure the daemon to be off at boot time or runlevel changes, and then run
to gracefully shut down a running daemon, such as sshd, in real time (the latter is the optional Red-Hat-based init script usage). The opposite of these commands would be the usage of 'on' and 'start' respectively.
| Caution | If you use the /etc/init.d/sshd stop option remotely over ssh, it will also end your session. The only way to get back into a system with a stopped sshd service like this would be to visit the machine physically, since you have turned off the service that provides access. |
Using SCP
You're fully configured and ready to go. How does scp work? Just like cp, or scp's older cousin rcp(remote copy), it works only through an encrypted network connection. For example, assume that the user bob wants to copy everything from his current desktop to a remote server at bobsdomain.org. In the current directory, he has the following files:
Bob doesn't have much more than a few files and some subdirectories. To copy the files, he issues the following command:
At this point, Bob must confirm that he wants to save the public key from the remote machine. This will speed connection to this site in the future. The remote machine prompts for a password, and the file transfer begins:
Note that scp did not do a recursive copy, and rejected the PACKAGES subdirectory. So the files did not get copied. To do so, Bob must specify recursive scp when he issues the initial command:
In this instance, the contents of the PACKAGES subdirectory and the directory itself were also copied over.
| Note | The second scp example used both the - - r (recursive) and - - p (permissions) switches. Remember that you adopt the username and UID of the remote user, but files retain your local permissions. If you're backing up a system and you want to preserve all user/group and UID/GID information, tar is probably a better solution. |
The scp tool is best for pushing and pulling files between system accounts and across networks, especially when the receiving user is going to adopt ownership of the files. One common use is to match scp with cron to push common system files, like /etc/hosts, nsswitch.conf, or resolv.conf, out to multiple machines on a network.
| Tip | If you want to offer scp access but don't want to give shell access, consider scponly. It's a bash shell replacement for scp. Just install and then add it to /etc/shells as a valid shell choice. You can now give remote users access over scp and sftp without giving them login privileges and a command line over SSH. Learn more at www.sublimation.org/scponly/. |
Key-Based Authentication for ssh, scp, and sftp
In some cases, you may prefer to enable key-based authentication rather than require users to type username/password pairs at login. As explained above, key-based authentication can be quite handy. If used by itself, it is less secure; however, it is sometimes the only way to automate systems smoothly and remove human intervention from the process.
To turn on key-based authentication, open the /etc/ssh/sshd_config file and locate the line beginning with #RSAAuthentication. Make sure that it is commented out, and that the PubkeyAuthentication line is active and set to yes:
After you change the configuration file, you'll need to restart sshd:
Now, when the user Mike requests ssh access, sshd will look in /home/mike/.ssh /authorized_keys to see whether this person has an authorized public key that can be trusted as Mike's key. How did the key get into his ~/.sshd/authorized_keys file in the first place? Someone put it there, probably either Mike or his root administrator.
Key Pairs
In order to work with key-based authentication, you must follow several steps. First, you need to generate a public/private key pair. Once you have a public key, you can put it into an ~/ .ssh/authorized_keys file (where ~ = /home/username/ ) so that you can access the account. To generate a key pair, follow this command sequence:
The output of ls --la.ssh/ shows the user Mike's private and public (.pub) dsa-based key files on his home machine. Assume that Mike needs to log into the remote system at work mydomain.com, and do so without a password. In order to do this, Mike's home public key needs to be placed in his ~/.ssh/authorized - keys file on the remote machine at work. First, from home, Mike prints his home dsa public key file to the screen:
| Tip | Notice the comment at the end that identifies this key as mike_home. This is a very useful trick, as it is nearly impossible to identify keystrings merely by reading them. It's wise to create separate public keys for work, home, laptops, and so on; the more keys you use, the more you need to keep them clearly marked. |
Mike then highlights the public key with his mouse and copies the text. Next, Mike uses ssh to log into his remote account at work (a password is still required at this point):
Next, Mike edits his remote ~ /.ssh/authorized_keys file, or creates it if it does not exist:
| Note | Notice how the prompt changes from Mike's home [mike@local host mike]$ to [mike@mydomain.com mike]$ at his work account. |
Mike now pastes the copied text of his public key, saves the file, and exits the text editor. His account now looks as follows:
The files look right, but the permissions are wrong. Both the authorized_keys file and the id_dsa (private key) should be readable only by the user who owns them. Use chmod authorized_keys to fix this:
| Note | This is probably the most common problem with key-based authentication. Both the authorized_keys file and the .ssh directory should be set to rwx------ (700). If you don't chmod them both to 700, sshd will simply ignore one or both, and key-based authentication won't work. |
Mike logs out of his remote work machine and then logs back in to see if the authorized_keys entry worked. If login no longer requires a password, then the key-based ssh authentication is working:
With this in place, Mike can now automate almost anything between his home and work account, whether it's pushing web content, bookmark files, or daily logs.
| Note | While this will allow Mike to easily push things to work, or pull them back home from work (using ssh, scp, or sftp), this will not allow the mike user at work (mydomain.com) to automatically push things home, or pull things from home to work. To do this, Mike would also need to put his work public key in his home's ~.ssh/authorized_keys file. |
For example, Mike might set up a regular job that copies web content from his home machine to his work machine. The following crontab entry will tar-gzip Mike's home web content
every Sunday at 1:37 A.M. and scp it to his work's ~/BACKUPS/ directory:
User Clients
One of the nice things about OpenSSH's SSH suite is that users can use whichever client they prefer: scp, sftp, or ssh. You don't need a GUI client at all. For example, the stock OpenSSH command line sftp client works perfectly:
When you installed the complete OpenSSH suite as part of the server installation, the openssh-clients package was included. It includes all the command-line clients. However, you and your users aren't limited to command-line clients. Both GNOME and KDE offer a number of GUI tools and clients that work with and use OpenSSH. For example, if you point KDE's Konqueror web browser to the URL sftp://mydomain.com and you don't pass key-based authentication, a login window automatically pops up (Figure 18-1).
Figure 18-1: KDE's Konqueror browser is SSH-aware.
Scp Ssh Copy
Table 18-1 shows some popular clients for scp and sftp. No matter the platform they use, your do users have some choice.
Windows | WinSCP (scp and sftp) WS-FTPPro (sftp) PuTTY (SSH, scp, and sftp) |
UNIX/Linux | Konqueror (sftp) GFTP (scp and sftp) |
Mac OS X | Fugu (sftp) Rbrowser (scp and sftp) |
SSH and Firewalls
If the sshd daemon is running and you can't get in with ssh, sftp, or scp, you may have selected install-time firewall configurations that lock the box down to the point where it can't be used as a server. While it's always good to start as securely as possible and then grant access, a server machine needs some freedom in order to do its work. You can see whether you inadvertently blocked SSH sessions by asking iptables what rules it is running:
Since there are no ACCEPT rules for SSH/port22 connections in this output, your SSH connections are being killed by the final line (REJECT all). This is a very secure setup, but it defeats the purpose of the server. To get your SSH connections working, you need to edit the /etc/sysconfig/iptables file (on Red-Hat-based systems) and insert the iptable rule for ssh so that it looks like this:
The second line from the bottom shows that SSH is now a trusted protocol from anywhere. You must now restart the iptables service. When it restarts, people should be able to connect through SSH.
Ssh Scp Command
| Tip | For a more friendly version of this configuration on all Red-Hat-based systems (including Fedora Core), type redhat-config-securitylevel to get the GUI configuration tool. Check the box next to SSH, and click OK to enable this ruleset change. The new rule will be saved to /etc/sysconfig/iptables, implemented, and will be loaded and used after all reboots. |