Agent forwarding is a mechanism whereby an SSH client allows an SSH server to use the local agent on the server, the user logs into, as if it was local there. We say that the private key is forwarded to the server1 in order to connect from server1 to server2.
Background
As I mentioned in my previous post, I switched to using SSH key auth for GitHub and Azure DevOps Repos a long time ago and found it a positive experience. At first I was a bit lazy and didn’t use passphrases on my keys, and just kept a copy of my keys in the .ssh folder in my User folder in Windows and another copy in ~/.ssh in WSL.
For day-to-day working this worked okay, but I finally got round to adding passphrases to my keys a while back and was less happy with the setup at that point. My previously suppressed niggles around having the keys in multiple places re-surfaced once I had to add handle passphrases in multiple systems on the same machine!
- Session key in cryptographic protocols is a per-session key used for encryption and integrity checking.
- /.ssh/authorizedkeys - contains keys which are allowed to connect which can be given options: command='command' - The command supplied by the user (if any) is ignored. Note that the client may specify TCP and/or X11 forwarding unless they are explicitly prohibited. Note that this option applies to shell, command or subsystem execution.
As it happens, recent versions of Windows ship with the OpenSSH Agent and Server but I didn’t want to have two SSH Authentication services each with their own set of keys. My last post shows how to get git in Windows to use the OpenSSH Agent to retrieve keys. In this post, I’ll walk through the journey to get SSH in WSL using keys from the Windows OpenSSH Agent. For details on installing and setting up the Windows OpenSSH Agent see the docs.
If you just want to set up the WSL SSH forwarding then skip to the final solution! Otherwise, let me take you on a tour…
Initial investigation
As I mentioned, my most common usage of SSH keys day-to-day is as a way to authenticate to git remotes. This lead me to this page in the GitHub docs which discusses SSH Agent forwarding and mentions the SSH_AUTH_SOCK environment variable.
After some reading it turns out that SSH_AUTH_SOCK controls the path to the UNIX socket that is used by SSH tools to communicate with the SSH Agent. This seemed like an interesting start, and fortunately I’d previously stumbled across the npiperelay from John Starks. The docs and examples for npiperelay have some examples for using npiperelay with the socat utility as a way of forwarding Linux sockets in WSL to named pipes in Windows - sounds perfect!
Get the tools
First off, I grabbed socat:
Next up, I built npiperelay, but happily John merged a PR that added releases, so you can now grab the latest release from GitHub. Once downloaded, extract the npiperelay.exe and place it somewhere in your PATH.
Exploring npiperelay and socat
The docker-relay example from npiperelay shows how to forward the /var/run/docker.sock socket to the //./pipe/docker_engine named pipe.
I took a bit of time to read up on socat. My understanding of the previous command is that it listens to the /var/run/docker.sock UNIX socket and when it gets a connection it launches the EXEC command. So in this case it starts an instance of npiperelay.exe using the specified arguments and forwards the data received on the UNIX socket to the input stream for npiperelay. On the other side, npiperelay takes the data sent to its input stream and forwards it to the //./pipe/docker_engine named pipe.
In this way, npiperelay and socat combine to be a way to forward from a UNIX socket to a Windows named pipe - pretty cool!
Testing it with SSH_AUTH_SOCK
Armed with new tools and knowledge, I deleted my SSH keys from ~/.ssh in WSL and then ran the following commands to set SSH_AUTH_SOCK and start socat.
Once that is set up I gave it a test to authenticate with GitHub (note that I’ve already added the key to GitHub and the Windows OpenSSH Agent):
Success!
Or almost :-)
It turns out that there are a few challenges with this, at least there are when you put it into your .bashrc or .bash_profile so that it runs automatically when you start your terminal.
Fixing up the script
In this section we’ll walk through the series of tweaks that I ended up making to the script. This will help to understand the script but feel free to skip ahead to the final solution if you are keen to get this set up.
Handling multiple instances of terminal
The first issue I hit was running multiple instances of the terminal. To overcome this I added a check via ps -aux to look to see if the socat/npiperelay command was running.
My first attempt at this was:
Unfortunately, this always returned 0. Dropping the -q and running it interactively, I realised that the ps.. | grep.. command was being listed in the ps output, so it alwasy got a match. Fortunately, a colleague had pointed me to a nice way round this a while back:
Note the square brackets around the n in [n]piperelay.exe. That gives a regular expression that requires that character to be an n, so we still match the original search string for the grep stage. But, it changes the command so that it no longer matches itself!
With this in place, I still hit an issue where sometimes it wasn’t finding the existing process. This took me a little longer to track down, but the issue was that the ps output gets truncated to try to fit in the terminal width. Adding the -ww to the ps command forced it to not truncate:
Clearing out previous sockets
Unfortunately, my notes for this part are missing some details, but I hit a scenario where sometimes the socket already existed.
For this I added a test using the -S condition (a list of condition expressions can be found here). Icons mac os x download.
If our socat command isn’t running then I added this check before starting it:
Keeping the forwarding running
I also wanted to keep the socat command running when I closed the terminal (ready for the next session). After some searching, I found this StackOverflow question which pointed me to setsid.
Adding setsid and suppressing the output resulted in
At this point, it can all be put together…
Final solution
The end result is that once socat is installed in WSL, and npiperelay is (See how to get the tools), you can add this script to your ~/.bash_profile or ~/.bashrc.
Note that this also requires that you have set up the SSH Agent in Windows and added your keys to it (as mentioned in the previous post).
With all this in place your SSH keys will be handled by the Open SSH Agent in Windows and SSH in WSL will access them from there!
P.S. If you liked this, you may also like my book “WSL 2: Tips, Tricks and Techniques” which covers tips for working with WSL 2, Windows Terminal, VS Code dev containers and more https://wsl.tips/book :-)
SSH Agent Forwarding with SecureCRT®
by Steve Friedl — Unixwiz.net
Steve Friedl is a Southern California native who has spent the better part of his life working with computers. From writing proprietary-language compiler tools back in college, to security consulting and communications controllers today, he has developed a broad background in technology thanks to a diverse customer base and a very curious mind. Steve has been using SecureCRT for quite a long time and is well-known in VanDyke Software's Customer Support Group. We asked Steve to adapt a Tech Tip he had written about SSH Agent Forwarding specifically for VanDyke Software customers using SecureCRT to connect to a Secure Shell (SSH) server. Many of the examples apply to connecting to an OpenSSH server. For more information on connecting to a VShell® server, please send email to VanDyke Software Support at .
Secure Shell is widely used to provide secure access to remote systems, and everybody who uses it is familiar with routine password authentication. This is the easiest authentication method to set up and is available by default, but using passwords alone suffers from a number of limitations. These include both security and usability issues, and Steve covers them in this tip. Steve then explores the various forms of authentication available to Secure Shell users and contrasts the security and usability tradeoffs of each. He then discusses the extra functionality of agent key forwarding, making the case that using SSH public-key authentication is a substantial win.
Ordinary Password Authentication
SSH supports authentication with a username and password, and this is little more than an encrypted Telnet. Access is, in fact, just like Telnet, with the normal username/password exchange.
We'll note that this exchange, and all others in this paper, assumes that an initial exchange of host keys has been completed successfully. Though an important part of session security, host validation is not material to the discussion of agent key forwarding.
All examples start from a user on homepc (perhaps a Windows workstation) connecting with SecureCRT to a server running OpenSSH. The particular details (program names, mainly) vary from implementation to implementation, but the underlying protocol has been proven to be highly interoperable.
1 | The user makes an initial TCP connection and sends a username. We'll note that unlike Telnet, where the username is prompted as part of the connected data stream (with no semantic meaning understood by Telnet itself), the username exchange is part of the SSH protocol itself. |
2 | The SSH daemon on the server responds with a demand for a password; access to the system has not yet been granted in any way. |
3 | The SecureCRT prompts the user for a password that is relayed through the encrypted connection to the server where it is compared against the local user base. |
4 | If the user's password matches the local credential, access to the system is granted and a two-way communications path is established, usually to a login shell. |
The main advantage of allowing password authentication is that it's simple to set up – usually the default – and is easy to understand. Systems which require access for many users from many varying locations often permit password authentication simply to reduce the administrative burden and to maximize access.
The substantial downside is that by allowing a user to enter a password, it means anybody is allowed to enter a password. This opens the door to wholesale password guessing by users or bots alike, and this has been an increasingly common method of system compromise.
Unlike prior-generation SSH worms, which attempted just a few very common passwords with common usernames, modern badware has very extensive dictionaries of usernames and passwords and has proven to be most effective in penetrating even systems with 'good' passwords. Only one compromised account is required to gain entry to a system.
But even putting security issues aside, the other downside of password authentication is that passwords must be remembered and entered separately upon every login. For users with just one system to access, this may not be such a burden, but users connecting to many systems throughout the day may find repeated password entry tedious.
And having to remember a different password for every system is not conducive to choosing strong passwords.
Public-Key Authentication
To counteract the shortcomings of password authentication, SSH supports public-key authentication: the user creates a pair of public and private keys, installs the public key in his account on the target server, and access is granted on a much more secure (and more convenient) basis.
The keys are very long strings of numbers and are mathematically related. Access is granted by the server when it proves that the SSH client attempting to authenticate has the private key. In this protocol, the private key itself never travels over the wire, so there's nothing for an attacker to intercept. It's really very clever.
Both keys are stored in files, and the user's private key is further protected by a secret passphrase; when the private key is needed for authentication, the user must present this passphrase to unlock the key. This is an added protection so that a user's private key file is of no value if it falls into the wrong hands.
The public key, on the other hand, is truly public: it's not sensitive information and need not be protected. Keys are represented in ASCII as long strings of digits along with some accessory information such as the key type and a comment about the key (often the owner's name). There are a few formats for these keys:
The OpenSSH server consults the keys in the file $HOME/.ssh/authorized_keys in the one-line format, and it grants access to the holder of the private key, all without a password. Note: older OpenSSH installations look in the file authorized_keys2 for version 2 keys, which is all we're considering here.
Creating a Key Pair
Creating a key pair with SecureCRT is easy; simply select Create Public Key.. from the Tools menu, and the wizard guides you through the process one step at a time. It took us less than 30 seconds to create a keywhen we just tried it.
For VShell, the public-key file can be simply dropped into the per-user public-key area on the target server without change, but for OpenSSH the key must be converted to the one-line format. One can use these instructions for converting this key and transferring it to the target system.
For VShell, the entire (small) public key file is placed into the per-user public-key directory, and it can contain as many public keys as desired.
Transferring the public-key files can be done in several ways, including cut-and-paste, file transfer, or emailing it to the system's administrator with a request to install the key.
But, when SecureCRT is connected to a SSH server supporting the Secure Shell Public-Key Subsystem (VShell, or OpenSSH with the Secure Shell Public-Key Subsystem patch), it's even easier. The Public Key Assistant.. (from the Tools menu) provides a mechanism to transfer a public key automatically. It could hardly be easier.
However the public-key files are generated and placed on the remote system, it's a one-time operation; after that, the keys 'just work'. And now we'll look at the mechanism which takes place to provide this access.
1 | The user makes an initial connection and sends a username along with a request to use a key. |
2 | The SSH daemon (sshd) on the server looks in the user's authorized_keys file, constructs a challenge based on the public key found there, and sends this challenge back to SecureCRT. |
3 | SecureCRT receives the key challenge. It finds the user's private key on the local system, but it's protected by an encrypting passphrase. SecureCRT uses 'Identity' and 'Identity.pub' as filenames for the private and public key files, respectively, regardless of key type. The user is free to rename these files as the last step in the key-generation wizard. Other clients or keytypes use different filename formats. An RSA key file is named id_rsa on OpenSSH. |
4 | SecureCRT prompts the user for the passphrase, and the comment on the private key is displayed to remind the user which key is requested. |
5 | SecureCRT uses the private key to construct a key response, and sends it to the waiting sshd on the other end of the connection. It does not send the private key itself! |
6 | The sshd validates the key response, and if valid, grants access to the system. |
This process involves more steps behind the scenes, but the user experience is mostly the same; you're prompted for a passphrase rather than a password. But, unlike setting up access to multiple computer systems (each of which may have a different password), using public-key authentication meansyoutype the same passphrase no matter which system you're connecting to.
This has a substantial, but non-obvious, security benefit: since you're now responsible for just one secret phrase instead of many passwords, you type it more often. This makes you more likely to remember it, and therefore, pick a stronger passphrase to protect the private key than you otherwise might.
Trying to remember many separate passwords for different remote systems is difficult, and does not lend itself to picking strong ones. Public key authentication solves this problem entirely.
We'll note that though public-key accounts can't generally be cracked remotely, the mere installation of a public key on a target system does not disable the use of passwords system wide. Instead, the server must be explicitly configured to allow only public-key encryption by the use ofthe PasswordAuthentication no keyword in the sshd_config file.
Public Key Authentication with Agent Support
Now that we've taken the leap into public-key authentication, we'll take the next step to enable agent support. In the previous section, the user's private key was unlocked at every connection request; this is not functionally different from typing a password, and though it's the same passphrase every time (which makes it easier to remember), it nevertheless gets tedious in the same way.
Ssh Keys Windows
Fortunately, most Secure Shell applications provide a broker known as a 'key agent', which can hold and manage private keys on your workstations and respond to requests from remote systems to verify your keys. Agents provide a tremendous productivity benefit, because once you've unlocked your private key (one time when you launch the agent), subsequent authentication works with the agent without prompting.
This works much like the key authentication seen previously, but with a twist.
1 | The user makes an initial connection and sends a username along with a request to use a key. |
2 | The SSH daemon (sshd) on the server looks [1] in the user's authorized_keys file, constructs a challenge based on the key, and sends it [2] back to SecureCRT. |
3 | SecureCRT receives the key challenge, and forwards it to the waiting agent. The agent, though part of the SecureCRT process, is nevertheless a separate entity. The agent opens the user's private key and discovers that it's protected by a passphrase. |
4 | SecureCRT prompts the user for the passphrase to unlock the private key, just as with standalone key support. |
5 | The agent constructs the key response and hands it back [1] to SecureCRT, which sends it off [2] to the sshd waiting on the other end. Unlike the previous example, SecureCRT never sees the private key directly, only the key response. |
6 | The sshd validates the key response, and if valid, grants access to the system. Note: the agent still retains the private keys in memory, though it's not participating in the ongoing conversation. |
As far as the user is concerned, this first exchange is little different from key authentication shown in the previous section the only difference is which program prompts for the private key (the SSH client itself versus the agent).With SecureCRT, the passphrase prompts are identical.
But, where agent support shines is at the next connection request made while the agent is still resident. Since it remembers the private keys from the first time it was unlocked with the passphrase, it's able to respond to the key challenge immediately without prompting. The user sees an immediate, direct login without having to type anything.
Many users only unlock their private keys once in the morning when they launch their SSH client and agent, and they don't have to enter it again for the rest of the day because the resident agent is handling all the key challenges. It's wonderfully convenient, as well as secure.
It's very important to understand that private keys never leave the agent; instead, the clients ask the agent to perform a computation based on the key, and it's done in a way which allows the agent to prove that it has the private key without having to divulge the key itself. We discuss the challenge/response in a later section.
Once agent support is enabled, all prompting has now been bypassed, and one can consider performing scripted updates of remote systems. This contrived example queries several systems for disk space.
Without agent support, each server would prompt for a password or passphrase. With agent support, there is no prompting at all.
However, these benefits only accrue to outbound connections made from the local system to SSH servers elsewhere: once logged into a remote server, connecting from there to yet a third server requires either password authentication, or setting up the user's private key on the intermediate system to pass to the third.
Having agent support on the local system is certainly an improvement, but many of us working remotely often must copy files from one remote system to another. Without installing and initializing an agent on the first remote system, the secure file transfer operation will require a password or passphrase every time. In a sense, this just pushes the tedium back one link down the SSH chain.
Fortunately, there's a great solution which solves all these issues.
Public-Key Authentication With Agent Forwarding
With our key agent in place, it's time to enable the final piece of our puzzle: agent forwarding. In short, this allows a chain of SSH connections to forward key challenges back to the original agent, obviatingthe need for passwords or private keys on any of the intermediate machines.
1 | This all starts with an already established connection to the first server, with the agent now holding the user's private key. The second server plays no part yet. |
2 | The user launches the SSH command-line client on the first server with a request to connect to server2, and this passes the username and a use-key request to the sshd. This could be done with the command-line clients as well. |
3 | The sshd searches the the user's public key folder for a matching public key or authorized_keys file [1], constructs a key challenge from the key, and sends it [2] back down the channel to the client which made the request. |
4 | This is where the magic occurs; SecureCRT on server receives the key challenge from the target system, and it forwards [1] that challenge to the sshd server on the same machine acting as a key agent. The sshd in turn relays [2] the key challenge down the first connection to the original SecureCRT. Once back on homepc, SecureCRT takes the final step in the relay process by handing the key challenge off [3] to the resident agent, which knows about the user's private key. |
5 | The agent running on homepc constructs the key response and hands it [1] back to SecureCRT, which in turn passes it [2] down the channel to the sshd running on server. Since sshd is acting as a key agent, it forwards [3] the key response off to the requesting SSH client, which sends it [4] to the waiting sshd on the target system (server2). This forwarding action is all done automatically and near instantly. |
6 | The sshd on server validates the key response, and if valid, grants access to the system. |
This process can be repeated with even more links in the chain (say, if the user wanted to SSH from server2 to server3), and it all happens automatically. Agent authentication is available with most Secure Shell utilities including ssh and sftp (secure file transfer). VanDyke Software's command-line utilities (vcp, vsftp, and vsh) participate as well.
This does require the one-time installation of the user's public – not private! – keys on all the target machines, but this setup cost is rapidly recouped by the added productivity provided. Those who use public keys with agent forwarding rarely go back.
Configuring VShell Authentication
One of the difficulties with forbidding password authentication is installation of public keys for new users; since they cannot login without a key, we're in a chicken-and-egg situation with respect to their own ability to set up their own accounts. This usually means that the administrator has to doit, and this is two interruptions for each new user rather than just one. This doesn't scale so well for larger enterprises.
VShell provides a clever solution to this: even with password authentication disabled, it can be configured to permit a small number – usually three – of password attempts before it reverts to key-only mode. This gives the user a couple of tries to login with a password to install a public key before the key is the only way to get in.
Password attempts are maintained on a per-user basis, so allowing the new users to make a go of keyless logins doesn't open this door for the existing accounts.
Configuring this requires coordination of a few settings, but it's easy to do:
- Open the VShell setup applet and navigate to the Authentication category. Uncheck both Allow and Require settings for Password; this disables password authentication entirely for the user base as a whole, requiring other, more secure mechanisms to get in.
- Check the Allow [3] password attempts check box; this grants a limited exception to the no-password provision in step #1 just for this user. Tune the number of attempts to taste.
It's inevitable that some users will have problems logging in even within the allotted attempts, and this will certainly require administrative intervention, but for the majority of users it means self-service installation of public keys.
How Key Challenges Work
One of the more clever aspects of the agent is how it can verify a user's identity (or more precisely, possession of a private key) without revealing that private key to anybody. This, like so many other things in modern secure communications, uses public-key encryption.
When a user wishes access to an SSH server, he presents his username to the server with a request to set up a key session. This username helps locate the list of public keys allowed access to that server; with VShell, it's found in the public key folder assigned to that user, or with OpenSSH it's typcially found in the $HOME/.ssh/authorized_keys file.
The server creates a 'challenge' which can only be answered by one in possession of the corresponding private key; it creates and remembers a large random number, then encrypts it with the user's public key. This creates a buffer of binary data which is sent to the user requesting access. To anybody without the private key, it's just a pile of bits.
When the agent receives the challenge, it decrypts it with the private key. If this key is the 'other half' of the public key on the server, the decryption will be successful, revealing the original random number generated by the server. Only the holder of the private key could ever extract this random number, so this constitutes proof that the user is the holder of the private key.
The agent takes this random number, appends the SSH session ID (which varies from connection to connection), and creates an MD5 hash value of the resultant string: this result is sent back to the server as the key response.
The server computes the same MD5 hash (random number + session ID) and compares it with the key response from the agent; if they match, the user must have been in possession of the private key, and access is granted. If not, the next key in the list (of any) is tried in succession until a valid key is found, or no more authorized keys are available. At that point, access is denied.
Curiously, the actual random number is never exposed in the client/agent exchange — it's sent encrypted to the agent, and included in an MD5 hash from the agent. It's likely that this is a security precaution designed to make it harder to characterize the properties of the random number generator on the server by looking at the client/agent exchange.
More information on MD5 hashes can be found in An Illustrated Guide to Cryptographic Hashes.
Security Issues With Key Agents
One of the security benefits of agent forwarding is that the user's private key never appears on remote systems or on the wire, even in encrypted form. But, the same agent protocol which shields the private key may nevertheless expose a different vulnerability: agent hijacking.
Each SSH implementation has to provide a mechanism for clients to request agent services, and on UNIX/Linux this is typically done with a UNIX domain socket stored under the /tmp/ directory. On our Linux system running OpenSSH, for instance, we find the file /tmp/ssh-CXkd6094/agent.6094 associated with the SSH daemon servicing a SecureCRT remote client.
This socket file is as heavily protected as the operating system allows (restricted to just the user running the process, kept in a protected subdirectory), but nothing can really prevent a root user from accessing any file anywhere.
If a root user is able to convince his SSH client to use another user's agent, root can impersonate that user on any remote system which authorizes the victim user's public key. Of course, root can do this on the local system as well, but he can do this directly anyway without having to resort to SSH tricks.
Several environment variables are used to point a client to an agent, but only SSH_AUTH_SOCK is required in order to use agent forwarding. Settingthis variable to a victim's agent socket allows full use of that socket if theunderlying file is readable. For root, it always is.
One cannot tell just from looking at the socket information which remote systems will accept the user's key, but it doesn't take too much detective work to track it down. Running the ps command periodically on the local system may show the user running SSH remotesystem, and the netstat command may well point to the user's home base.
Furthermore, the user's $HOME/.ssh/known_hosts file contains a list of machines which the user has a connection: though they may not all be configured to trust the user's key, it's certainly a great place to start looking. Modern versions (4.0 and later) of OpenSSH can optionally hash the known_hosts file to forestall this.
There is no technical method which will prevent a root user from hijacking an SSH agent socket if he has the ability to access it, so this suggests that agent forwarding might not be such a good idea when the remote system cannot be entirely trusted. All SSH clients provide a method to disable agent forwarding.
The Command-Line Clients
Most users spend the bulk of their time in SecureCRT terminal windows, but there's a parallel set of tools to support command-line usage. Available from VanDyke Software, they fully work and play well with all the other parts, including the key agents.
- vcp.exe
This is the secure file transfer program, and it's able to copy files to and from remote systems from the command line. Though it appears to work like the UNIX scp, the UNIX version uses the rcp/remote execute mechanism while vcp uses the SFTP protocol. It's able to fully use any resident key agents. - Copy operations can go in either direction, subject to the rights granted by the remote server.
Ssh Port Forward
vsh.exe
This is a full-strength SSH client, providing remote login and remote command execution services from the command line; in this respect it's very much like the OpenSSH ssh command.
This provides an FTP-like front end to the Secure Shell File Transfer protocol, and it's easier for many users to navigate than the low-level vcp operations (users wishing a GUI interface should consider SecureFX).
Each takes a similar set of command-line parameters which direct most of the important behaviors, and this makes them all highly amenable to scripting.
Of particular utility in the scripting arena is the ability to provide a specific private key file. It's common to create a separate key which provides only limited powers on the target server (for instance, it could allow the user to connect, but only to run a single, specified command via vsh).
Since scripts often run from Scheduled Tasks (and do not allow user interaction), all the credentials necessary for remote access — the username, the key, and the passphrase must be provided with the script. This is not terribly secure, so by creating a key configured with purpose-built limited powers, compromise of the credentials by those with access to the machine doesn't provide unrestricted access to the remote system.
Ssh Forward Ssh Key Command
Additional Resources
Up to this point, we've provided essentially no practical how-to information on installing or configuring any particular SSH implementation. Our feeling is that this information is covered better elsewhere, and we're happy to provide some links here to those other resources.
TheSecure Shell: The Definitive Guide, 2 Ed (O'Reilly & Associates).This is clearly the standout book in its class: it covers Secure Shell from A to Z, including many popular implementations. There is no better comprehensive source for nearly all aspects of Secure Shell Usage. A worthy addition to any bookshelf.Unixwiz.net Tech Tip: Building and configuring OpenSSH Though this Tech Tip is mainly concerned with configuration of the server on a UNIX/Linux platform, it also provides a some notes on SecureCRT key generation.
Unixwiz.net Tech Tip: An Illustrated Guide to Cryptographic Hashes Though not central to using SSH Agent Forwarding, some coverage cryptographic hashes may help understand the key challenge and response mechanism. This Tech Tip provides a good overview of crypto hashes in a similarly-illustrated format.