Ssh - Revision history

Ninereasons: common misspelling

2006-05-23T23:24:33Z

common misspelling

Jimbo: /* What's all this stuff about keys? */

2006-05-13T14:57:57Z

What's all this stuff about keys?

Jimbo: /* Technical details and comparisons */

2006-05-13T14:56:07Z

Technical details and comparisons

Jimbo at 17:27, 18 March 2006

2006-03-18T17:27:29Z

Dave: /* See also */

2006-03-17T19:00:19Z

Dave at 19:00, 17 March 2006

2006-03-17T19:00:06Z

84.42.190.231: /* What's all this stuff about keys? */

2006-02-13T06:48:02Z

What's all this stuff about keys?

Dave: /* OK, I can use the client, how do I run the server? */

2005-12-14T14:25:31Z

OK, I can use the client, how do I run the server?

Dave: /* What's all this stuff about keys? */

2005-12-12T15:03:39Z

What's all this stuff about keys?

Dave: /* What's all this stuff about keys? */

2005-12-12T14:38:14Z

What's all this stuff about keys?

@@ Line 52: / Line 52: @@
 SSH keys are made in pairs, one public and one private. They match each other -- not unlike a physical lock and key. For more information on the theory behind this, see [[public key infrastructure]] or [[PKI]].
-As it relates to ssh, this is a topic that is sufficiently hairy that there are seperate wiki pages for the various aspects of it:
+As it relates to ssh, this is a topic that is sufficiently hairy that there are separate wiki pages for the various aspects of it:
 [[ssh keys, creating]]

@@ Line 48: / Line 48: @@
 ==What's all this stuff about keys?==
-[[SSH]] can use public/private key pairs for both stronger encryption and authentication. You increase security by adding another layer -- something you know (your password) and something you have (the key you provide to the server) -- and you can prove to the server that it is your key by giving it the password that the key was made with. That said, one common use of ssh keys is passwordless authentication, which is less secure but very handy (e.g., with scripts). The downside of using passwordless authentication with keys is that you have to keep your keys fairly secure or risk a security breach if they are not secured.
+[[SSH]] can use public/private key pairs for both stronger encryption and authentication. You increase security by adding another layer -- something you know (your password) and something you have (the key you provide to the server) -- and you can prove to the server that it is your key by giving it the password that the key was made with. That said, one common use of ssh keys is passwordless authentication, which is less secure but very handy (e.g., with scripts). The downside of using passwordless authentication with keys is that you have to be very careful to keep your keys secure, since that key is the ''only'' thing a black-hat would need to breach your security.
 SSH keys are made in pairs, one public and one private. They match each other -- not unlike a physical lock and key. For more information on the theory behind this, see [[public key infrastructure]] or [[PKI]].

@@ Line 9: / Line 9: @@
 == Technical details and comparisons ==
-In older days the cryptographically-lacking [[telnet]] and related applications such as [[rsh]] were used to control [[headless]] or remote devices.  [[telnet|Telnet]] is now largely obsolete, however, surviving mostly only on distincly aging legacy equipment and for use in local serial console access on industrial routers.  "Serious equipment" such as unix-like servers and heavyweight routers is moving toward access via ssh, while the smaller embedded equipment such as small-office/home-office routers and embedded printservers are moving towards embedded web-based access and configuration (often with SSL connections).
+In older days the cryptographically-lacking [[telnet]] and related applications such as [[rsh]] were used to control [[headless]] or remote devices.  However, [[telnet]] is now largely obsolete, surviving mostly only on distinctly aging legacy equipment and physical console access to serial ports on industrial routers.  "Serious equipment" such as unix-like servers and heavyweight routers is moving toward access via ssh, while the smaller embedded equipment such as small-office/home-office routers and embedded printservers are moving towards embedded web-based access and configuration (often with SSL connections).
-It is historically important to recall that [[telnet]] originally evolved as a standard for use over non-routable networks that were not considered very likely to be tapped, such as VT100-style serial networks, local console ports, and the like.  As modern networking began drastically increasing the exposure of networked data to more and farther-flung locations, however, [[packet sniffing]] became more and more of an issue.  An enterprising [[black-hat]] who had access to a router, hub, or switch anywhere in between you and the machine you were trying to [[telnet]] into didn't necessarily need to know your password ahead of time - he could just log all the [[packets]] going to the machine and wait until a login sequence went by, and presto change-o, he's got [[root]].  A more patient black-hat might sit and monitor quietly without doing anything for weeks, months, or even years - the longer time went by with no alarm raised, the more sensitive data would go his way down the pike.
+It is historically important to recall that [[telnet]] evolved as a standard for use over non-routable networks that were not considered very likely to be tapped, such as VT100-style serial networks and local console ports.  As modern networking began drastically increasing the exposure of networked data to more and farther-flung locations, however, [[packet sniffing]] became more and more of an issue.  An enterprising [[black-hat]] who had access to a router, hub, or switch anywhere in between you and the machine you were trying to [[telnet]] into didn't necessarily need to know your password ahead of time - he could just log all the [[packets]] going to the machine and wait until a login sequence went by, and presto change-o, he's got [[root]].  A more patient black-hat might sit and monitor quietly without doing anything for weeks, months, or even years - the longer time went by with no alarm raised, the more sensitive data would go his way down the pike.
-[[Ssh]] changed all that, by introducing automatic public/private key-based security and authentication across the channel.  A [[black-hat]] lurking on the network and [[packet sniffing|sniffing packets]] moving to and from a server controlled via [[ssh]] has much less to work with; since even the authentication challenge and response itself is encrypted against third-party interception, it is ''very'' difficult to gain much of value out of [[packet sniffing|sniffing]] an [[ssh]] session.
+[[Ssh]] changed all that, by introducing automatic public/private key-based security and authentication across the channel.  A [[black-hat]] lurking on the network and [[packet sniffing|sniffing packets]] moving to and from a server controlled via [[ssh]] has much less to work with.  Since even the authentication challenge and response itself is encrypted against third-party interception, it is ''very'' difficult to gain much of value out of [[packet sniffing|sniffing]] an [[ssh]] session.
 Of course, things do tend to evolve, and it's always wise to make sure that your version of [[ssh]] is up to date before you decide that you're the Fort Knox of the IT world - fairly recently at the time of this writing, serious cryptological flaws were discovered in the older (version 1) ssh protocol, and so currently it is considered best practice to disable ssh1 sessions, forcing ssh2 or nothing.

@@ Line 70: / Line 70: @@
 [[sshd]]
-[[Tunneling over SSH from Winows]]
+[[Tunneling over SSH from Windows]]
 [[Category : System Commands]]
 [[Category : Ports and Packages]]

@@ Line 69: / Line 69: @@
 ==See also==
 [[sshd]]
 [[Tunneling over SSH from Winows]]

@@ Line 58: / Line 58: @@
 [[ssh keys, using]]
-[[passwordless authentication]]
+[[SSH:_Passwordless_authentication]]
 ==OK, I can use the client, how do I run the server?==

← Older revision		Revision as of 14:38, 12 December 2005
Line 53:		Line 53:

	As it relates to ssh, this is a topic that is sufficiently hairy that there are seperate wiki pages for the various aspects of it:		As it relates to ssh, this is a topic that is sufficiently hairy that there are seperate wiki pages for the various aspects of it:
		+
	[[ssh keys, creating]]		[[ssh keys, creating]]