Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Secure Shell (SSH) was originally developed by Tatu Ylцnen, Finland, as a secure replacement for Telnet, rlogin, rcp, rsh. It is based on so called Public-Key Cryptography Optional compression of traffic is provided.
SSH can be many authentication schemes such as SecurID, Kerberos, S/KEY to provide a highly secure remote access point to UNIX servers. By default, the OpenSSH server listens for requests on port 22 and port 6010 for X11 forwarding.
SSH1 was the the first version (protocol v1.2 and v1.5) that was free in the earlier days, but licensing has become more restrictive and SSH Communications and DataFellows are trying to get people to move to the newer SSH2 (which is commercial).
OpenSSH has been produced by the OpenBSD team and community. It was first integrated in OpenBSD in 1999. Linux got it much later as a present from OpenBSD community.
OpenSSH intended as a drop-in replacement for the Berkeley "r"-tools (rsh, rlogin, rcp). It can also tunnel via encrypted tunnel X windows and other TCP/IP application level protocols.
Like r-tools ssh supports cross computer pipes:
tar cvzf - . | rsh xxx.xxx.xxx.xxx "(cd $dir; tar xzf -)"
tar cvzf - . | ssh xxx.xxx.xxx.xxx "(cd $dir; tar xzf -)"
This is also possible to do in the reverse direction
ssh xxx.xxx.xxx.xxx "(cd $dir; tar cvzf -)" | tar xzf -
Openssh is a leading SSH implementation (by world famous OpenBSD team). It was first included into OpenBSD 2.6. The software is developed outside the USA, using code from roughly 10 countries, and is freely useable and re-useable by everyone under a BSD license. The OpenSSH suite includes the ssh program which replaces rlogin and telnet, scp which replaces rcp, and sftp which replaces ftp. Also included is sshd which is the server side of the package, and the other basic utilities like ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen and sftp-server.
The package includes several binaries:
Binary name Description ssh rlogin/rsh-like client program ssh-agent This command can store passphrase for private RSA keys in memory, to respond to challenges (challenge response) from the server. This simplifies repeated authentication (imitation of no password authentication) ssh-add Tool which adds keys to ssh-agent sftp FTP-like program that works over SSH1 and SSH2 protocol scp File copy program that acts like rcp ssh-keygen This command generates RSA public and private keys pair ssh-keyscan A utility for gathering the public ssh host keys from a
number of SSH servers. The keys gathered are
displayed on the standard output. This output can then be compared with the key in the file /etc/ssh/ssh_known_hosts and be included in the
file.ssh-keysign Utility for hostbased authentication sshd The daemon that permits you to login sftp-server SFTP server subsystem (started automatically by sshd)
OpenSSH supports SSH protocol versions 1.3, 1.5, and 2.0. Only the latest versions of v. 2.0 have required level of security. Earlier versions have serious security vulnerabilities.
It's not without drawbacks: since SSH is encrypted, troubleshooting is quite challenging. There are also multiple hazards that are inherent in the protocol of that level complexity. Vulnerabilities with SSH, especially were one of the major exploits that were used against ISPs. Beyond protocol problems, there are architecture issues by allowing encrypted pipes. It defeats IDS mechanisms.
|
|||||||
Belier allows opening a shell or executing a command on a remote computer through an SSH session. The main feature of Belier is its ability to cross several intermediate computers before realizing the... job. You can execute commands with any account available on the remote computer. It is possible to switch an account on intermediate computers before accessing the final computer, and Belier will generate one script for each final computer to reach
OpenSSH for Windows is a free package that installs a minimal OpenSSH server and client utilities in the Cygwin package without needing the full Cygwin installation.The OpenSSH for Windows package provides full SSH/SCP/SFTP support. SSH terminal support provides a familiar Windows Command prompt, while retaining Unix/Cygwin-style paths for SCP and SFTP.
Note : This set of instructions has worked for me at our institution. You should read /usr/share/doc/Cygwin/openssh.README after installing cygwin and check the cygwin mailing list if you encounter problems.
June 18, 2008 | Linux.com
SSHMenu adds a button to your GNOME panel that displays a configurable drop-down list of hosts that you have might like to connect to with SSH.SSHMenu is packaged and available in repositories for both Ubuntu (as sshmenu-gnome) and Fedora (gnome-applet-sshmenu). Other SSHMenu packages available for both distributions do not include GNOME support. In those, the button for the SSH menu is started in its own window and an xterm is started when you wish to connect to a host with SSH. If you install the GNOME-aware SSHMenu packages, you can add SSHMenu to your panel by right-clicking the panel and choosing "Add to Panel..." and selecting the "SSH Menu Applet."
When using the GNOME-aware SSHMenu, a gnome-terminal is started to handle your SSH connections, and you can select the profile gnome-terminal should use on a per-host basis. That lets you specify a font and background color in the terminal that can act as a reminder of which host that terminal is connected with.
SSHMenu is a GNOME panel applet* that keeps all your regular SSH connections within a single mouse click.
Each menu option will open an SSH session in a new terminal window. You can organise groups of hosts with separator bars or sub-menus. You can even open all the connections on a submenu (in separate windows or tabs) with one click.
Here's a killer feature: imagine if every time you connected to a production server the terminal window had a red-tinted background, to remind you to tread carefully. Using terminal profiles, SSHMenu allows you to specify colours, fonts, transparency and a variety of other settings on a per-connection basis. You can even set window size and position.
Cluster SSH opens terminal windows with connections to specified hosts and an administration console. Any text typed into the administration console is replicated to all other connected and active windows. This tool is intended for, but not limited to, cluster administration where the same configuration or commands must be run on each node within the cluster. Performing these commands all at once via this tool ensures all nodes are kept in sync.
A lazy sysadmin is a good sysadmin. Time spent in finding more-efficient shortcuts is time saved later on for that ongoing project of "reading the whole of the internet", so try Juliet Kemp's 10 handy tips to make your admin life easier...1. Cache your password with ssh-agent
Using ssh keys and ssh-agent allows you to enter your password once and have it cached for the rest of the session. Edit your .xsession file to have this as its final line:
ssh-agent gnome-session(or substitute the window manager of your choice for gnome-session). This starts gnome-session via ssh-agent, so that any programs run from that gnome-session will have access to the keys stored in ssh-agent.
Next, type:
ssh-add ~/.ssh/id_rsaand enter your passphrase for that key. That's it! From now until the end of the session, you can log in with that key without entering the passphrase.
22nd August 2008Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.
In connection with the incident, the intruder was able to get a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only) signed. As a precautionary measure, we are releasing an updated version of these packages and have published a list of the tampered packages and how to detect them.
To reiterate, our processes and efforts to date indicate that packages obtained by Red Hat Enterprise Linux subscribers via Red Hat Network are not at risk.
We have provided a shell script which lists the affected packages and can verify that none of them are installed on a system:
The script has a detached GPG signature from the Red Hat Security Response Team (key) so you can verify its integrity:
This script can be executed either as a non-root user or as root. To execute the script after downloading it and saving it to your system, run the command:
bash ./openssh-blacklist-1.0.shIf the script output includes any lines beginning with "ALERT" then a tampered package has been installed on the system. Otherwise, if no tampered packages were found, the script should produce only a single line of output beginning with the word "PASS", as shown below:
bash ./openssh-blacklist-1.0.sh PASS: no suspect packages were found on this systemThe script can also check a set of packages by passing it a list of source or binary RPM filenames. In this mode, a "PASS" or "ALERT" line will be printed for each filename passed; for example:
bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklistRed Hat customers who discover any tampered packages, need help with running this script, or have any questions should log into the Red Hat support website and file a support ticket, call their local support center, or contact their Technical Account Manager.
This document covers the SSH client on the Linux Operating System and other OSes that use OpenSSH. If you use Windows, please read the document SSH Tutorial for Windows If you use Mac OS X, you should already have OpenSSH installed and can use this document as a reference.
This is one of the top tutorials covering SSH on the Internet. It was originally written back in 1999 and was completely revised in 2006 to include new and more accurate information. It has been read by over 227,000 people and consistently appears at the top of Google's search results for SSH Tutorial and Linux SSH.
Mar 29, 2000
Q: I use telnet from my Linux box at home to use the HP_UX boxes at university. No problems with telnet, but is there a way to get it to export the X display so that I can use tools other than command line ones?
John Hinsley
Short answer: Use ssh instead.
The default for telnet is to preserve a number of environment settings, including TERM, and DISPLAY. (Any recent telnet daemon should also perform some sanitization on these variables to prevent some degenerate values from being propagated through them to a potentially vulnerable program).
So, if you issue a 'set', 'env' or 'printenv' command and look you might find that your DISPLAY variable IS set. However, it's probably set to the wrong thing.
When you run 'startx' on the local system, it sets your DISPLAY variable to something like: DISPLAY=:0.0 X client programs seeing this value under Linux or UNIX will attempt to connect to the X server via a local UNIX domain socket (one of those nodes in the a filesystem whose permissions/type starts with an "s" in a "long" 'ls' output). That works for the local processes talking to the local X server.
However, to start a remote process that needs to talk to your local X server you must set the DISPLAY variable to a hostname and display number. What you need is something like
DISPLAY=123.45.67.85:0.0 or DISPLAY=foo.bar.not:0.0
Programs that are linked against X libraries will automatically search their environment for a DISPLAY value. If it specifies a hostname or IP address, they will attempt to open a TCP connection (Internet domain socket) instead of a local file/node (UNIX domain socket) connection. Specifically they will try to connect to port 6000 for :0.0, and 6001 for ...:1.0, etc. (Incidentally, the .0 in :0.0 or localhost:0.0 refers to a possible display number. Some X servers support multiple displays/monitors, and these address each of the displays as 0.0, 0.1, 1.0, 1.1 etc).
So, one solution is to use the following sort of command (assuming that you are using a Bourne compatible shell like 'bash' which is the Linux default):
DISPLAY=your.local.hostname:0.0 telnet to.your.remote...
... this variation of the familiar syntax sets this value for the DISPLAY in the environment of the following command (that is on the same line as the assignment, and NOT separated with one of the normal command delimiters, like the semicolon).
Naturally you'd probably put this into whatever function, alias, or shell script you are using to start these telnet sessions. You could use a more portable syntax like:
DISPLAY=`hostname`:0.0 telnet ...
... where the backtick (command substitution) expression is used to fill in the blank. This will allow those shell scripts, etc to adapt to whatever system you copy them to, and will save you from having to fix all of them if you change hostname (and ISP).
Of course, these days your machine's hostname might not match anything that your ISP has set for you. So you might want to extract your IP address and use that instead of your idea of your hostname. I'll leave the extraction of your IP address from the output of the 'ifconfig' command using sh, awk, PERL, TCL or whatever, as an exercise to the reader, it's not difficult (*).
- (Here's an example using just shell builtins for the parsing: '/sbin/ifconfig eth0 | { read x; IFS=": " read x x a x; echo $a; }' )
Another problem with using straight IP addresses is that you might be going through some sort of IP masquerading (NAT --- network address translation) between your local system and the remote.
There is a better way!
USE ssh!
ssh will automatically handle your DISPLAY variable for you. When you establish a remote shell session using ssh it creates it's own version of the DISPLAY variable, one which points "localhost:10" (or localhost:11, etc).
What? Yep! You read that right. Your ssh client tells the remote sshd (daemon/server) to pretend to be the "10th (or later) X server" on the remote system. The the sshd will listen for X protocol activity on TCP port 6010 (or 6011, 6012, etc) and relay that through to your local X server. This feature of ssh is called X11 port forwarding. It is completely transparent and automatic.
On top of that all the traffic between your remote X clients and your local display server is encrypted from the time it gets to the remote sshd (X proxy) until it gets to your local ssh client process. It can't be sniffed or spoofed (not without some heretofore unheard of cryptanalysis or the application of a WHOLE LOT or brute computing force).
Also, when you install and configure ssh you can put one or more public keys in the ~/.ssh/authorized_keys on each of the remote systems to which you want access. So long as you keep the corresponding private keys secure on your system, you can safely access your remote accounts without a password. It's as convenient as 'rsh' and as safe as Kerberos (possibly more so).
You can even publish one or more ssh public identities. Then anyone who wants to let you access an account on any of their systems can just add that to the authorized_keys file there. Possession of the public key can let them let you in, while not directly compromising the security of any other sites to which you have access.
On top of all that you can also use the 'scp' program as a "secure 'rcp'." That's a way to copy files to and from a remote system using basically the same syntax as a 'cp' command and without having to start up a copy of ftp or C-Kermit, etc.
It's also possible to set up ssh tunnels and run any number of common protocols through them.
There's also an ssh-agent program. This is a way of allowing you to login, start up one shell under the ssh-agent, give it your passphrase (in effect unlocking your local private key) and having all your other ssh commands in all of descendent processes, including those on remote systems all automatically use the "unlocked" key. When you exit that one ssh-agent shell or X session, you've effectively "locked" the key back up. (It's actually a rather clever hack).
Oh, yeah! That X11 forwarding trick works right through any IP masquerading, NAT, or applications proxying. It's just more traffic between your ssh client and the remote daemon multiplexed in band with the rest of your session.
It makes no sense to use rsh or telnet in the modern world. We should all switch to more secure protocols like ssh, Kerberos etc. (Ironically, the emergence of IPSec and the future of ubiquitously secure DNS may eventually make the 'net safe for plain telnet and rsh protocols. But that's a different story.)
May 16, 2008
As has been widely reported, the maintainers of Debian's OpenSSL packages made some errors recently that have potentially compromised the security of any sshd-equipped system used remotely by Debian users. System administrators may wish to purge authorized_key files of public keys generated since 2006 by affected client machines.
Simply using a Debian-based machine to access a remote server via SSH would not be enough to put the machine at risk. However, if the user copied a public key generated on a Debian-based system to the remote server, for example to take advantage of the higher security offered by password-free logins, then the weak key could make the server susceptible to brute-force attacks, especially if the user's name is easily guessable.
Administrators of servers that run SSH may wish to go through users' authorized key files (typically ~/.ssh/authorized_keys), deleting any that may have been affected. A "detector" script, available here, appears to compare public key signatures against a list of just 262,800 entries. That in turn suggests that if the user's name is known, a brute force attack progressing at one guess per second could succeed within 73 hours (262,800 seconds).
A full explanation of the problem can be found here. In a nutshell, Debian's OpenSSL maintainers made some Debian-specific patches that, according to subscriber-only content at LWN.net, were aimed at fixing a memory mapping error that surfaced during testing with the valgrind utility. The unintended consequence was a crippling of the randomness of keys, making them predictable, and thus possible to guess using "brute-force" attacks. And unfortunately, the Debian maintainers failed to submit their patches upstream, and thus the problem did not surface until very recently (there's certainly a lesson to be learned, there). Not surprisingly, brute force attacks are way up this week, LWN.net also reported.
Users of Debian and Debian-based distributions such as Ubuntu should immediately upgrade the SSH software on their systems. The new ssh-client package will contain an "ssh-vulnkey" utility that, when run, checks the user's keys for the problem. Users should re-generate any affected keys as soon as possible.
Also possibly affected are "OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections," though not apparently Keys generated with GnuPG or GNUTLS. More details can be found here (Debian resource page), as well as on this webpage, which also links to lists of common keys and brute-force scripts that boast of 20-minute typical break-in times.
-- Henry Kingman
Sometimes, people do such stupid things that words almost fail me. That’s the case with a Debian ‘improvement’ to OpenSSL that rendered this network security program next to useless in Debian, Ubuntu and other related Linux distributions.OpenSSL is used to enable SSL (Secure Socket Layer) and TLS (Transport Layer Security) in Linux, Unix, Windows and many other operating systems. It also includes a general purpose cryptography library. OpenSSL is used not only in operating systems, but in numerous vital applications such as security for Apache Web servers, OpenVPN for virtual private networks, and in security appliances from companies like Check Point and Cisco.
Get the picture? OpenSSL isn’t just important, it’s vital, in network security. It’s quite possible that you’re running OpenSSL even if you don’t have a single Linux server within a mile of your company. It’s that widely used.
Now, OpenSSL itself is still fine. What’s anything but fine is any Linux, or Linux-powered device, that’s based on Debian Linux OpenSSL code from September 17th, 2006 until May 13, 2008.
What happened? This is where the idiot part comes in. Some so-called Debian developer decided to ‘fix’ OpenSSL because it was causing the Valgrind code analysis tool and IBM’s Rational Purify runtime debugging tool to produce warnings about uninitialized data in any code that was linked to OpenSSL. This ‘problem’ and its fix have been known for years. That didn’t stop our moronic developer from fixing it on his own by removing the code that enabled OpenSSL to generate truly random numbers..
After this ‘fix,’ OpenSSL on Debian systems could only use one of a range from 1 to 32,768—the number of possible Linux process identification numbers—as the ‘random’ number for its PRNG (Pseudo Random Number Generator). For cryptography purposes, a range of number like that is a bad joke. Anyone who knows anything about cracking can work up a routine to automatically bust it within a few hours.
Why didn’t the OpenSSL team catch this problem? They didn’t spot it because they didn’t see it. You see Debian developers have this cute habit of keeping their changes to themselves rather than passing them upstream to any program’s actual maintainers. Essentially, what Debian ends up doing is forking programs. There’s the Debian version and then there’s the real version.
Usually, it’s a difference that makes no difference. Sometimes, it just shows how pig-headed Debian developers can be. My favorite case of this is when they decided that rather than allow Mozilla to have control of the logo in the Firefox browser, because that wasn’t open enough according to the Debian Social Contract, they forked Firefox into their own version: Iceweasel.
That was just stupid. This is stupid and it’s put untold numbers of users at risk for security attacks.
First, the mistake itself was something that only a programming newbie would have made and I have no idea how this ever got passed by the Debian code maintainers. This is first-year programming assignment. “What is a random number generator and how do you make one?”
Then, insult to injury, because Debian never passed its ‘fix’ on to OpenSSL, the people who would have caught the problem at a glance, this sloppy, insecure mess has now been used on hundreds of thousands, if not millions, of servers, PCs, and appliances.
This isn’t just bad. This is Microsoft security bad.
Now, there’s a fix for Debian 4.0 Etch and its development builds. Ubuntu, which is based on Debian,, also have fixes for it. In Ubuntu, the versions that need patches are Ubuntu 7.04, Feisty; Ubuntu 7.10, Gutsy; the just released Ubuntu 8.04 LTS Hardy, and the developer builds of Ubuntu Intrepid Ibex.
Debian has also opened a site on how to rollover your insecure security keys to the better ones once you’ve installed the corrected software.. For more on how to fix your system, see Fixing Debian OpenSSL on my ComputerWorld blog, Cyber Cynic.
Silk Tree propagate /etc/passwd and /etc/group files from a master to a list of hosts via SSH. Neither the sending nor the receiving end connect to each other as root. Instead there is a read-only sudo sub-component on the receiver's side that makes the final modifications in /etc. Many checks are made to ensure reliable authorization updates. ACLs are used to enforce a simple security policy. Differences between old and new versions are shown. Two small scripts are included for exporting LDAP users and groups.
Syntax
sshpass [options] command arguments
Options
If not option is given, sshpass reads the password from the standard input. The user may give at most one alternative source for the password:
-p password - The password is given on the command line. Please note the section titled “SECURITY CONSIDERATIONS”.
-f filename - The password is the first line of the file filename.
-d number - number is a file descriptor inherited by sshpass from the runner. The password is read from the open file descriptor.
-e - The password is taken from the environment variable “SSHPASS”.
Security Considerations
First and foremost, users of sshpass should realize that ssh’s insistance on only getting the password interactively is not without reason. It is close to impossible to securely store the password, and users of sshpass should consider whether ssh’s public key authentication provides the same end-user experience, while involving less hassle and being more secure.
The -p option should be considered the least secure of all of sshpass’s options. All system users can see the password in the command line with a simple “ps” command. Sshpass makes no attempt to hide the password, as such attempts create race conditions without actually solving the problem. Users of sshpass are encouraged to use one of the other password passing techniques, which are all more secure.
In particular, people writing programs that are meant to communicate the password programatically are encouraged to use an anonymous pipe and pass the pipe’s reading end to sshpass using the -d option.
sshpass Examples
1) Run rsync over SSH using password authentication, passing the password on the command line:
rsync –rsh=’sshpass -p 12345 ssh -l test’ host.example.com:path
2)sshpass -p [yourpassword] ssh [yourusername]@[host]
About: MindTerm is a complete ssh-client in pure Java. It can be used either as a standalone Java application or as a Java applet. Three packages of importance are provided (terminal, ssh, and security). The terminal package is a rather complete vt102/xterm-terminal, and the ssh-package contains the ssh- protocol and also "drop-in" socket replacements to use ssh-tunnels transparently from a Java application/applet. It also contains functionality to realize a ssh-server. Finally, the security package contains RSA, DES, 3DES, Blowfish, IDEA, and RC4 ciphers.
... ... ...
SSHv2 vs. SSHv1
There are numerous benefits to using the latest version of the SSH protocol, version 2, over it's older counterpart, version 1 and I'm not going into a lot of details on those benefits here - if you're interested, see the URL in the reference below or Google around. That being said if you don't have an explicit reason to use the older version 1, you should always be using version 2.
...To force everybody to use SSHv2, change it to:
Protocol 2When you make this change don't forget to generate the appropriate HostKey's as well! SSHv2 requires the following keys:
# HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key... Once your changes are made, restart the SSH daemon:
# /etc/init.d/sshd restart
[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell DaemonFrom another machine, try SSH'ing in. You can use the -v option to see which protocol is being used, and the '-oProtocol=' option to force one or the other - for example, "ssh -v -oProtocol=2
" would force protocol version 2. ... ... ...
Using TCP Wrappers
TCP Wrappers are used to limit access to TCP services on your machine. If you haven't heard of TCP Wrappers you've probably heard of /etc/hosts.allow and /etc/hosts.deny: these are the two configuration files for TCP Wrappers. In the context of SSH, TCP Wrappers allow you to decide what specific addresses or networks have access to the SSH service.
To use TCP Wrappers with SSH you need to make sure that OpenSSH was built with the -with-tcp-wrappers. This is the case on any modern distribution.
As I indicated earlier, TCP Wrappers are configured by editing the /etc/hosts.deny and /etc/hosts.allow files. Typically you tell hosts.deny to deny everything, then add entries to hosts.allow to permit specific hosts access to specific services.
An example:
# hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # ALL: ALL# hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # sshd: 207.46.236. 198.133.219.25In the example above, access to SSH is limited to the network 207.46.236.0/24 and the address 198.133.219.25. Requests to any other service from any other address are denied by the "ALL: ALL" in hosts.deny. If you try to SSH into a machine and TCP Wrappers denies your access, you'll see something like this:
ssh_exchange_identification: Connection closed by remote host
This simple configuration change significantly hardens your installation since, with it in place, packets from hostile clients are dropped very early in the TCP session -- and before they can do any real damage to a potentially vulnerable daemon.
Public Key Authentication
...Public key authentication is no silver bullet - similarly, people generate passphrase-less keys or leave ssh-agents running when they shouldn't - but, in my opinion, it's a much better bet.
Just about every distribution ships with public key authentication enabled, but begin by making sure it is:
RSAAuthentication yes PubkeyAuthentication yesBoth of these options default to "yes" and the "RSAAuthentication" option is for SSHv1 and the "PubkeyAuthentication" option is for SSHv2. If you plan on using this authentication method exclusively, while you're there, you may want to disable password authentication:
PasswordAuthentication noBefore you proceed, make sure you have a terminal open on your target machine. Once you restart the SSH daemon you will no longer be able to log in without a key... which we haven't generated yet!
Once you're sure, restart the SSH daemon:
# /etc/init.d/sshd restart
[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell DaemonNow, from your desktop, try to SSH in to your target machine:
$ ssh rwm@brainy
Permission denied (publickey,keyboard-interactive).
We're locked out! This is a good thing. The next step, on your desktop, is to generate a key:
$ ssh-keygen -t dsa -C "Ryan's SSHv2 DSA Key (Jan 2008)"
Generating public/private dsa key pair.
Enter file in which to save the key (/home/rwm/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): **********
Enter same passphrase again: **********
Your identification has been saved in /home/rwm/.ssh/id_dsa.
Your public key has been saved in /home/rwm/.ssh/id_dsa.pub.
The key fingerprint is:
98:4d:50:ba:ee:8b:79:be:b3:36:75:8a:c2:4a:44:4b Ryan's SSHv2 DSA Key (Jan 2008)A few notes on this:
- You can generate a DSA (-t dsa), RSA (-t rsa), or SSHv1 (-t rsa1) key. In the example above I'm using dsa.
- I like to put the date I generated the key in the comment (-C) field, that way I can change it out every so often.
- You're entering a passphrase, not a password. Use a long string with spaces and punctuation. The longer and more complicated the better!
The command you just ran generated two files - id_dsa, your private key and id_dsa.pub, your public key. It is critical that you keep your private key private, but you can distribute your public key to any machines you would like to access.
Now that you have generated your keys we need to get the public key into the ~/.ssh/authorized_keys file on the target machine. The best way to do this is to copy-and-paste it - begin by concatenating the public key file:
$ cat .ssh/id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAL7p6bsg5kK4ES9BWLPCNABl20iQQB3R0ymaPMHK...
... ds= Ryan's SSHv2 DSA Key (Jan 2008)This is a very long string. Make sure you copy all of it and that you do NOT copy the newline character at the end. In other words, copy from the "ssh" to the "2008)", but not past that.
The next step is to append this key to the end of the ~/.ssh/authorized_keys file on your target machine. Remember that terminal I told you to keep open a few steps ago? Type the following command into it, pasting the key you've just copied into the area noted KEY:
echo "KEY" >> ~/.ssh/authorized_keys
For example:
echo "ssh-dss AAAA5kS9BWLPCN...s= Ryan's SSHv2 DSA Key (Jan 2008)" >> ~/.ssh/authorized_keys
Now, try to SSH in again. If you did this procedure correctly then instead of being denied access, you'll be prompted for your passphrase:
$ ssh rwm@brainy
Enter passphrase for key '/home/rwm/.ssh/id_dsa':
Last login: Thu Jan 10 14:37:14 2008 from papa.engardelinux.org
[rwm@brainy ~]$Viola! You're now logged in using public key authentication instead of password authentication.
About: Gnome-sshman is an SSH session manager for GNOME. It is easy and fast to use, and is useful for system administrators that need to connect to many SSH servers. Gnome-sshman saves ssh sessions and allows you to open a saved session with a double click in nautilus. Changes: The "open sessions folder" button was removed, so nautilus is now an optional dependency. A session information tool was added to view session data and attach notes to an ssh session. Telnet support was added. A warning is given if you are closing a session with opened tabs. A preferences window was added to change colors, fonts, and set other default options. Gconf support was added. Two bugs were corrected: a cypher module bug with the hwrandom module and a bug with GNOME 2.20 nautilus in background mode.
rshall
Runs commands on multiple remote hosts simultaneously. (Perl)
View the README
Download version 11.0 - gzipped tarball, 9 KB
Last update: November 2005
autosync
Copies files to remote hosts based on a configuration file. (Perl)
View the README
Download version 1.4 - gzipped tarball, 5 KB
Last update: April 2007
Simplifying remote loginSecure Shell (SSH) tools provide a secure method for logging in and exchanging information with a remote host. A number of different tools are provided, including the general-purpose SSH tool (which provides a remote terminal connection), SCP (a secure, host-to-host, copy solution), and SFTP, a secure file copy solution that works in a similar fashion to the standard FTP tools.
All of these tools are secure in that the information that is exchanged is encrypted. In addition, the authentication of connections is secured using a public or private key mechanism. One of the main benefits of SSH is that you can bypass the normal login and password exchange by copying your public key to a remote machine.
Although this is useful when using SSH to log in to a remote machine (as it means you don't have to provide a password), it is even more useful when performing remote administration. Having to type in a password can also make automated remote administration (for example, running a command through cron) impossible, because in an automated script, you won't be around to type in the password!
When using SSH to run commands across multiple machines without exchanging your public key, you need to type in your password for each machine.
A quick and simple way of setting this up is to create a public key:
Follow the on-screen instructions, but don't set a password when prompted, as you will then need to enter the password each time you want to use the key. This creates a private and a public key file. Now you just need to append the contents of the public key file in .ssh/id_rsa.pub, and append it to the .ssh/authorized_keys file on the remote host and user you want to use when logging in. You need to append the public key file contents to each machine you want to log in to automatically.There are many ways in which you can run a remote command.
You can run a single remote command by adding the command you want to run to SSH after the login or host information. For example, to get the disk information for a remote host, you might use the command and get the output in Listing 1 below.
Listing 1. Running a simple command through SSH
Bear in mind that the sequence in Listing 1 requires you to enter a password if you haven't already exchanged your public key with the remote host.
You can also execute a sequence of commands by separating each command with a semicolon and then placing the entire sequence of commands into quotes so that it is identified as a single argument.
An example of executing both a disk check and an uptime check is shown in Listing 2.
Listing 2. Executing a disk and an uptime check
You can string as many commands as you like into this operation. Filtering, for example, using grep or other tools, is also possible, but you need to make sure to embed the entire remote command expression into the quotes (see Listing 3).
Listing 3. Filtering using grep
The first item to note about Listing 3 is that you are logging in directly to the remote machine as root. This is because the file you want to view is only accessible to the superuser. You must ensure that your system is configured to allow remote root logins for this to work.
The second important note about this example is that you've performed the grep operation remotely. In actual fact, you don't need to do this. The standard input and output of the remote host are replicated to the local machine, so the output from the command can be filtered locally, as shown here in Listing 4.
Listing 4. Output filtered locally
Of course, the effect is essentially the same.
Using the remote pipe method, though, is useful when the information or command that you want to pipe with is remote. For example, you can use
lsin combination withduto determine the disk usage of different directories with the command shown in Listing 5.
Listing 5. Determining disk usage of different commands
Before moving on to redistributing these techniques to multiple machines, there's a quick trick for running remote interactive sessions directly without having to log in first.
As shown previously, you can directly run a number of different commands and chains of commands. One of the benefits of the SSH solution is that although the command itself is executed remotely, the input and output of the command are sourced from the calling machine. You can use this as a method for exchanging information between the two machines relating to the commands that you want to execute.
The commands that you execute can cover almost anything from a range of different commands. However, because you are running commands directly from the command line, there are limits to what you can execute directly with this method. For example, trying to edit a remote file with an editor using this method and techniques shown above usually fail (see Listing 6).
Listing 6. Edit a remote file fails
You can resolve this by forcing SSH to allocate a pseudo-tty device so that you can interact directly with the remote application.
SftpDrive Access SFTP as a Windows Drive Letter
SftpDrive lets your applications access your files from anywhere on the Internet safely and securely, like a VPN, without the VPN.
SSH is the industry standard for remote access to Linux, Mac OS X, and UNIX computers because it's safe, secure, and just works from anywhere on the Internet. SSH servers like OpenSSH and VShell have a powerful system called SFTP built-in. Unrelated to the archaic FTP protocol, SFTP is a modern, secure system that gives you the power to treat your network files as if they were right on your desktop. Stream movies and music. Run programs. Load and save any file from any application. Best of all, your SSH server is ready to go.
Many of us use the excellent OpenSSH as a secure, encrypted replacement for the venerable telnet and rsh commands. One of OpenSSH's (and the commercial SSH2's) intriguing features is its ability to authenticate users using the RSA and DSA authentication protocols, which are based upon a pair of complementary numerical "keys". And one of the main appeals of RSA and DSA authentication is the promise of being able to establish connections to remote systems without supplying a password. The keychain script makes handling RSA and DSA keys both convenient and secure. It acts as a front-end to ssh-agent, allowing you to easily have one long-running ssh-agent process per system, rather than per login session. This dramatically reduces the number of times you need to enter your passphrase from once per new login session to once every time your local machine is rebooted.
Keychain was first introduced in a series of IBM developerWorks articles.
- The first article introduces the concepts behind RSA/DSA key authentication and shows you how to set up primitive (with passphrase) RSA/DSA authentication.
- The second article shows you how to use keychain to set up secure, passwordless ssh access in an extremely convenient way. keychain also provides a clean, secure way for cron jobs to take advantage of RSA/DSA keys without having to use insecure unencrypted private keys.
- The third article shows you how to use ssh-agent's authentication forwarding mechanism.
Current versions of keychain are known to run on Linux, BSD, Cygwin, Tru64 UNIX, HP-UX, Mac OS X, and Solaris using whatever variant of Bourne shell you have available.
Secure Shell is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for telnet, rlogin, rsh, and rcp. For SSH2, there is a replacement for FTP: sftp.This might be useful if you are trying to connect everytime to your server remotely.A Trust relationship can be established for users on multiple servers running OpenSSH to allow a password free ssh session. This is sometime important when you want to run scripts or commands remotely.
Let’s assume ServerA and ServerB both run the ssh daemons.
To allow ServerA to SSH to ServerB without password, please try the following:
# ssh-keygen -t rsa
Note: User here is root
This generates two files id_rsa.pub and id_rsa
Now, this needs to be copied to the authorized_keys file on ServerB
# scp id_rsa.pub ServerB:~/.ssh/authorized_keys
Enter password when prompted.
Note: If the ServerB is already having a trust relationship with more that one hosts already then the above will wipe the contents and write this key alone. In which case, copy the file to the remote server as something like ServerA_rsa.pub and then append the contents to authorized_keys as follows. This will allow the existing authroized_keys from being wiped off.
# scp id_rsa.pub ServerB:~/.ssh/ServerA_rsa.pub
# cat ServerA_rsa.pub >> authorized_keys
Thats it. Test if you are able to do a ssh from ServerA without a password:
# ssh serverB uname -a
This will run the command “uname -a” on ServerB and returns the result on ServerA.
The same procedure has to be followed in the reverse to allow ServerB to talk back to ServerA without any password.
And, if there is anyone other server to be added to the existing list follow the same procedure ensuring the key is appended to the remote servers authorized_keys file and not by overwriting it.
TCP Wrappers has been around for many years. It is used to restrict access to TCP services based on host name, IP address, network address, and so on. For more details on what TCP Wrappers is and how you can use it, see man tcpd.
The original code was written by Wietse Venema at the Eindhoven University of Technology, The Netherlands, between 1990 and 1995.
TCP Wrappers support in Secure Shell is given by using the library libwrap, which is a free software program library that implements generic TCP Wrapper functionality for network service daemons to use (rather than, or in addition to, their own host access control schemes).
To see if sshd is dynamically linked against libwrap, or has support build-in, use the following command:
ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00b22000)Logging of SSH Logins
Normally, the Port for SSH is open to the Internet World, can pass Firewalls and is therefore a door for Hackers. TCP Wrappers relies on the standard syslog facility to log connections, which can be checked in /etc/syslog.conf
# The authpriv file has restricted access.
authpriv.* /var/log/auth.logIf you look into this file with tail -f you will be noticed, that there are many (hopefully failed) SSH Connections. So, how to avoid this unnecessary traffic to your system?
TCP wrappers provides limited, connection-oriented host-based firewall functionality with which connections can be denied or accepted based on the originating host. Connection attempts are logged using syslog(3C). OpenSSH uses this functionality by linking in the libwrap library. TCP wrappers is dependent on the name and IP address information returned by the name services, such as DNS. It cannot stop low-level network-based attacks, such as port scanning, IP spoofing, or denial of service. For those, a packet-based firewall solution such as SunScreenTM software is necessary. The Solaris 9 OE has TCP wrappers integrated into it, package SFWtcpd, which is located in the /usr/sfw directory. For the Solaris 8 OE, TCP wrappers can be found on the Software Companion CD (starting in the Solaris 8 10/00 release). For the Solaris 2.6 and 7 OE releases, TCP wrappers must be downloaded and built from the source. TCP wrappers is not required to build OpenSSH.
A quick tutorial on how to configure tcp wrapper for SSH on your VDS or dedicated server. More detailed information can be obtained by looking at the man pages - 'man hosts.allow' - 'man hosts.deny'.
In a nutshell tcp wrapper can be used to control access to your server via SSH (and other daemons). It can be used in combination with a local firewall (iptables, ipchains, ipfw) or standalone.
From the man page.
The access control software consults two files. The search stops at the first match:
- Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.
- Otherwise, access will be denied when a (daemon,client) pair matches an entry in the /etc/hosts.deny file.
- Otherwise, access will be granted.
A very simplistic tcp wrapper implementation:
# Control access to SSH
vi /etc/hosts.allow
# Allow me access from home on IP 192.168.1.1
SSHD: 192.168.1.1
# Allow me access from work on IP 10.0.1.0/24
SSHD: 10.0.1.
vi /etc/hosts.deny
# Deny all other SSH attempts
SSHD: ALL
In the above example you will be able to connect via SSH from the IP address 192.168.1.1 and the netblock 10.0.1.0/24 (which includes IP address 10.0.1.1 through 10.0.1.254).
To verify tcp wrapper is working by attempting to connect from an IP address not in /etc/hosts.allow. You should see something similar in your logs (/var/log/secure):
Feb 20 08:05:46 server sshd[8273]: refused connect from 218.236.84.82 (218.236.84.82)
Above, you see the date, time, hostname, process (sshd), process id (8273) and the IP address where the person was attempting to connect from.
tcp wrapper is an excellent way to enchance security on your VDS or dedicated server and is not limited to just SSH.
Tom
15.2.3.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.
Configuring SSH Secure Shell for TCP Wrappers Support
To enable usage of TCP Wrappers with SSH Secure Shell, perform the following operations:
- If SSH Secure Shell was previously installed from binaries, you may want to uninstall it before continuing.
- Compile the source code:
./configure --with-libwrap makeThen, become root and runmake installNote: Ifconfiguredoes not findlibwrap.a, do the following:
- Locate
libwrap.a- Run
configureagain:make distclean ./configure --with-libwrap=/path_to_libwrap.a/Note: It is only necessary to specify the path tolibwrap.aif the library and the include files are located in a non-standard directory, i.e. if the library has been compiled to a local directory, or has been installed to somewhere else than the default location.- Create or edit the
/etc/hosts.allowand/etc/hosts.denyfiles. When a user tries to connect to the SSH Secure Shell server, the TCP wrapper daemon (tcpd) reads the/etc/hosts.allowfile for a rule that matches the client's hostname or IP. If/etc/hosts.allowdoes not contain a rule allowing access,tcpdreads/etc/hosts.denyfor a rule that would deny access. If neither of the files contains an accept or deny rule, access is granted by default. The syntax for the/etc/hosts.allowand/etc/hosts.denyfiles is as follows:daemon : client_hostname_or_IPThe typical setup is to deny access to everyone listed in the/etc/hosts.denyfile. (This example shows both ssh1 and ssh2.)sshd1: ALL sshd2: ALL sshdfwd-X11 : ALLor simplyALL: ALLAnd then allow access only to trusted clients in the/etc/hosts.allow:sshd1 : trusted_client_IP_or_hostname sshd2 : .ssh.com foo.bar.fi sshdfwd-X11 : .ssh.com foo.bar.fiBased on the/etc/hosts.allowfile above, users coming from any host in the ssh.com domain or from the host foo.bar.fi are allowed to access.
Based on 24 reviews. Write a review.