ssh.0 revision 197670
1SSH(1) OpenBSD Reference Manual SSH(1) 2 3NAME 4 ssh - OpenSSH SSH client (remote login program) 5 6SYNOPSIS 7 ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] 8 [-D [bind_address:]port] [-e escape_char] [-F configfile] 9 [-i identity_file] [-L [bind_address:]port:host:hostport] 10 [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] 11 [-R [bind_address:]port:host:hostport] [-S ctl_path] 12 [-w local_tun[:remote_tun]] [user@]hostname [command] 13 14DESCRIPTION 15 ssh (SSH client) is a program for logging into a remote machine and for 16 executing commands on a remote machine. It is intended to replace rlogin 17 and rsh, and provide secure encrypted communications between two untrust- 18 ed hosts over an insecure network. X11 connections and arbitrary TCP 19 ports can also be forwarded over the secure channel. 20 21 ssh connects and logs into the specified hostname (with optional user 22 name). The user must prove his/her identity to the remote machine using 23 one of several methods depending on the protocol version used (see be- 24 low). 25 26 If command is specified, it is executed on the remote host instead of a 27 login shell. 28 29 The options are as follows: 30 31 -1 Forces ssh to try protocol version 1 only. 32 33 -2 Forces ssh to try protocol version 2 only. 34 35 -4 Forces ssh to use IPv4 addresses only. 36 37 -6 Forces ssh to use IPv6 addresses only. 38 39 -A Enables forwarding of the authentication agent connection. This 40 can also be specified on a per-host basis in a configuration 41 file. 42 43 Agent forwarding should be enabled with caution. Users with the 44 ability to bypass file permissions on the remote host (for the 45 agent's Unix-domain socket) can access the local agent through 46 the forwarded connection. An attacker cannot obtain key material 47 from the agent, however they can perform operations on the keys 48 that enable them to authenticate using the identities loaded into 49 the agent. 50 51 -a Disables forwarding of the authentication agent connection. 52 53 -b bind_address 54 Use bind_address on the local machine as the source address of 55 the connection. Only useful on systems with more than one ad- 56 dress. 57 58 -C Requests compression of all data (including stdin, stdout, 59 stderr, and data for forwarded X11 and TCP connections). The 60 compression algorithm is the same used by gzip(1), and the 61 ``level'' can be controlled by the CompressionLevel option for 62 protocol version 1. Compression is desirable on modem lines and 63 other slow connections, but will only slow down things on fast 64 networks. The default value can be set on a host-by-host basis 65 in the configuration files; see the Compression option. 66 67 -c cipher_spec 68 Selects the cipher specification for encrypting the session. 69 70 Protocol version 1 allows specification of a single cipher. The 71 supported values are ``3des'', ``blowfish'', and ``des''. 3des 72 (triple-des) is an encrypt-decrypt-encrypt triple with three dif- 73 ferent keys. It is believed to be secure. blowfish is a fast 74 block cipher; it appears very secure and is much faster than 75 3des. des is only supported in the ssh client for interoperabil- 76 ity with legacy protocol 1 implementations that do not support 77 the 3des cipher. Its use is strongly discouraged due to crypto- 78 graphic weaknesses. The default is ``3des''. 79 80 For protocol version 2, cipher_spec is a comma-separated list of 81 ciphers listed in order of preference. See the Ciphers keyword 82 for more information. 83 84 -D [bind_address:]port 85 Specifies a local ``dynamic'' application-level port forwarding. 86 This works by allocating a socket to listen to port on the local 87 side, optionally bound to the specified bind_address. Whenever a 88 connection is made to this port, the connection is forwarded over 89 the secure channel, and the application protocol is then used to 90 determine where to connect to from the remote machine. Currently 91 the SOCKS4 and SOCKS5 protocols are supported, and ssh will act 92 as a SOCKS server. Only root can forward privileged ports. Dy- 93 namic port forwardings can also be specified in the configuration 94 file. 95 96 IPv6 addresses can be specified with an alternative syntax: 97 [bind_address/]port or by enclosing the address in square brack- 98 ets. Only the superuser can forward privileged ports. By de- 99 fault, the local port is bound in accordance with the 100 GatewayPorts setting. However, an explicit bind_address may be 101 used to bind the connection to a specific address. The 102 bind_address of ``localhost'' indicates that the listening port 103 be bound for local use only, while an empty address or `*' indi- 104 cates that the port should be available from all interfaces. 105 106 -e escape_char 107 Sets the escape character for sessions with a pty (default: `~'). 108 The escape character is only recognized at the beginning of a 109 line. The escape character followed by a dot (`.') closes the 110 connection; followed by control-Z suspends the connection; and 111 followed by itself sends the escape character once. Setting the 112 character to ``none'' disables any escapes and makes the session 113 fully transparent. 114 115 -F configfile 116 Specifies an alternative per-user configuration file. If a con- 117 figuration file is given on the command line, the system-wide 118 configuration file (/etc/ssh/ssh_config) will be ignored. The 119 default for the per-user configuration file is ~/.ssh/config. 120 121 -f Requests ssh to go to background just before command execution. 122 This is useful if ssh is going to ask for passwords or passphras- 123 es, but the user wants it in the background. This implies -n. 124 The recommended way to start X11 programs at a remote site is 125 with something like ssh -f host xterm. 126 127 If the ExitOnForwardFailure configuration option is set to 128 ``yes'', then a client started with -f will wait for all remote 129 port forwards to be successfully established before placing it- 130 self in the background. 131 132 -g Allows remote hosts to connect to local forwarded ports. 133 134 -I smartcard_device 135 Specify the device ssh should use to communicate with a smartcard 136 used for storing the user's private RSA key. This option is only 137 available if support for smartcard devices is compiled in (de- 138 fault is no support). 139 140 -i identity_file 141 Selects a file from which the identity (private key) for RSA or 142 DSA authentication is read. The default is ~/.ssh/identity for 143 protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro- 144 tocol version 2. Identity files may also be specified on a per- 145 host basis in the configuration file. It is possible to have 146 multiple -i options (and multiple identities specified in config- 147 uration files). 148 149 -K Enables GSSAPI-based authentication and forwarding (delegation) 150 of GSSAPI credentials to the server. 151 152 -k Disables forwarding (delegation) of GSSAPI credentials to the 153 server. 154 155 -L [bind_address:]port:host:hostport 156 Specifies that the given port on the local (client) host is to be 157 forwarded to the given host and port on the remote side. This 158 works by allocating a socket to listen to port on the local side, 159 optionally bound to the specified bind_address. Whenever a con- 160 nection is made to this port, the connection is forwarded over 161 the secure channel, and a connection is made to host port 162 hostport from the remote machine. Port forwardings can also be 163 specified in the configuration file. IPv6 addresses can be spec- 164 ified with an alternative syntax: [bind_address/]port/host/host- 165 port or by enclosing the address in square brackets. Only the 166 superuser can forward privileged ports. By default, the local 167 port is bound in accordance with the GatewayPorts setting. How- 168 ever, an explicit bind_address may be used to bind the connection 169 to a specific address. The bind_address of ``localhost'' indi- 170 cates that the listening port be bound for local use only, while 171 an empty address or `*' indicates that the port should be avail- 172 able from all interfaces. 173 174 -l login_name 175 Specifies the user to log in as on the remote machine. This also 176 may be specified on a per-host basis in the configuration file. 177 178 -M Places the ssh client into ``master'' mode for connection shar- 179 ing. Multiple -M options places ssh into ``master'' mode with 180 confirmation required before slave connections are accepted. Re- 181 fer to the description of ControlMaster in ssh_config(5) for de- 182 tails. 183 184 -m mac_spec 185 Additionally, for protocol version 2 a comma-separated list of 186 MAC (message authentication code) algorithms can be specified in 187 order of preference. See the MACs keyword for more information. 188 189 -N Do not execute a remote command. This is useful for just for- 190 warding ports (protocol version 2 only). 191 192 -n Redirects stdin from /dev/null (actually, prevents reading from 193 stdin). This must be used when ssh is run in the background. A 194 common trick is to use this to run X11 programs on a remote ma- 195 chine. For example, ssh -n shadows.cs.hut.fi emacs & will start 196 an emacs on shadows.cs.hut.fi, and the X11 connection will be au- 197 tomatically forwarded over an encrypted channel. The ssh program 198 will be put in the background. (This does not work if ssh needs 199 to ask for a password or passphrase; see also the -f option.) 200 201 -O ctl_cmd 202 Control an active connection multiplexing master process. When 203 the -O option is specified, the ctl_cmd argument is interpreted 204 and passed to the master process. Valid commands are: ``check'' 205 (check that the master process is running) and ``exit'' (request 206 the master to exit). 207 208 -o option 209 Can be used to give options in the format used in the configura- 210 tion file. This is useful for specifying options for which there 211 is no separate command-line flag. For full details of the op- 212 tions listed below, and their possible values, see ssh_config(5). 213 214 AddressFamily 215 BatchMode 216 BindAddress 217 ChallengeResponseAuthentication 218 CheckHostIP 219 Cipher 220 Ciphers 221 ClearAllForwardings 222 Compression 223 CompressionLevel 224 ConnectionAttempts 225 ConnectTimeout 226 ControlMaster 227 ControlPath 228 DynamicForward 229 EscapeChar 230 ExitOnForwardFailure 231 ForwardAgent 232 ForwardX11 233 ForwardX11Trusted 234 GatewayPorts 235 GlobalKnownHostsFile 236 GSSAPIAuthentication 237 GSSAPIDelegateCredentials 238 HashKnownHosts 239 Host 240 HostbasedAuthentication 241 HostKeyAlgorithms 242 HostKeyAlias 243 HostName 244 IdentityFile 245 IdentitiesOnly 246 KbdInteractiveDevices 247 LocalCommand 248 LocalForward 249 LogLevel 250 MACs 251 NoHostAuthenticationForLocalhost 252 NumberOfPasswordPrompts 253 PasswordAuthentication 254 PermitLocalCommand 255 Port 256 PreferredAuthentications 257 Protocol 258 ProxyCommand 259 PubkeyAuthentication 260 RekeyLimit 261 RemoteForward 262 RhostsRSAAuthentication 263 RSAAuthentication 264 SendEnv 265 ServerAliveInterval 266 ServerAliveCountMax 267 SmartcardDevice 268 StrictHostKeyChecking 269 TCPKeepAlive 270 Tunnel 271 TunnelDevice 272 UsePrivilegedPort 273 User 274 UserKnownHostsFile 275 VerifyHostKeyDNS 276 VisualHostKey 277 XAuthLocation 278 279 -p port 280 Port to connect to on the remote host. This can be specified on 281 a per-host basis in the configuration file. 282 283 -q Quiet mode. Causes most warning and diagnostic messages to be 284 suppressed. 285 286 -R [bind_address:]port:host:hostport 287 Specifies that the given port on the remote (server) host is to 288 be forwarded to the given host and port on the local side. This 289 works by allocating a socket to listen to port on the remote 290 side, and whenever a connection is made to this port, the connec- 291 tion is forwarded over the secure channel, and a connection is 292 made to host port hostport from the local machine. 293 294 Port forwardings can also be specified in the configuration file. 295 Privileged ports can be forwarded only when logging in as root on 296 the remote machine. IPv6 addresses can be specified by enclosing 297 the address in square braces or using an alternative syntax: 298 [bind_address/]host/port/hostport. 299 300 By default, the listening socket on the server will be bound to 301 the loopback interface only. This may be overridden by specify- 302 ing a bind_address. An empty bind_address, or the address `*', 303 indicates that the remote socket should listen on all interfaces. 304 Specifying a remote bind_address will only succeed if the serv- 305 er's GatewayPorts option is enabled (see sshd_config(5)). 306 307 If the port argument is `0', the listen port will be dynamically 308 allocated on the server and reported to the client at run time. 309 310 -S ctl_path 311 Specifies the location of a control socket for connection shar- 312 ing. Refer to the description of ControlPath and ControlMaster 313 in ssh_config(5) for details. 314 315 -s May be used to request invocation of a subsystem on the remote 316 system. Subsystems are a feature of the SSH2 protocol which fa- 317 cilitate the use of SSH as a secure transport for other applica- 318 tions (eg. sftp(1)). The subsystem is specified as the remote 319 command. 320 321 -T Disable pseudo-tty allocation. 322 323 -t Force pseudo-tty allocation. This can be used to execute arbi- 324 trary screen-based programs on a remote machine, which can be 325 very useful, e.g. when implementing menu services. Multiple -t 326 options force tty allocation, even if ssh has no local tty. 327 328 -V Display the version number and exit. 329 330 -v Verbose mode. Causes ssh to print debugging messages about its 331 progress. This is helpful in debugging connection, authentica- 332 tion, and configuration problems. Multiple -v options increase 333 the verbosity. The maximum is 3. 334 335 -w local_tun[:remote_tun] 336 Requests tunnel device forwarding with the specified tun(4) de- 337 vices between the client (local_tun) and the server (remote_tun). 338 339 The devices may be specified by numerical ID or the keyword 340 ``any'', which uses the next available tunnel device. If 341 remote_tun is not specified, it defaults to ``any''. See also 342 the Tunnel and TunnelDevice directives in ssh_config(5). If the 343 Tunnel directive is unset, it is set to the default tunnel mode, 344 which is ``point-to-point''. 345 346 -X Enables X11 forwarding. This can also be specified on a per-host 347 basis in a configuration file. 348 349 X11 forwarding should be enabled with caution. Users with the 350 ability to bypass file permissions on the remote host (for the 351 user's X authorization database) can access the local X11 display 352 through the forwarded connection. An attacker may then be able 353 to perform activities such as keystroke monitoring. 354 355 For this reason, X11 forwarding is subjected to X11 SECURITY ex- 356 tension restrictions by default. Please refer to the ssh -Y op- 357 tion and the ForwardX11Trusted directive in ssh_config(5) for 358 more information. 359 360 -x Disables X11 forwarding. 361 362 -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not 363 subjected to the X11 SECURITY extension controls. 364 365 -y Send log information using the syslog(3) system module. By de- 366 fault this information is sent to stderr. 367 368 ssh may additionally obtain configuration data from a per-user configura- 369 tion file and a system-wide configuration file. The file format and con- 370 figuration options are described in ssh_config(5). 371 372 ssh exits with the exit status of the remote command or with 255 if an 373 error occurred. 374 375AUTHENTICATION 376 The OpenSSH SSH client supports SSH protocols 1 and 2. Protocol 2 is the 377 default, with ssh falling back to protocol 1 if it detects protocol 2 is 378 unsupported. These settings may be altered using the Protocol option in 379 ssh_config(5), or enforced using the -1 and -2 options (see above). Both 380 protocols support similar authentication methods, but protocol 2 is pre- 381 ferred since it provides additional mechanisms for confidentiality (the 382 traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and 383 integrity (hmac-md5, hmac-sha1, umac-64, hmac-ripemd160). Protocol 1 384 lacks a strong mechanism for ensuring the integrity of the connection. 385 386 The methods available for authentication are: GSSAPI-based authentica- 387 tion, host-based authentication, public key authentication, challenge-re- 388 sponse authentication, and password authentication. Authentication meth- 389 ods are tried in the order specified above, though protocol 2 has a con- 390 figuration option to change the default order: PreferredAuthentications. 391 392 Host-based authentication works as follows: If the machine the user logs 393 in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote 394 machine, and the user names are the same on both sides, or if the files 395 ~/.rhosts or ~/.shosts exist in the user's home directory on the remote 396 machine and contain a line containing the name of the client machine and 397 the name of the user on that machine, the user is considered for login. 398 Additionally, the server must be able to verify the client's host key 399 (see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, 400 below) for login to be permitted. This authentication method closes se- 401 curity holes due to IP spoofing, DNS spoofing, and routing spoofing. 402 [Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the 403 rlogin/rsh protocol in general, are inherently insecure and should be 404 disabled if security is desired.] 405 406 Public key authentication works as follows: The scheme is based on pub- 407 lic-key cryptography, using cryptosystems where encryption and decryption 408 are done using separate keys, and it is unfeasible to derive the decryp- 409 tion key from the encryption key. The idea is that each user creates a 410 public/private key pair for authentication purposes. The server knows 411 the public key, and only the user knows the private key. ssh implements 412 public key authentication protocol automatically, using either the RSA or 413 DSA algorithms. Protocol 1 is restricted to using only RSA keys, but 414 protocol 2 may use either. The HISTORY section of ssl(8) contains a 415 brief discussion of the two algorithms. 416 417 The file ~/.ssh/authorized_keys lists the public keys that are permitted 418 for logging in. When the user logs in, the ssh program tells the server 419 which key pair it would like to use for authentication. The client 420 proves that it has access to the private key and the server checks that 421 the corresponding public key is authorized to accept the account. 422 423 The user creates his/her key pair by running ssh-keygen(1). This stores 424 the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 425 2 DSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in 426 ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), or 427 ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user's home directory. The us- 428 er should then copy the public key to ~/.ssh/authorized_keys in his/her 429 home directory on the remote machine. The authorized_keys file corre- 430 sponds to the conventional ~/.rhosts file, and has one key per line, 431 though the lines can be very long. After this, the user can log in with- 432 out giving the password. 433 434 The most convenient way to use public key authentication may be with an 435 authentication agent. See ssh-agent(1) for more information. 436 437 Challenge-response authentication works as follows: The server sends an 438 arbitrary "challenge" text, and prompts for a response. Protocol 2 al- 439 lows multiple challenges and responses; protocol 1 is restricted to just 440 one challenge/response. Examples of challenge-response authentication 441 include BSD Authentication (see login.conf(5)) and PAM (some non-OpenBSD 442 systems). 443 444 Finally, if other authentication methods fail, ssh prompts the user for a 445 password. The password is sent to the remote host for checking; however, 446 since all communications are encrypted, the password cannot be seen by 447 someone listening on the network. 448 449 ssh automatically maintains and checks a database containing identifica- 450 tion for all hosts it has ever been used with. Host keys are stored in 451 ~/.ssh/known_hosts in the user's home directory. Additionally, the file 452 /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any 453 new hosts are automatically added to the user's file. If a host's iden- 454 tification ever changes, ssh warns about this and disables password au- 455 thentication to prevent server spoofing or man-in-the-middle attacks, 456 which could otherwise be used to circumvent the encryption. The 457 StrictHostKeyChecking option can be used to control logins to machines 458 whose host key is not known or has changed. 459 460 When the user's identity has been accepted by the server, the server ei- 461 ther executes the given command, or logs into the machine and gives the 462 user a normal shell on the remote machine. All communication with the 463 remote command or shell will be automatically encrypted. 464 465 If a pseudo-terminal has been allocated (normal login session), the user 466 may use the escape characters noted below. 467 468 If no pseudo-tty has been allocated, the session is transparent and can 469 be used to reliably transfer binary data. On most systems, setting the 470 escape character to ``none'' will also make the session transparent even 471 if a tty is used. 472 473 The session terminates when the command or shell on the remote machine 474 exits and all X11 and TCP connections have been closed. 475 476ESCAPE CHARACTERS 477 When a pseudo-terminal has been requested, ssh supports a number of func- 478 tions through the use of an escape character. 479 480 A single tilde character can be sent as ~~ or by following the tilde by a 481 character other than those described below. The escape character must 482 always follow a newline to be interpreted as special. The escape charac- 483 ter can be changed in configuration files using the EscapeChar configura- 484 tion directive or on the command line by the -e option. 485 486 The supported escapes (assuming the default `~') are: 487 488 ~. Disconnect. 489 490 ~^Z Background ssh. 491 492 ~# List forwarded connections. 493 494 ~& Background ssh at logout when waiting for forwarded connection / 495 X11 sessions to terminate. 496 497 ~? Display a list of escape characters. 498 499 ~B Send a BREAK to the remote system (only useful for SSH protocol 500 version 2 and if the peer supports it). 501 502 ~C Open command line. Currently this allows the addition of port 503 forwardings using the -L, -R and -D options (see above). It also 504 allows the cancellation of existing remote port-forwardings using 505 -KR[bind_address:]port. !command allows the user to execute a 506 local command if the PermitLocalCommand option is enabled in 507 ssh_config(5). Basic help is available, using the -h option. 508 509 ~R Request rekeying of the connection (only useful for SSH protocol 510 version 2 and if the peer supports it). 511 512TCP FORWARDING 513 Forwarding of arbitrary TCP connections over the secure channel can be 514 specified either on the command line or in a configuration file. One 515 possible application of TCP forwarding is a secure connection to a mail 516 server; another is going through firewalls. 517 518 In the example below, we look at encrypting communication between an IRC 519 client and server, even though the IRC server does not directly support 520 encrypted communications. This works as follows: the user connects to 521 the remote host using ssh, specifying a port to be used to forward con- 522 nections to the remote server. After that it is possible to start the 523 service which is to be encrypted on the client machine, connecting to the 524 same local port, and ssh will encrypt and forward the connection. 525 526 The following example tunnels an IRC session from client machine 527 ``127.0.0.1'' (localhost) to remote server ``server.example.com'': 528 529 $ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 530 $ irc -c '#users' -p 1234 pinky 127.0.0.1 531 532 This tunnels a connection to IRC server ``server.example.com'', joining 533 channel ``#users'', nickname ``pinky'', using port 1234. It doesn't mat- 534 ter which port is used, as long as it's greater than 1023 (remember, only 535 root can open sockets on privileged ports) and doesn't conflict with any 536 ports already in use. The connection is forwarded to port 6667 on the 537 remote server, since that's the standard port for IRC services. 538 539 The -f option backgrounds ssh and the remote command ``sleep 10'' is 540 specified to allow an amount of time (10 seconds, in the example) to 541 start the service which is to be tunnelled. If no connections are made 542 within the time specified, ssh will exit. 543 544X11 FORWARDING 545 If the ForwardX11 variable is set to ``yes'' (or see the description of 546 the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY 547 environment variable is set), the connection to the X11 display is auto- 548 matically forwarded to the remote side in such a way that any X11 pro- 549 grams started from the shell (or command) will go through the encrypted 550 channel, and the connection to the real X server will be made from the 551 local machine. The user should not manually set DISPLAY. Forwarding of 552 X11 connections can be configured on the command line or in configuration 553 files. 554 555 The DISPLAY value set by ssh will point to the server machine, but with a 556 display number greater than zero. This is normal, and happens because 557 ssh creates a ``proxy'' X server on the server machine for forwarding the 558 connections over the encrypted channel. 559 560 ssh will also automatically set up Xauthority data on the server machine. 561 For this purpose, it will generate a random authorization cookie, store 562 it in Xauthority on the server, and verify that any forwarded connections 563 carry this cookie and replace it by the real cookie when the connection 564 is opened. The real authentication cookie is never sent to the server 565 machine (and no cookies are sent in the plain). 566 567 If the ForwardAgent variable is set to ``yes'' (or see the description of 568 the -A and -a options above) and the user is using an authentication 569 agent, the connection to the agent is automatically forwarded to the re- 570 mote side. 571 572VERIFYING HOST KEYS 573 When connecting to a server for the first time, a fingerprint of the 574 server's public key is presented to the user (unless the option 575 StrictHostKeyChecking has been disabled). Fingerprints can be determined 576 using ssh-keygen(1): 577 578 $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 579 580 If the fingerprint is already known, it can be matched and the key can be 581 accepted or rejected. Because of the difficulty of comparing host keys 582 just by looking at hex strings, there is also support to compare host 583 keys visually, using random art. By setting the VisualHostKey option to 584 ``yes'', a small ASCII graphic gets displayed on every login to a server, 585 no matter if the session itself is interactive or not. By learning the 586 pattern a known server produces, a user can easily find out that the host 587 key has changed when a completely different pattern is displayed. Be- 588 cause these patterns are not unambiguous however, a pattern that looks 589 similar to the pattern remembered only gives a good probability that the 590 host key is the same, not guaranteed proof. 591 592 To get a listing of the fingerprints along with their random art for all 593 known hosts, the following command line can be used: 594 595 $ ssh-keygen -lv -f ~/.ssh/known_hosts 596 597 If the fingerprint is unknown, an alternative method of verification is 598 available: SSH fingerprints verified by DNS. An additional resource 599 record (RR), SSHFP, is added to a zonefile and the connecting client is 600 able to match the fingerprint with that of the key presented. 601 602 In this example, we are connecting a client to a server, 603 ``host.example.com''. The SSHFP resource records should first be added 604 to the zonefile for host.example.com: 605 606 $ ssh-keygen -r host.example.com. 607 608 The output lines will have to be added to the zonefile. To check that 609 the zone is answering fingerprint queries: 610 611 $ dig -t SSHFP host.example.com 612 613 Finally the client connects: 614 615 $ ssh -o "VerifyHostKeyDNS ask" host.example.com 616 [...] 617 Matching host key fingerprint found in DNS. 618 Are you sure you want to continue connecting (yes/no)? 619 620 See the VerifyHostKeyDNS option in ssh_config(5) for more information. 621 622SSH-BASED VIRTUAL PRIVATE NETWORKS 623 ssh contains support for Virtual Private Network (VPN) tunnelling using 624 the tun(4) network pseudo-device, allowing two networks to be joined se- 625 curely. The sshd_config(5) configuration option PermitTunnel controls 626 whether the server supports this, and at what level (layer 2 or 3 traf- 627 fic). 628 629 The following example would connect client network 10.0.50.0/24 with re- 630 mote network 10.0.99.0/24 using a point-to-point connection from 10.1.1.1 631 to 10.1.1.2, provided that the SSH server running on the gateway to the 632 remote network, at 192.168.1.15, allows it. 633 634 On the client: 635 636 # ssh -f -w 0:1 192.168.1.15 true 637 # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 638 # route add 10.0.99.0/24 10.1.1.2 639 640 On the server: 641 642 # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 643 # route add 10.0.50.0/24 10.1.1.1 644 645 Client access may be more finely tuned via the /root/.ssh/authorized_keys 646 file (see below) and the PermitRootLogin server option. The following 647 entry would permit connections on tun(4) device 1 from user ``jane'' and 648 on tun device 2 from user ``john'', if PermitRootLogin is set to 649 ``forced-commands-only'': 650 651 tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane 652 tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john 653 654 Since an SSH-based setup entails a fair amount of overhead, it may be 655 more suited to temporary setups, such as for wireless VPNs. More perma- 656 nent VPNs are better provided by tools such as ipsecctl(8) and 657 isakmpd(8). 658 659ENVIRONMENT 660 ssh will normally set the following environment variables: 661 662 DISPLAY The DISPLAY variable indicates the location of the 663 X11 server. It is automatically set by ssh to 664 point to a value of the form ``hostname:n'', where 665 ``hostname'' indicates the host where the shell 666 runs, and `n' is an integer >= 1. ssh uses this 667 special value to forward X11 connections over the 668 secure channel. The user should normally not set 669 DISPLAY explicitly, as that will render the X11 670 connection insecure (and will require the user to 671 manually copy any required authorization cookies). 672 673 HOME Set to the path of the user's home directory. 674 675 LOGNAME Synonym for USER; set for compatibility with sys- 676 tems that use this variable. 677 678 MAIL Set to the path of the user's mailbox. 679 680 PATH Set to the default PATH, as specified when compil- 681 ing ssh. 682 683 SSH_ASKPASS If ssh needs a passphrase, it will read the 684 passphrase from the current terminal if it was run 685 from a terminal. If ssh does not have a terminal 686 associated with it but DISPLAY and SSH_ASKPASS are 687 set, it will execute the program specified by 688 SSH_ASKPASS and open an X11 window to read the 689 passphrase. This is particularly useful when call- 690 ing ssh from a .xsession or related script. (Note 691 that on some machines it may be necessary to redi- 692 rect the input from /dev/null to make this work.) 693 694 SSH_AUTH_SOCK Identifies the path of a UNIX-domain socket used to 695 communicate with the agent. 696 697 SSH_CONNECTION Identifies the client and server ends of the con- 698 nection. The variable contains four space-separat- 699 ed values: client IP address, client port number, 700 server IP address, and server port number. 701 702 SSH_ORIGINAL_COMMAND This variable contains the original command line if 703 a forced command is executed. It can be used to 704 extract the original arguments. 705 706 SSH_TTY This is set to the name of the tty (path to the de- 707 vice) associated with the current shell or command. 708 If the current session has no tty, this variable is 709 not set. 710 711 TZ This variable is set to indicate the present time 712 zone if it was set when the daemon was started 713 (i.e. the daemon passes the value on to new connec- 714 tions). 715 716 USER Set to the name of the user logging in. 717 718 Additionally, ssh reads ~/.ssh/environment, and adds lines of the format 719 ``VARNAME=value'' to the environment if the file exists and users are al- 720 lowed to change their environment. For more information, see the 721 PermitUserEnvironment option in sshd_config(5). 722 723FILES 724 ~/.rhosts 725 This file is used for host-based authentication (see above). On 726 some machines this file may need to be world-readable if the us- 727 er's home directory is on an NFS partition, because sshd(8) reads 728 it as root. Additionally, this file must be owned by the user, 729 and must not have write permissions for anyone else. The recom- 730 mended permission for most machines is read/write for the user, 731 and not accessible by others. 732 733 ~/.shosts 734 This file is used in exactly the same way as .rhosts, but allows 735 host-based authentication without permitting login with 736 rlogin/rsh. 737 738 ~/.ssh/ 739 This directory is the default location for all user-specific con- 740 figuration and authentication information. There is no general 741 requirement to keep the entire contents of this directory secret, 742 but the recommended permissions are read/write/execute for the 743 user, and not accessible by others. 744 745 ~/.ssh/authorized_keys 746 Lists the public keys (RSA/DSA) that can be used for logging in 747 as this user. The format of this file is described in the 748 sshd(8) manual page. This file is not highly sensitive, but the 749 recommended permissions are read/write for the user, and not ac- 750 cessible by others. 751 752 ~/.ssh/config 753 This is the per-user configuration file. The file format and 754 configuration options are described in ssh_config(5). Because of 755 the potential for abuse, this file must have strict permissions: 756 read/write for the user, and not accessible by others. 757 758 ~/.ssh/environment 759 Contains additional definitions for environment variables; see 760 ENVIRONMENT, above. 761 762 ~/.ssh/identity 763 ~/.ssh/id_dsa 764 ~/.ssh/id_rsa 765 Contains the private key for authentication. These files contain 766 sensitive data and should be readable by the user but not acces- 767 sible by others (read/write/execute). ssh will simply ignore a 768 private key file if it is accessible by others. It is possible 769 to specify a passphrase when generating the key which will be 770 used to encrypt the sensitive part of this file using 3DES. 771 772 ~/.ssh/identity.pub 773 ~/.ssh/id_dsa.pub 774 ~/.ssh/id_rsa.pub 775 Contains the public key for authentication. These files are not 776 sensitive and can (but need not) be readable by anyone. 777 778 ~/.ssh/known_hosts 779 Contains a list of host keys for all hosts the user has logged 780 into that are not already in the systemwide list of known host 781 keys. See sshd(8) for further details of the format of this 782 file. 783 784 ~/.ssh/rc 785 Commands in this file are executed by ssh when the user logs in, 786 just before the user's shell (or command) is started. See the 787 sshd(8) manual page for more information. 788 789 /etc/hosts.equiv 790 This file is for host-based authentication (see above). It 791 should only be writable by root. 792 793 /etc/shosts.equiv 794 This file is used in exactly the same way as hosts.equiv, but al- 795 lows host-based authentication without permitting login with 796 rlogin/rsh. 797 798 /etc/ssh/ssh_config 799 Systemwide configuration file. The file format and configuration 800 options are described in ssh_config(5). 801 802 /etc/ssh/ssh_host_key 803 /etc/ssh/ssh_host_dsa_key 804 /etc/ssh/ssh_host_rsa_key 805 These three files contain the private parts of the host keys and 806 are used for host-based authentication. If protocol version 1 is 807 used, ssh must be setuid root, since the host key is readable on- 808 ly by root. For protocol version 2, ssh uses ssh-keysign(8) to 809 access the host keys, eliminating the requirement that ssh be se- 810 tuid root when host-based authentication is used. By default ssh 811 is not setuid root. 812 813 /etc/ssh/ssh_known_hosts 814 Systemwide list of known host keys. This file should be prepared 815 by the system administrator to contain the public host keys of 816 all machines in the organization. It should be world-readable. 817 See sshd(8) for further details of the format of this file. 818 819 /etc/ssh/sshrc 820 Commands in this file are executed by ssh when the user logs in, 821 just before the user's shell (or command) is started. See the 822 sshd(8) manual page for more information. 823 824SEE ALSO 825 scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), 826 tun(4), hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8) 827 828 The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006. 829 830 The Secure Shell (SSH) Protocol Architecture, RFC 4251, 2006. 831 832 The Secure Shell (SSH) Authentication Protocol, RFC 4252, 2006. 833 834 The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, 2006. 835 836 The Secure Shell (SSH) Connection Protocol, RFC 4254, 2006. 837 838 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 839 4255, 2006. 840 841 Generic Message Exchange Authentication for the Secure Shell Protocol 842 (SSH), RFC 4256, 2006. 843 844 The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, 2006. 845 846 The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, 2006. 847 848 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer 849 Protocol, RFC 4345, 2006. 850 851 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer 852 Protocol, RFC 4419, 2006. 853 854 The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006. 855 856 A. Perrig and D. Song, Hash Visualization: a New Technique to improve 857 Real-World Security, 1999, International Workshop on Cryptographic 858 Techniques and E-Commerce (CrypTEC '99). 859 860AUTHORS 861 OpenSSH is a derivative of the original and free ssh 1.2.12 release by 862 Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo 863 de Raadt and Dug Song removed many bugs, re-added newer features and 864 created OpenSSH. Markus Friedl contributed the support for SSH protocol 865 versions 1.5 and 2.0. 866 867OpenBSD 4.6 March 19, 2009 14 868