Differences between version 75 and predecessor to the previous major change of SSHNotes.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 75 | Last edited on Thursday, June 1, 2006 12:33:02 pm | by AristotlePagaltzis | Revert |
| Older page: | version 73 | Last edited on Thursday, March 9, 2006 12:55:04 pm | by SamCook | Revert |
@@ -1,192 +1,200 @@
-See the [SSHErrors] page for resolving [SSH] related errors, and [SSHKeys] for information about setting up SSH key logins.
+See the [SSHErrors] page for resolving [SSH] related errors, and [SSHKeys] for information about setting up [
SSH]
key logins.
-!!!Config file aliases
-To ease your life, you can put all settings for a particular host in your __.ssh/config__. Say you would normally use the CommandLine
+!!! Config file aliases
-
ssh me@some.long.winded.fqdn.name.here
.com
+To ease your life, you can put all settings for a particular host in your <tt>.
ssh/config</tt>
. Say you would normally use the following command to connect to somewhere:
-to connect to somewhere
. That's a lot to type
. If you spell this out in configuration directives (see ssh_config(5)) it looks like this:
+<verbatim>
+ssh me@some
.long
.winded.fqdn.name.here.com
+</verbatim>
- Host foo
- Protocol 2
- User me
- !HostName some
.long.winded.fqdn.name.here.com
+That's a lot to type
. If you spell this out in configuration directives (see ssh_config(5)) it looks like this:
-From then on it's enough to simply say
+<verbatim>
+Host foo
+ User me
+ HostName some.long.winded.fqdn.name.here.com
+</verbatim>
- ssh foo
+From then on it's enough to simply say this:
-Much better! You can also use wildcards for the hostname. A __Host *__ section defines directives that should be in effect for ''all'' [SSH] connections.
+<verbatim>
+ssh foo
+</verbatim>
-!!!
SSH Control Character
+Much better
! You can also use wildcards for the hostname. A <tt>Host *</tt> stanza defines directives that should be in effect for ''all'' [
SSH] connections.
-~ is the control character for ssh. Once you get into control mode there are a few things you can do - exit the current ssh session ( use ~. ) or background it ( ~^Z). ~? will give you a list of control sequences. This is discussed in ssh(1), of course.
-~ is only special if it is pressed after a newline, otherwise a literal "~"
character is sent (as it is if the following character is not one of the meaningful ssh commands). ~~ after a newline will also force a "~" char to be sent. If you are ssh'd from another ssh connection, you can do ~~^Z after a newline to make the remote ssh client get the background command, instead of your local client.
+!!! Control
character
+<tt>~~</tt> is the control character for [SSH]. Once you get into control mode there are a few things you can do – exit the current ssh session (use <tt>~~.</tt>) or background it (<tt>~~^Z</tt>). <tt>~~?</tt> will give you a list of control sequences. This is discussed in ssh(1), of course.
-!!!Virtual Terminal
+<tt>~~</tt> is only special if it is pressed after a newline, otherwise a literal "~~" character is sent (as it is if the following character is not one of the meaningful ssh commands). <tt>~~~~</tt> after a newline will also force a "~~" char to be sent. If you are [SSH]ed from another [SSH] connection, you can do <tt>~~^Z</tt> after a newline to make the remote ssh client get the background command, instead of your local client.
-Ever tried to do
- ssh user@host screen -rx
+!!! Virtual Terminal
-to reconnect to
a screen?
[Screen] will tell you it can't do that: ''Must be connected to a terminal''. Well, you can provide one easily:
+Ever tried
to do
reconnect a [Screen] session over [SSH]?
- ssh -t user@host screen -rx
+ <verbatim>
+
ssh joe@home.sweet.home screen -rx
+ Must be connected to a terminal.
+ </verbatim>
+
+This is [Screen] complaining, not [SSH]. Well, you can provide a terminal easily by using the <tt>-t</tt> switch: <tt>
ssh -t user@host screen -rx</tt>
Combined with [SSHKeys] it's excellent for reconnecting those [IRC] sessions with a single key/buttonpress.
Unfortunately this option cannot be set from your ssh_config(5).
-!!!Connecting to two hosts behind one IP address
-You may connect directly to a number of machines NATted
behind a single ip
address using different ports.
+!!! Connecting to two hosts behind one [IP] address
+
+
You may connect directly to a number of machines [NAT]ted
behind a single [IP]
address using different ports.
After the first host has been connected to, subsequent hosts will give a warning:
- Warning: the RSA host key for 'hostname' differs from the key for the IP address '1.1.1.1'
- Offending key for IP in /home/alastair/.ssh/known_hosts:2
- Matching host key in /home/alastair/.ssh/known_hosts:7
- Are you sure you want to continue connecting (yes/no)?
-Some ways to work around this:
-* Add
''!StrictHostKeyChecking no
'' to each stanza
in your
ssh_config(5). This will still produce a warning, but will connect without any input needed
-* Add ''!UserKnownHostsFile ~
/.ssh/known_hosts_foo''
to each ssh_config
(5
) stanza.
+ <verbatim>
+ Warning: the RSA host key for
'example.com
' differs from the key for the IP address
'1.1.1.1
'
+ Offending key for IP
in /home/joerandom/.
ssh/known
_hosts:2
+ Matching host key in /home/joerandom
/.ssh/known_hosts:7
+ Are you sure you want
to continue connecting
(yes/no
)?
+ </verbatim>
-Better technique: set
up aliases for the different
host/port combinations
in your ssh_config file, e.g.
+To avoid this, use the <tt>~HostKeyAlias</tt> keyword to specify an alternative name rather than the hostname to use for finding the host key in your <tt>known_hosts</tt> file. Set
up aliases for each
host/port combination
in your <tt>
ssh_config</tt> as explained above in <i>Config
file aliases</i>
, then assign them each unique key aliases:
-
Host machine89
- !
HostKeyAlias machine89
- !
HostName example.com
-
Port 8922
-
Host machine90
- !
HostKeyAlias machine90
- !
HostName example.com
-
Port 9022
+<verbatim>
+
Host foo
+
HostKeyAlias example_com_9622
+
HostName example.com
+
Port 9622
+Host bar
+
HostKeyAlias example_com_9623
+
HostName example.com
+
Port 9623
+</verbatim>
-The "!HostKeyAlias" keyword specifies an alternative name (rather than the host name) to use for finding the host key in your known-hosts file, whereas the "Host" keyword is what you type on the command line
instead of the host name. This means you can type "ssh machine89" instead of "
ssh -p 8922
example.com"
and "
ssh machine90" instead of "ssh -p 9022 example.com". See the ssh_config
(5
) man page for other options you can put in your "Host" stanzas, including different usernames etc
.
+Now
instead of typing <tt>
ssh -p 9622
example.com</tt>, you say <tt>ssh foo</tt>
and ssh(1
) will figure things out correctly
.
-!!!Port Forwarding
+A clumsier workaround is to add <tt>~UserKnownHostsFile ~~/.ssh/known_hosts_<i>hostname</i></tt> to each ssh_config(5) stanza, so a different list of known hosts is used for each host.
-[SSH] can forward ports across its encrypted tunnel
. Using the following command
,
+If you just need a quick and dirty workaround, add <tt>~StrictHostKeyChecking no</tt> to each stanza in your ssh_config(5)
. This will still produce a warning
, but will connect without any input needed, while decreasing your security.
- ssh -L 5000:very.remote:80 user@host.remote
-will have [SSH] listening on port 5000 on __localhost__. By connecting to this port you get a connection tunneled to __host.remote__, which will then establish a connection to port 80 on __very.remote__. This is very helpful if __very.remote__ lives behind a FireWall that blocks direct traffic, but will let you [SSH] to __host.remote__. By the same token, doing
+!!! Port Forwarding
-
ssh -L 5000:localhost
:80 user@host.remote
+[SSH] can forward ports across its encrypted tunnel. F.ex., if you issue <tt>
ssh -L 5000:very.remote
:80 user@host.remote</tt> [SSH] will be listening on port 5000 on <tt>localhost</tt>. By connecting to this port you get a connection tunneled to <tt>host.remote</tt>, which will then establish a connection to port 80 on <tt>very.remote</tt>. This is very helpful if <tt>very.remote</tt> lives behind a FireWall that blocks direct traffic, but will let you [SSH] to <tt>host.remote</tt>.
-you can tunnel a connection from port 5000 on your own host to port 80 on __
host.remote__
, which for the purposes of the webserver on the other end will appear to come from that __
localhost__
.
+By the same token, using <tt>ssh -L 5000:localhost:80 user@host.remote</tt>
you can tunnel a connection from port 5000 on your own host to port 80 on <tt>
host.remote</tt>
, which for the purposes of the webserver on the other end will appear to come from that <tt>
localhost</tt>
.
-If you don't need the shell, and just want the tunnel, you can add options __
-f__
(go to background before command execution) and __
-N__
(don't execute remote command).
+If you don't need the shell, and just want the tunnel, you can add options <tt>
-f</tt>
(go to background before command execution) and <tt>
-N</tt>
(don't execute remote command): <tt>ssh -f -N -L 5000:localhost:80 user@host.remote</tt> [SSH] will then effectively run as a daemon
.
- ssh
-f -N -L 5000:
localhost:80 user@host
.remote
+If you add <tt>
-g</tt>, your local end of the [SSH] tunnel will accept connections from anyone, not just <tt>
localhost</tt>. Say there are two machines called <tt>host1.lan</tt> and <tt>host2.lan</tt> on a [LAN]
. By doing
-[SSH] will then effectively run as a daemon
.
+<verbatim>
+host1$ ssh -f -g -N -L 5000:localhost:80 user@host
.remote
+host2$ lynx host1:5000
+</verbatim>
-If you add __-g__, your local end of the [SSH] tunnel will accept connections from anyone, not just __localhost__. Say there are two machines called __host1.lan__ and __host2.lan__ on a [LAN]. By doing
-
- host1$ ssh -f -g -N -L 5000:localhost:80 user@host.remote
- host2$ lynx host1:5000
-
-__
host2.lan__
to the webserver on __
host.remote__
without, in fact, connecting from __
host2.lan__
to __
host.remote__
.
+you have opened a connection from <tt>
host2.lan</tt>
to the webserver on <tt>
host.remote</tt>
without, in fact, connecting from <tt>
host2.lan</tt>
to <tt>
host.remote</tt>
.
Imagine the fun you can have with multiple [SSH] forwards!
-If you've set up your __
.ssh/config__
as in the tip above, you can spare yourself typing the same parameters to set up tunnels in the same manner. __
-L 5000:localhost:110__
translates to __!
LocalForward 5000 localhost:110__
. If you'd like to have __
-g__
taken care of as well, add __!
GatewayPorts__
. __
-f__
and __
-N__
don't have corresponding options, but those wouldn't be very useful anyway.
+If you've set up your <tt>
.ssh/config</tt>
as in the tip above, you can spare yourself typing the same parameters to set up tunnels in the same manner. <tt>
-L 5000:localhost:110</tt>
translates to <tt>~
LocalForward 5000 localhost:110</tt>
. If you'd like to have <tt>
-g</tt>
taken care of as well, add <tt>~
GatewayPorts</tt>
. <tt>
-f</tt>
and <tt>
-N</tt>
don't have corresponding options, but those wouldn't be very useful anyway.
-!!!X Connection Forwarding
-If you use the __-
X__ option to ssh, you will enable X-connection forwarding. This is essentially a reverse port forward with a few added effects: for instance it will set your __DISPLAY__ variable on the remote end to something like __localhost:15__. Most of the time you won't need to mess with xhost(1) or xauth(1) either.
+!!! [
X] Connection Forwarding
-Be aware that
you will need
the X libraries and utilites even if
you're
forwarding clients from
a headless server
. To fix yourself
up on Debian machines
, just
+If
you use
the <tt>-
X</tt> option to ssh(1),
you will enable [X]-connection
forwarding. This is essentially
a reverse port forward with a few added effects: for instance it will set your <tt>DISPLAY</tt> EnvironmentVariable on the remote end to something like <tt>localhost:15</tt>
. Most of the time you won't need to mess with xhost(1) or xauth(1) either. If you've set
up your <tt>.ssh/config</tt> as discussed above
, you can spare yourself typing <tt>-X</tt> every time using the <tt>ForwardX11</tt> directive.
- apt-get install xbase-clients
+The [SSH] daemon on the remote machine must be configured to allow X11 forwarding. If it is disabled, you have to edit <tt>/etc/ssh/sshd_config</tt> and then restart sshd(8).
-For those of us not running debian
, you need to install
whatever packages you have that
give you the xhost(1) binary. In FreeBSD, it is named ''xorg-clients''
.
+Be aware that you will need the [X] libraries and utilites installed on the server even if you're forwarding clients from a headless server. On [Debian], you need the <tt>xbase-clients</tt> [Package]; on [FreeBSD], it’s <tt>xorg-clients</tt>. In general
, you need whatever packages will
give you the xhost(1) binary.
-If you've set up your __
.ssh/config__ as discussed above
, you can spare yourself typing __-X__ every time using the directive ForwardX11.
+If you are running OpenSSH 3
.8 or newer
, some [X] applications may give
you one of these errors:
-The [SSH] daemon on the remote machine must be configured to allow X11 forwarding -- the [Debian] [Woody] default configuration for example disables it. If it is disabled, you have
to edit __
/etc
/ssh/sshd_config__ and then restart sshd
(8
).
+* <tt>~BadWindow (invalid Window parameter)</tt>
+* <tt>~BadAccess (attempt
to access private resource denied)<
/tt>
+* <tt>X Error of failed request: ~BadAtom (invalid Atom parameter)<
/tt>
+* <tt>Major opcode of failed request: 20
(X_~GetProperty
)</tt>
-If
you are running OpenSSH 3
.8 or newer
, some X applications may give you
one of these errors:
+In that case
you will also find by invoking xdpyinfo(1) from the remote machine that they can only use a fraction of the extensions your [XServer] offers
. This is because the new default is to use untrusted [X11] cookies for forwarding connections. You need to invoke ssh(1) with the <tt>-Y</tt> option for [X11] forwarding
, or add <tt>ForwardX11Trusted yes</tt> to your configuration. Since
one of the affected extensions is <tt>XRENDER</tt>, which greatly reduces the bandwidth required to draw AntiAliasedFonts and accelerates their rendering, it is unclear why anyone would ever use untrusted cookies.
-* !BadWindow (invalid Window parameter)
-* !BadAccess (attempt to access private resource denied)
-* X Error of failed request: !BadAtom (invalid Atom parameter)
-* Major opcode of failed request: 20 (X_!GetProperty)
-
-You will also find by invoking xdpyinfo(1) from the remote machine that they can only use a fraction of the extensions your X server offers. This is because the new default is to use untrusted X11 cookies for forwarding connections. You need to invoke ssh(1) with the __-Y__ option for [X11] forwarding, or add __ForwardX11Trusted yes__ to your configuration. Since one of the affected extensions is XRENDER, which greatly reduces the bandwidth required to draw AntiAliasedFonts and accelerates their rendering, it is unclear why anyone would ever use untrusted cookies.
!!! STDIN Forwarding
[SSH] forwards its standard input to be the standard input of a command executed on the remote machine. You can use this to do some pretty cool things like stream tar(1) archives across a network to eliminate any overhead with copying many small files:
-
tar c sourcedir | ssh user@host tar xf -
+<verbatim>
+
tar c sourcedir | ssh user@host tar xf -
+</verbatim>
There are many other neat tricks that can be perfomed using this technique as well. The feature was inherited from rsh(1). If you are having problems with corruption when piping data via [SSH], you may find a solution on the [SSHErrors] page.
-In a rudimentary test involving about 200MB of variously sized files, the tar stream finished in about 4:00 minutes, where __
scp -R__
took about 5:40 minutes. (That is even though it doesn't seem to establish a new connection for each file as ftp(1) does, nor have much overhead at all. So tar(1) could just be better at doing this than scp(1).)
+In a rudimentary test involving about 200MB of variously sized files, the tar(1)
stream finished in about 4:00 minutes, where <tt>
scp -R</tt>
took about 5:40 minutes. (That is even though it doesn't seem to establish a new connection for each file as ftp(1) does, nor have much overhead at all. So tar(1) could just be better at doing this than scp(1).)
+
!!! Executing the same command on multiple machines
-Check out the distributed shell dsh(1). It lets you [SSH] to all your
drones and execute the same series of commands, watching the output as you go.
+Check out the distributed shell,
dsh(1). It lets you [SSH] to a set of
drones and execute the same series of commands on all of them
, watching the output as you go.
+
!!! [SSH]ing to not directly reachable hosts
-Suppose you have a shell account on __
safe__
, a machine on a [NAT]ted [LAN] without a public [IP] address assigned to it. Let's also suppose you can [SSH] to the publicly visible gateway router of that [LAN], __
door__
, and that on this machine a copy of nc(1) (aka netcat) is installed. With the aid of a config file alias for the [NAT]ted host and a config directive called __!
ProxyCommand__
, you can easily set yourself up such that [SSH]ing to __
safe__
is no different from [SSH]ing to any publicly visible box:
+Suppose you have a shell account on <tt>
safe</tt>
, a machine on a [NAT]ted [LAN] without a public [IP] address assigned to it. Let's also suppose you can [SSH] to the publicly visible gateway router of that [LAN], <tt>
door</tt>
, and that on this machine a copy of nc(1) (aka netcat) is installed. With the aid of a config file alias for the [NAT]ted host and a config directive called <tt>~
ProxyCommand</tt>
, you can easily set yourself up such that [SSH]ing to <tt>
safe</tt>
is no different from [SSH]ing to any publicly visible box:
-
# this section
isn't necessary of course
- Host door
-
Protocol 2
-
User me
- !
HostName homelan.at.dsl.my.isp.com
- # but this one is
- Host safe
-
Protocol 2
-
User me
- !
HostName 192.168..42
- __!
ProxyCommand ssh door nc -q 0 safe 22__
+<pre>
+
# this stanza
isn't necessary of course
+Host door
+
Protocol 2
+
User me
+ ~
HostName homelan.at.dsl.my.isp.com
+# but this one is
+Host safe
+
Protocol 2
+
User me
+ ~
HostName 192.168..42
+ <b>~
ProxyCommand ssh door nc -q 0 safe 22</b>
+</pre>
-If you have the sshd(8) running on a different port than 22 (the standard [SSH] port) on __
safe__
, you need to change the argument to nc(1) accordingly, of course. Note the "-q " argument to netcat -
without this, you will likely end up with stale netcat processes on the intermediary machine. Now, you can just
+If you have the sshd(8) running on a different port than 22 (the standard [SSH] port) on <tt>
safe</tt>
, you need to change the argument to nc(1) accordingly, of course. Note the "<tt>
-q </tt>
" argument to netcat –
without this, you will likely end up with stale netcat processes on the intermediary machine. Now, you can just <tt>ssh safe</tt> and [SSH] will transparently invoke another copy of itself that connects to <tt>door</tt> and uses the netcat installed there to establish a connection from <tt>door</tt> to <tt>safe</tt>. netcat's STDIN/STDOUT is tunnelled back to your via your slave [SSH] connection to <tt>door</tt>, across which the primary [SSH] process can then communicate with the sshd(8) on <tt>safe</tt>.
- $ ssh safe
+Note that since the master [SSH] process is only communicating with the proxy process, it has no way of knowing the [IP] address of the remote host it is talking to. Since its address is needed to verify its host key's authenticity, it is advisable to use a <tt>~HostName</tt> directive for the proxied host to specify its address. Since the address is not otherwise used, you ''can'' leave it out or even enter something fake – you'll just get a complaint from [SSH].
-and [SSH] will transparently invoke another copy of itself
that connects to __door__ and uses
the netcat installed there to establish a connection from __door__ to __safe__
. netcat's STDIN/STDOUT
is tunnelled back to your via your slave
[SSH
] connection to __door__
, across which the primary
[SSH] process can then communicate with
the sshd
(8) on __safe__
.
+Finally, remember
that <tt>ssh foo nc bar 1234</tt> is just one example of what
the proxy command could be
. The only requirement
is that it forward the traffic, whether that be a
[TCP
] connection or even anything else
, to and from
[SSH] over STDIN/STDOUT. You might even use something like <tt>~ProxyCommand pppd nodetach call <i>foo</i></tt> and have
the remote getty
(8) launch <tt>sshd -i</tt>
on the incoming line, thus logging into a machine that's not even connected to the InterNet
.
-Note that since
the master
[SSH] process is only communicating with the proxy process, it has no way of knowing the [IP] address of the remote host it is talking
to. Since its address is needed to verify its host key's authenticity
, it is advisable to use
a __!HostName__ directive
for the proxied host to specify its address. Since the address is not otherwise used,
you ''
can'' leave it out or even enter something fake - you'll just get a complaint from
[SSH].
+The possibilities are endless. In
the standard case of using a slave
[SSH] connection
to some gateway
, nothing stops you from using
a <tt>~ProxyCommand</tt> in the alias configured
for the gateway – so
you can build an entire cascade of
[SSH] tunneled connections from one gateway to the next. Of course eventually the onion of tunnels wrapped around the connection will push the latency up to and the throughput down to unworkable levels
.
-Finally, remember that __ssh foo nc bar 1234__ is just one example of what the proxy command could be. The only requirement is that it forward the traffic, whether that be a TCP connection or even anything else, to and from [SSH] over STDIN/STDOUT. You might even use something like
-
- !ProxyCommand pppd nodetach call __foo__
-
-and have the remote getty(8) launch __[sshd|sshd(8)] -i__ on the incoming line, thus logging into a machine that's not even connected to the InterNet.
-
-The possibilities are endless. In the standard case of using a slave [SSH] connection to some gateway, nothing stops you from using a __!ProxyCommand__ in the alias configured for the gateway - so you can build an entire cascade of [SSH] tunneled connection from one gateway to the next. Of course eventually the onion of tunnels wrapped around the connection will push the latency up and the throughput down to unworkable levels.
!!! Improving loss of connection detection / coping with flaky net links
-Configure your [SSH] client to keep making sure it can still talk to the remote host if it hasn't received any data in a while. This is done by setting __!
ServerAliveInterval__
in your __
.ssh/config__
to how many seconds of silence the client should wait. The __!
ServerAliveCountMax__
directive defines how many attempts to get a reaction from the remote host may go unanswered before the [SSH] clients decides the connection has been lost. If you specify 5 seconds and 3 tries, a dead connection will be detected in 15 seconds.
+Configure your [SSH] client to keep making sure it can still talk to the remote host if it hasn't received any data in a while. This is done by setting <tt>~
ServerAliveInterval</tt>
in your <tt>
.ssh/config</tt>
to how many seconds of silence the client should wait. The <tt>~
ServerAliveCountMax</tt>
directive defines how many attempts to get a reaction from the remote host may go unanswered before the [SSH] clients decides the connection has been lost. If you specify 5 seconds and 3 tries, a dead connection will be detected in 15 seconds.
The default values are 0 seconds, which means never, and 3 tries.
Pick these according to bandwidth, ping time to the server, and packet loss on your link.
+
!!! Speeding up transfer rates
-[SSH] can use [gzip] compression on any connection, and will use a modest level by default. Compression is a great idea if you are forwarding X sessions on a dial-up or slow network. It can be turned on using the __
-C__
switch, or using __
Compression yes__
in your __
.ssh/config__
.
+[SSH] can use [gzip] compression on any connection, and will use a modest level by default. Compression is a great idea if you are forwarding [
X]
sessions on a dial-up or slow network. It can be turned on using the <tt>
-C</tt>
switch, or using <tt>
Compression yes</tt>
in your <tt>
.ssh/config</tt>.
+
+Changing your encryption cipher from the common default of DES or 3DES can speed things up as well. BlowFish and [AES] are faster, and new versions of [OpenSSH] default to BlowFish. The CommandLine switch to change the cipher is <tt>-c blowfish</tt>. For <tt>.ssh/config</tt> it depends on whether you are connecting with SSH1 or SSH2
.
-Changing your encryption cipher from the common default of DES or 3DES can speed things up as well. Blowfish and AES are faster, and new versions of [OpenSSH] default to Blowfish. The CommandLine switch to change the cipher is __-c
blowfish__. For __.ssh/config__ it depends on whether you are connecting with
SSH1 or
SSH2.
+<verbatim>
+Cipher
blowfish #
SSH1
+Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc #
SSH2
+</verbatim>
- Cipher blowfish # SSH1
- Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # SSH2
-!!! SSH for apt-get(8)
+!!! [
SSH]
for apt-get(8)
-If you try and run apt-get without a terminal or the right paths, it won't be able to find dpkg or display debconf information. This is the way I've found (useful for remote upgrading of machines -
note, only do this off security or your own repository...
)
+If you try and run apt-get(8)
without a terminal or the right paths, it won't be able to find dpkg(8)
or display debconf information. This is the way I've found (useful for remote upgrading of machines –
note, only do this off security or your own repository…
)
-
ssh root@[[
hostname]
-t "su - -c 'apt-get update && apt-get upgrade'"
+<pre>
+
ssh root@<i>
hostname</i>
-t "su - -c 'apt-get update && apt-get upgrade'"
+</pre>
----
Part of CategorySecurity and CategoryNetworking
